Tenant separation is the design premise
Complyee is built as a multi-tenant service where separation between customers is enforced by the platform itself, not by careful use of the user interface. Each workspace has its own address, its own document store, its own settings, its own members and its own audit trail.
Every request is resolved to exactly one workspace before any data is read, and every data access is scoped to that workspace at the data layer. There is no view, endpoint or search path in the product that spans two customers.
Getting into a workspace
Access control is layered: a request has to arrive from an approved network, from an approved identity, on an approved email domain, before it can become a workspace session.
- Approved networks only
Each workspace can define the public IP ranges it is reachable from. Requests from anywhere else are refused — both at the edge, before they reach the application, and again inside the application when a session is established. The application only accepts a caller's network address when it arrives with a cryptographic assertion issued by our own edge; a self-declared address is never enough. If a workspace has network restrictions switched on and that assertion is missing, the request is refused rather than allowed through.
- API keys with their own network rules
Programmatic access uses per-workspace API keys, stored only as hashes. Each key can carry its own list of approved IP ranges, and a key with such a list answers only from those networks — regardless of where the key is presented from. This is also the path for server-to-server integrations in network-restricted workspaces: browser and sign-in traffic is vouched for by our edge, while a network-scoped key lets an approved integration server call the API directly without weakening the workspace-wide network rules.
- No passwords, anywhere
Complyee has no password to phish, reuse or leak. Employees sign in either with a one-time code sent to their company mailbox, or with single sign-on through the company's own identity provider.
- Company email domains only
A workspace lists the email domains it accepts. Addresses outside those domains cannot receive a sign-in code and cannot become members, regardless of how the request is made.
- Single sign-on, optionally mandatory
Single sign-on can be enabled, and then required. When required, the email-code path is switched off entirely and refused on the server — so identity, multi-factor policy, conditional access and deprovisioning are governed solely by your identity provider. Attempts to use the disabled path are recorded.
- Sign-in attempts are rate limited
Requests for a sign-in code are throttled per email address and per network address, with a temporary lockout once the limit is crossed. This blunts code guessing and mailbox spam, and every throttled attempt is recorded in the workspace audit trail.
- Roles, not shared logins
Members, workspace administrators and platform administrators are distinct roles held per user. Role changes are privileged operations performed server-side and written to the audit trail.
Your documents
Documents are uploaded by your workspace administrators and stored in a storage location dedicated to your workspace. Your content is never pooled with another customer's content, and the search index built from it is likewise dedicated to your workspace.
Documents are not published on public links. Opening or downloading a document goes through the application, which re-checks the member's session, role, workspace and network before issuing a short-lived, single-purpose grant for that one file. Deleting a document removes it from both the store and the search index.
Answers stay inside your material
Retrieval is restricted to your workspace's own document set — the assistant cannot reach another customer's material, and it cannot reach the open internet. A grounding setting controls how strictly answers must stay within the source documents, and answers carry references back to the document and page they came from, so any claim can be checked.
Your documents, questions and answers are not used to train models.
Keys and credentials
Service credentials live in an encrypted secret store managed outside the codebase. They are never committed to source control, never shipped to the browser and never rendered in the interface — only server-side code can read them, and only at the moment it needs them. Credentials can be rotated without changing application code.
Access between components follows least privilege: each credential is granted the narrowest role that lets it do its job, and nothing more.
Separation inside the AI platform
For workspaces running on the Complyee-operated cloud environment, separation is carried through to the AI layer: each workspace has its own storage bucket and its own search datastore, addressed by identifiers that are bound to the workspace record. A query issued in one workspace is physically incapable of reaching another workspace's datastore, because the datastore it targets is resolved from the authenticated workspace, never from anything the user supplies.
Bring your own cloud
Where your policy requires it, a workspace can run entirely inside your own Google Cloud project: your storage, your search index, your region, your service account. Complyee then holds only a scoped credential that you issue and can revoke at any time, and your documents and generated answers never leave your own tenancy.
Edge protection
All traffic is served over TLS through a global edge network that absorbs volumetric and denial-of-service traffic before it reaches the application. Per-workspace firewall rules at that edge drop requests from networks a customer has not approved, so unauthorised traffic is stopped upstream rather than at the application door.
Audit trail
Each workspace gets its own audit trail: sign-ins, denied sign-in attempts, questions asked, answers returned, documents uploaded, indexed and deleted, document downloads, document requests and their outcomes, role changes, member removals and settings changes.
The trail is written to your workspace's own storage and is readable by your administrators in the product, so your security function can review activity without depending on us to extract it.
Sessions and access revocation
Sessions do not last indefinitely. Each workspace sets how long a session may sit idle before it is signed out, and an absolute maximum length after which the person must authenticate again, whatever they are doing. Both limits are enforced on our side, not only in the browser, so an open tab cannot keep asking questions past them.
Workspace administrators can end sessions immediately: for one member, or for everyone in the workspace at once. Revocation takes effect for requests made after it, not when a token happens to expire, and it is written to your audit trail. Removing a member, or forgetting one, ends their sessions as part of the same action, so offboarding does not leave a signed-in device behind.
One honest limitation: ending a Complyee session does not end the session at your identity provider. Where single sign-on is enabled, a user may be signed straight back in without typing a password. To cut access completely, disable the account at your identity provider as well — or remove the member here, which stops them rejoining even with a valid single sign-on session.
Your own security posture, visible in the product
Workspace administrators do not have to ask us how their workspace is configured. A security page inside the product shows it live: whether single sign-on is enabled and enforced, which email domains may join, which networks are allowed, the session limits in force, who holds administrator rights, whether programmatic access is switched on, and how long records are kept.
Each item carries a plain-English explanation and a status — good, worth reviewing, or not configured — so it works as a self-audit checklist rather than a settings dump. There is no overall score or grade; we describe your configuration, we do not certify it. The checklist can be exported for your own audit file, and settings only we can change have a request path built in.
Availability, backup and recovery
The service is delivered through a global edge network and we work to keep it available, with maintenance planned and interruptions kept short. Self-service plans carry a reasonable-efforts commitment rather than a contractual uptime guarantee; an uptime commitment can be agreed in a customer agreement. We do not yet publish a public status page — where an incident affects a workspace, we notify its administrators by email.
Backups exist so the service as a whole can be recovered from a disaster. They are never used to bring back data a customer deleted deliberately, which is consistent with the deletion commitments on our privacy page.
- Application database
Workspaces, members, roles, settings, requests and key records are held in a managed EU-hosted database with automated daily backups and point-in-time restore taken by our managed platform provider. We do not operate the backup schedule ourselves, and restoring is a platform operation rather than a self-service action in the product.
- Documents and audit trails
These live in your workspace's own cloud storage with object versioning and soft delete enabled. An object that is overwritten or deleted can be recovered for 7 days, and non-current versions are retained for 90 days, so document recovery is effectively point-in-time within that window.
- Search index
The index is derived data. It is not backed up separately — it is rebuilt from the documents in the workspace's storage.
- Recovery point and recovery time
For the application database we target a recovery point of up to 24 hours and a recovery time, best effort, within one business day for a full-service restore. For documents and audit objects the recovery point is effectively zero within the versioning window and recovery takes hours, since it is done per object. These are service-wide targets, not a contractual service level on self-service plans.
- Testing, stated honestly
Restore capability is provided and exercised by the platform that operates the database. We do not yet publish a formal restore test report of our own, and we will say so rather than imply a programme we do not run.
Data location
New workspaces are placed in the EU by default, and the region is fixed for the lifetime of the workspace. Other regions can be selected at onboarding where your operations require it, and customers running in their own cloud project choose their region themselves.
Where we are on certifications
We would rather be plain about this than imply more than is true: Complyee is not currently SOC 2 or ISO 27001 certified, and we do not claim to be. What we do have is the set of controls described on this page, applied to every workspace by default rather than as paid add-ons, and a willingness to walk your security function through the specifics under NDA.
We are happy to complete security questionnaires, discuss a data processing agreement, and share our roadmap towards formal certification. If a certification is a hard requirement for you today, tell us early and we will say so honestly rather than let it surface late in a procurement process.
Leaving Complyee
Deletion is a real operation in the product, not a promise on a page. When a workspace is deleted, every document is removed from the search index first, then every object in the workspace's storage bucket is deleted, then the bucket itself, then the sign-in accounts that exist only for that workspace, and finally the workspace record and all its database rows — members, roles, settings, API keys, document requests and query history. If the search index cannot be cleared, the deletion stops and nothing is removed, so a workspace is never left half-deleted with content still answerable.
Removing a single member is a real operation too: their name and email in the requests and feedback they submitted are replaced with an anonymous placeholder, and their sign-in account is deleted unless it also belongs to another workspace. Audit events already recorded keep the original identifier and are covered by your workspace’s own retention period rather than rewritten — if your data processing agreement needs those historical entries pseudonymised, ask us and we will handle it as a documented request. Every completed deletion, of a workspace or a member, is recorded in a receipt we keep outside your bucket so the deletion stays provable after the bucket is gone.
Your audit trail lives in your own bucket and is deleted with it. Export it first if you need to retain it — it is plain JSON, readable by your administrators in the product at any time while the workspace is open.
A workspace administrator can download a full JSON export of the workspace at any time from workspace settings — the workspace record and assistant settings, members, the document manifest, requests, feedback, API key metadata, approved networks, and the audit trail — and can request deletion from the same page. We complete a deletion request within 30 days. What remains afterwards is only what law requires us to keep: billing and accounting records, held for the period Swedish accounting law prescribes. Workspaces running in your own Google Cloud project are deleted the same way, using the credential you issued; if you have already revoked it, we tell you so rather than reporting a deletion we could not perform.
Reporting a vulnerability
If you believe you have found a security weakness in Complyee, please write to security@complyee.ai with enough detail for us to reproduce it. We acknowledge reports within two business days and will keep you updated until the issue is resolved. Please give us a reasonable window to fix an issue before disclosing it publicly, and do not access, alter or retain data that is not yours while investigating.