Workspace Data Isolation & Multi-Tenant Security

Every workspace is an isolated silo - database-level filtering and workspace-scoped encryption keys make cross-tenant access architecturally impossible

Overview

Instafill.ai is a multi-tenant platform: many organizations use it simultaneously, on shared infrastructure. The central security question for any multi-tenant system is: can Organization A ever see Organization B's data? The answer for Instafill is no - not through a bug, not through misconfiguration, not by Instafill staff - and this page explains how that isolation is enforced at every layer.

Isolation is implemented at two independent levels that must both be bypassed simultaneously for any cross-tenant access to occur:

  1. Database-level: Every query against every collection includes a workspaceId filter. A session, form, profile, or source file can only be retrieved if the requesting user's workspaceId matches the record's workspaceId.
  2. Cryptographic level: Every workspace's data is encrypted with a unique set of keys stored in an HSM-backed Azure Key Vault, scoped to that workspace. Even if a database query somehow returned the wrong records, the data would be encrypted with the wrong key and unreadable.

How Database-Level Isolation Works

Authentication Middleware Extracts Workspace Identity

Every API request to Instafill is authenticated before any business logic runs. The authentication layer:

  1. Validates the JWT token (signature, expiry, audience claim)
  2. Identifies the user and their active workspace
  3. Attaches the workspace ID to the request context for all downstream operations

There is no path to the filling pipeline, form retrieval, or session access that bypasses this step.

Every Query Filters by Workspace

Once the workspace ID is established for a request, it is injected into every database query. A session, form, profile, or source file can only be retrieved when the database query explicitly matches both the record ID and the requesting workspace's ID - a record belonging to Workspace B cannot be returned in response to a Workspace A request, even if the record IDs happen to match.

This filtering applies to every data type: sessions, forms, profiles, batch jobs, and source files. No query retrieves records without a workspace scope.

What This Means in Practice

  • A user in Workspace A cannot access sessions created in Workspace B, even with knowledge of the session ID
  • Form templates are workspace-scoped - a form uploaded in one workspace does not appear in another
  • Profiles, source documents, and batch jobs are all workspace-isolated
  • API keys are workspace-scoped - an API key from one workspace cannot access another workspace's data

How Cryptographic Isolation Works

Workspace-Scoped Encryption Keys

Each workspace has its own unique 256-bit encryption keys, auto-generated by Instafill.ai and stored in an HSM-backed Azure Key Vault scoped to that workspace. When source text or file data is encrypted, the workspace ID is included in the encryption scope - the ciphertext can only be decrypted in the context of the originating workspace.

Key rotation happens automatically on an annual basis by default. Enterprise customers can bring their own customer-managed keys (BYOK) in their own Azure tenant - Instafill gets wrap/unwrap access only with no export capability. All decryption operations are logged to Azure Monitor.

For full detail on the encryption stack and key management options, see Data Encryption and Security.

What Azure Stores

Azure Key Vault holds the key material in HSM-backed storage - the keys themselves are never stored in application code or configuration files. Azure Blob Storage holds encrypted file data, with the encryption keys held separately in Key Vault. Azure itself cannot decrypt either without Instafill's application logic.

Encryption in the Filling Pipeline

When autofill runs, source text is decrypted in memory immediately before being passed to the AI provider. The decrypted text exists only in the application's working memory for the duration of that operation - it is not logged, not written to disk in decrypted form, and not accessible to other requests. After the AI call completes and field values are stored, the in-memory decrypted text is no longer referenced.

File Storage Isolation

Files are stored in Azure Blob Storage under a path structure that includes user and session identifiers. There is no shared namespace where one workspace's files could be accessed by another. Access tokens generated for file retrieval are scoped to specific paths and time windows and cannot be used to access other users' files.

Workspace Roles and Internal Access Control

Within a workspace, access is further controlled by roles. Role enforcement happens at the API endpoint level in addition to workspace-level isolation - a lower-privileged role cannot access higher-privileged endpoints even within the same workspace.

For the full role breakdown at the organization, workspace, and folder level, see Workspace Management and Organization Management.

Real-world example: Healthcare organizations filling credentialing packets for multiple hospitals use separate workspaces per client, with role-based access ensuring only authorized staff can view completed packets. See how Hawkeye Physicians automated multi-hospital credentialing with workspace isolation keeping each hospital's data separate.

Organization-Level Policy Enforcement

Organizations contain one or more workspaces. Organization admins can require all members to have two-factor authentication enabled before accessing any workspace. Members who do not have 2FA enabled are unable to access organization resources until they update their settings. Outside collaborators without 2FA enabled are removed from the organization.

This policy is enforced at authentication time and cannot be bypassed by workspace-level settings.

Data Privacy

No one at Botmakers LLC has access to view, edit, or manually inspect your data. All processing is handled automatically and securely. All access to systems, APIs, and user data processing activities is logged with timestamped details including origin, action type, and access level, and is retained for audit and compliance purposes.

For healthcare and legal customers with strict PHI or attorney-client privilege requirements, Instafill can discuss contractual access restrictions via a BAA or DPA. Contact sales.

Security and Privacy

  • Defense in depth: Database filtering and cryptographic isolation are independent controls - both must fail simultaneously for cross-tenant access to be possible
  • No shared encryption keys: Workspace A's encryption key set is never used to encrypt Workspace B's data, regardless of which server processes the request
  • No staff data access: No one at Botmakers LLC can view, edit, or manually inspect your data - all processing is handled automatically and securely
  • Audit trails: All decryption operations are logged to Azure Monitor. All access to systems, APIs, and user data processing activities is logged with timestamped details, retained for audit and compliance purposes

Common Questions

Can Instafill employees read my documents?

No. No one at Botmakers LLC has access to view, edit, or manually inspect your data. All processing is handled automatically and securely. Source text is decrypted in memory only during an active fill operation and is never logged or stored in plaintext.

For regulated industries requiring contractual limitations documented in writing, this can be addressed in a BAA or DPA. Contact sales.

What happens if there's a bug in the workspace filter?

The cryptographic layer provides defense in depth for exactly this scenario. If a query somehow returned records from the wrong workspace, those records would be encrypted with the wrong workspace's key. The application would attempt decryption with the requesting workspace's key and fail - the data would be unreadable.

The likelihood of both the database filter and the cryptographic isolation failing simultaneously is extremely low. The systems are independent and failure modes do not compound.

Are workspaces within the same organization isolated from each other?

Yes. Each workspace has its own workspaceId and its own encryption key set, regardless of whether workspaces belong to the same organization. An Admin of Workspace A within an organization cannot access the forms, sessions, or sources of Workspace B in the same organization unless they are also a member of Workspace B.

What is the scope of API key access?

API keys are workspace-scoped. An API key generated in Workspace A can only access Workspace A's data - sessions, forms, profiles, and batch jobs. The key cannot be used to query other workspaces, even within the same organization.

See API Key Management for full detail on key creation, rotation, and revocation.

Related Features

Ready to get started?

Start automating your form filling process today with Instafill.ai

Try Instafill.ai View Pricing