Security Overview

How the service is built, how customers are kept apart, and which controls protect their data. Written for the people who fill in vendor security questionnaires; where a control is not yet in place, this page says so.

Last updated: 2026-09-18.

Architecture

DocAI Fabric runs on Microsoft Azure, deployed separately per Region (Data Handling). Each Region is an independent stack with its own subscription, storage, queue, secrets and AI endpoints: nothing is shared between Regions.

Component	Service	Role
Application and workers	Azure Container Apps	The API, the web application and the document-processing workers run from one container image; workers scale with the queue
Documents, results, configuration, audit log	Azure Blob Storage	All customer data at rest; no database holds customer content
Queue	Azure Managed Redis	Work queue and short-lived coordination state; no documents are stored in it
Secrets	Azure Key Vault	API keys, connection strings, signing keys; the application reads them through a managed identity
Edge	Azure Front Door (Australia; United States after migration)	TLS termination, custom domain, health probing
OCR and AI	Azure AI Document Intelligence, Azure OpenAI, Azure AI Foundry	Called inside the Region; see Data Handling for the per-Region line-up

Anonymous access to storage is disabled; storage is reachable only with credentials held by the application. HTTPS is enforced everywhere.

Tenant isolation

Every customer is a tenant. Isolation is enforced in the application on every request, not by convention:

• All stored objects live under a path that starts with the tenant identifier. There is no cross-tenant listing or read path in the storage layer.
• Every API request is authenticated to a user or API key, resolved to exactly one tenant, and then authorised against that user's grants. A request cannot name another tenant.
• The AI assistant and all automation tools operate through the same authorised API layer, with the same tenant boundary.
• Security testing includes cross-tenant access attempts as a standing regression suite; a cross-tenant finding is rated Critical with a seven-day fix commitment (see Compliance).

Authentication and sessions

• Sign-in with email and password. Passwords are stored as salted bcrypt hashes and never logged.
• Sessions last 7 days, extended while the user is active, and can be revoked by an administrator from the Sessions page.
• Sign-in throttling protects against credential stuffing: per account, progressive delays after 5 failures and a 15-minute block after 20; per source address, the same at 20 and 100. Blocks expire automatically and never affect existing sessions.
• API access uses per-tenant API keys with scoped permissions. The Security Overview page inside the product shows unused keys (90 days) and keys about to expire (30 days) so administrators can rotate them.
• Single sign-on through your organization's identity provider (OpenID Connect: Microsoft Entra ID, Okta and others). People sign in with the provider's passwords and multi-factor authentication, and groups in the provider decide which DocAI Fabric groups, and so which roles, they get. Administrators set it up on the Security page; a domain is proven by a DNS record before it can be used, and a connection must pass a test sign-in before it is switched on. Administrators can require single sign-on for the organization, which turns password and Google sign-in off for everyone except the owner and named break-glass or guest exemptions; every exempt sign-in is recorded, and a break-glass one emails the administrators. Personal API keys and connected AI agents of people who sign in only through single sign-on pause after 7 days without a sign-in (configurable from 1 to 30), so access ends for someone removed in the identity provider. SAML 2.0 and automatic deprovisioning (SCIM) are on the roadmap. Our own staff use multi-factor authentication for all administrative access.

Authorisation: the grants model

Access inside a tenant is governed by grants (fine-grained permissions such as viewing documents, editing configuration, publishing, managing users, reading the audit log). Roles are bundles of grants: built-in roles cover common jobs and administrators can define custom roles and assign them to users or groups. Every screen and every API endpoint checks grants, so a custom role behaves exactly like a built-in one.

Encryption

• In transit: TLS 1.2 or later for every connection, external and internal.
• At rest: AES-256 through Azure Storage service-side encryption, for documents, results, configuration, backups and the audit log.
• Secrets: Azure Key Vault, with soft delete; application access through managed identity rather than stored credentials.

Logging and monitoring

• A security audit log records sign-ins (successful, failed, blocked), user and role changes, API-key events, configuration changes, data exports and administrative actions, per tenant. Administrators can read it in the product and export it.
• Retention is 400 days by default; we can set it between 90 days and 7 years for a tenant on request.
• Forwarding to a customer SIEM is available as a signed webhook feed (HMAC-SHA256 signature on every delivery).
• Platform logs and metrics go to Azure Log Analytics per Region; access is limited to the operations group.

Secure development

• Every change is reviewed and goes through automated tests before merge. The main branch is protected: pull requests only, required checks, no bypass.
• Automated security checks run on every pull request: dependency vulnerability scanning, static analysis and licence compliance. The container image is scanned for known vulnerabilities whenever a change to its components is merged, on every release, and weekly.
• Test and production environments are separate, with separate credentials.
• Deployments are reproducible from version-controlled infrastructure definitions and a tagged container image; production releases are tagged and can be rolled back.
• Third-party components and their licences are listed in the Third-Party Notices, regenerated automatically from the dependency manifests.

Security testing

• Quarterly internal penetration test following the OWASP Web Security Testing Guide, with findings tracked to closure against fixed severity deadlines (Critical 7 days, High 30 days, Medium 90 days).
• Cross-tenant, authorisation and injection tests run as a permanent regression suite.
• Annual external penetration test by an independent firm: first engagement scheduled for Q4 2026. The attestation letter will be available to customers under NDA.
• Responsible disclosure programme: see Responsible Disclosure.

Incident response

• Incidents are handled by the on-call engineering team under a documented runbook.
• A confirmed security incident affecting a customer's data is notified to that customer's administrators without undue delay and in any event within 48 hours, with the information needed for the customer's own obligations.
• Post-incident reviews are written for every incident affecting availability or data. Customers on Enterprise Support receive a written root cause analysis for every P1 incident, as the Support Policy provides; for everyone else the status page post is the record.

Personnel

• Confidentiality undertakings for all staff and contractors.
• Data-protection and security training at onboarding and annually.
• Production access limited to a named operations group, by named account with multi-factor authentication, logged, and revoked on role change or departure.

Business continuity

Per-Region storage redundancy, replication and the 90-day Recovery Window are described on Data Handling. Recovery objectives and their testing cadence are set out in the Service Level Agreement for Enterprise plans.

Questions and documents

security@docaifabric.com. Completed security questionnaires, the penetration-test attestation letter and the architecture whitepaper are available under NDA on request.