This page is written for the person who has to sign off on new software. It says what we do, what we don't have yet, and who to email. Nothing on it requires an NDA to read.
| Control | Status | Detail |
|---|---|---|
| Encryption in transit | Yes | HTTPS with HSTS on the web app, the API, the MCP server and device sync. Plain HTTP is redirected. Webhooks are only ever delivered to HTTPS endpoints. |
| Password storage | Yes | Salted, iterated hashes (ASP.NET Core Identity). Minimum 8 characters with mixed case, a digit and a symbol. |
| API key storage | Yes | Shown once, stored as a salted PBKDF2-SHA512 hash. Only a short prefix is kept in the clear so you can tell keys apart in the list. |
| API key expiry and IP allow-lists | Yes | A key can be given an end date (30 days to a year, or a chosen date) and limited to up to 50 IPv4/IPv6 addresses or CIDR ranges; both are set when it is created or edited later in Settings → Integrations → API Keys. Both are checked on every API and MCP request: an expired key gets 401, a call from outside the list gets 403. The caller's address is taken from the connection, so a forged X-Forwarded-For header doesn't count. |
| Multi-tenant isolation | Yes | Every record carries its organization; every query, API call and MCP tool is filtered by the caller's organization on the server. Device sync is bound to the organization the device is registered to: a desktop, phone or office app of one organization cannot read or write another's, whatever it puts in its request. There is no "all organizations" mode outside our own system administration. |
| Roles and permissions | Yes | Organization Admin, Manager and User roles, plus more than 30 fine-grained permissions (view/manage per area). API keys carry a subset of their creator's permissions and can never be granted more; they follow the creator over time — a deactivated creator's keys stop working and a demoted creator's keys lose what the creator lost, within a minute. |
| Admin removal protection | Yes | One Organization Admin can't quietly demote or deactivate another through the Users page, the API, an AI agent or any Flex app. Removing an admin takes a request: it applies when they approve it, or after 14 days' notice (in-app and by email) that they can contest. An admin can step down themselves at once, and the organization's last active Organization Admin can never be removed. The rules are enforced by our server, not by the app. Requests from the Flex web app, the API and AI agents are checked by our servers against the person actually signed in or the key's creator; requests from an installed Flex app must carry a short-lived credential that only that person's own sign-in on that device can produce. It is issued only after their two-factor code if they use it, is stored encrypted on the device, and is deleted when they sign out; if the device is online at that moment, our server also refuses it from then on. Either way, nobody can act as another admin. |
| Audit history | Yes | Jobs keep a timestamped history of every status change, assignment, note and edit with who did it; stock movements and payments record who made them. Every API and MCP request is logged per key — method, path, status, timing, IP, and for an AI agent the MCP tool it called (never the arguments, results or the key itself) — and kept 90 days. Admins browse and filter it, and download it as CSV, at Settings → Integrations → API activity, or read it from code (GET /api/v1/activity). Refused calls from an expired key or a disallowed IP are logged with the reason. |
| Webhook integrity | Yes | HMAC-SHA256 signature on every delivery; private, loopback and link-local destinations refused; redirects never followed. |
| Rate limiting | Yes | Per key and per organization on the API and MCP server; every response states the limit, what's left and when it resets. |
| Device authorization | Yes | Desktop, phone and office-app installs are registered devices with their own tokens. Registering one by signing in needs the person's password and, if they use two-factor, their code; a device registered with an administrator's registration key still asks each person for their code at sign-in. A device syncs only its own organization, and only for people of that organization who are still active. Once a device's token is replaced, our server refuses the old one, and signing in on a new install never takes over another install's registration. An administrator can revoke a device and it stops syncing. |
| Payment card data | Never stored | Card entry and storage happen at Stripe. Flex holds your plan, seat count and invoice history only. |
| Data export | Yes | Everything is reachable through the API; an admin downloads a full export of the organization (every table as JSON and CSV, one zip, described column by column in the data dictionary) from Settings → Export All Data; invoices export to CSV for QuickBooks. |
| Scheduled export | Yes | The same zip, daily or weekly, to your SFTP server, an S3-compatible bucket or an emailed download link. Destination passwords and keys are encrypted and never shown again; SFTP servers and bucket endpoints must be public addresses, and the SFTP server's host key is pinned after the first run. A download link works for 7 days and only a hash of it is stored. |
| Backups | Yes | A database snapshot is taken before every production deployment and before any bulk data operation, and kept alongside the previous release for rollback. Schedule and retention details on request. |
| Two-factor authentication | Available | Authenticator-app codes (TOTP, e.g. Microsoft or Google Authenticator) with single-use recovery codes, turned on per user from Account → Settings in the web or desktop app. Optional per user, or required for everyone by an organization admin (Settings → Security in the web app; our server ignores the setting from any other app): in the web app, people without an authenticator are asked to set one up before they can continue, and cannot turn it off; the installed apps send them to the web app to set it up first. The keys are held by our server, never on a desktop, phone or tablet, and our server checks the code: signing in to the web, desktop, phone or office app, or registering a new device by signing in, gives that device nothing until the code is right. Each code works once, whichever app it was typed into, and five wrong passwords or codes lock sign-in for five minutes. A lockout doesn't erase anyone's offline sign-in. In the web and desktop apps alike, turning two-factor on needs your password as well as a code; turning it off, resetting it or making new recovery codes needs a current code (a recovery code also works for turning it off or resetting it). Changing your password in the web or desktop app needs a current code too. The phone and office apps only ask for the code at sign-in; two-factor is set up and changed in the web or desktop app. When an installed app is offline it only lets in people who have signed in online on that device (on the phone and office apps, within the last 30 days). Once someone turns two-factor on, a password-only offline sign-in stops working on each device as soon as that device next hears from our server: the desktop checks at every online sign-in and every hour, and the phone and office apps check at every sign-in and after every sync. API keys and the MCP server are unchanged. |
| Single sign-on | Sign in with Google is available for the web app — for regular users and administrators alike; administrator single sign-on always requires two-factor. SSO links to an existing Flex account by verified email and never creates accounts. SAML / enterprise OIDC is planned — ask if it's a requirement for you and it moves up the list. | |
| SOC 2 / ISO 27001 | No | We are a small company and have not undergone a third-party audit. We would rather say so than imply one. We will complete a security questionnaire for any prospective customer. |
An organization id is attached at sign-in, at key creation and at device registration, and the server applies it to every read and write. A bug in a page cannot widen the scope; the scope is decided before the page runs.
An API key or an AI agent gets the permissions you tick and nothing else. A key cannot be granted more than its creator holds. Give a reporting tool read-only keys; give a scheduling bot ManageJobs and nothing about invoices. Give a contractor's key an end date, and fence a server integration to its own IP addresses.
Outbound webhooks are signed so the receiver can prove they came from us. Destinations are validated when you subscribe and again at send time, so Flex can't be used to poke at someone's internal network.
Database credentials, signing keys and third-party tokens live in server configuration with restricted file permissions, outside the repository, and are rotated when staff or contractors change.
The Windows desktop keeps a local copy so work continues without internet. That copy is tied to a registered device and a signed-in user; permissions are enforced locally the same way they are on the server, and a revoked device stops syncing.
Your business data is not used to train AI models, build marketing profiles or benchmark you against other customers. The MCP server exists so your chosen agent can act for you; our own AI Assistant runs only when an organization turns it on (below). Details on the AI page.
Our built-in AI Assistant is an optional module, off until an organization admin turns it on and acknowledges that using it sends the relevant business records to Anthropic to answer each request. Anthropic's API does not train on that data. The assistant works through the same permission-checked tools an API key uses, so it can never do more than the signed-in person's own permissions, and every change it makes waits for that person to confirm it in the chat.
Lock-in is not a retention strategy we're interested in.
| Provider | Purpose | What they see |
|---|---|---|
| Stripe | Billing | Billing contact, company name, plan; card details go straight to Stripe. |
| Cloudflare | DNS and inbound email routing | DNS queries; mail sent to our @flexonthejob.com addresses. |
| Google Fonts / reCAPTCHA | Marketing site only | Visitor IP on flexonthejob.com; never loaded inside the app. |
Hosting is on servers we operate ourselves, not on a shared multi-tenant SaaS platform. Region and provider details are available to customers on request. We'll tell you before adding a sub-processor that would see your business data.
Email [email protected]. A human reads it. We acknowledge within two business days, keep you updated while we fix it, and credit you if you'd like.
Machine-readable: /.well-known/security.txt
Our standard Data Processing Addendum applies to every account with nothing to sign; we'll countersign a copy for your files. We'll also complete your vendor security questionnaire and walk your IT person through the architecture on a call.
Reviewers and auditors: admin-scoped sandbox access to our demo organization — an admin API key and a sandbox admin login — is available on request, so you can actually test the admin-gated controls (required two-factor, API-key expiry, IP allow-lists, the activity log, full export, and user and role writes) rather than just read about them. Email [email protected].
Only if you give them the role for it. A User sees the jobs they're on and the stock they touch; a Manager sees the whole operation; an Organization Admin also manages users, keys and billing. Each role's permissions can be adjusted per organization.
Not through Flex. Taking Organization Admin away from someone, or deactivating them, needs their approval or 14 days' notice that they can contest — the same through the Users page, the API and MCP. (Our server checks who is actually signed in — or, for the API and MCP, whose key it is — before it acts, never a name the request merely claims.) Nobody can remove the organization's last active admin, and Flex support can step in if an admin is unreachable.
Yes. The authenticator keys live on our server, not on any device, and our server checks the code when someone who uses two-factor signs in to the web, desktop, phone or office app, or registers a new device. The installed apps ask for the code (or a recovery code) and get nothing from our server until it is right. Offline, an app only lets in people who have signed in online on that device before (on the phone and office apps, within the last 30 days), and once the device has heard from our server since someone turned two-factor on, only if that online sign-in included their code. API keys and AI agents use their own keys and are not asked for a code.
Deactivate the user in Settings. Their signed-in sessions end within five minutes, their devices stop syncing, and any API keys they created are listed so you can revoke them. Their name stays on the history they wrote.
Yes. Each key can carry an allow-list of up to 50 IPv4 or IPv6 addresses and CIDR ranges, and an expiry date; set them when you create the key or later with Edit under Settings → Integrations → API Keys. A call from anywhere else is refused with 403 and shows up in the key's activity log. Keys are also limited by permission, rate and revocation.
Yes. Settings → Integrations → API activity lists every API and MCP request with the key, path or tool, status, timing and IP, filterable by key, date, status and text, with a CSV download; it's kept 90 days. Job and order history entries written through a key are also marked "via API key" with its name.
We run our own security reviews on every release that touches authentication, the API or sync, and fix findings before shipping. We have not commissioned an external penetration test yet; when we do, the summary will be here.
There hasn't been a security incident affecting customer data. If there ever is, affected organizations are notified by email within 72 hours of confirmation, and a summary is posted on status.flexonthejob.com, which also shows live availability of every service and the last 90 days.
Ask the people who built it. We'd rather answer now than surprise you later.
on the job