When a team is evaluating a document AI tool, the security questionnaire shows up early. One question that comes up almost every time: _how do you keep our documents apart from another customer's?_ This is a quick walkthrough of how Docusift answers it, what isolation actually means in our model, and the parts that are commonly misunderstood.
The default: workspace-scoped storage
Every workspace on Docusift gets its own scoped storage namespace. Uploads go to a dedicated key prefix that is bound to the workspace identifier; the application layer enforces that scope on every read, write, and delete. There is no UI or API surface that lets a workspace request bytes outside its own scope, period.
In practice that means:
- A user in Workspace A can never list or fetch a document from Workspace B, even if they guess the document ID. - Internal services (the Review queue, the API, the email-intake pipeline, the integration sync) all resolve the workspace identity from the authenticated request and only ever pass it through scope-aware handles. - Audit logs and access checks live on the same workspace boundary, so investigations stay neatly partitioned.
For most customers this is the right level of isolation. It is the same model the major SaaS platforms run on, and it lets us deliver the same feature set to a 5-person team and a 5,000-person team without forking infrastructure.
The Enterprise option: bring your own bucket
Some customers — regulated industries, customers with a data-residency policy, customers who want a hard infrastructure boundary — need more than logical isolation. For those workspaces, Docusift supports plugging in your own object storage bucket. The flow is:
1. Provision an S3 bucket (or any S3-compatible service) in the region of your choice. 2. Add the credentials in Settings under Data & Storage. 3. New uploads land in your bucket. We never see the bytes outside of the request that processes them.
Two things are worth being explicit about:
- Split history. Documents uploaded before you switched live in the platform default bucket; documents uploaded after live in yours. We record the storage location per document, so reads always go to the right place. We do not auto-migrate historical objects — that has to be a deliberate decision, and most customers leave history in place. - Credentials are encrypted at rest. When you save bucket credentials in Settings, they are encrypted with a per-environment key before they touch the database. The decrypted form only exists in process memory while a request is being served.
What isolation does not mean
A few clarifications we end up making during procurement reviews:
- Isolation is not the same as encryption. Documents are encrypted in transit and at rest regardless of whether you bring your own bucket. Workspace isolation is about access scope; encryption is about confidentiality at rest. They solve different problems. - Logical isolation is enforced by the application, not by separate infrastructure. If your compliance posture requires a separate data plane per customer, the bring-your-own-bucket option is the right tier — that is what it is designed for. - Bringing your own bucket does not change processing. Your documents are still classified and extracted by the same pipeline; the only thing that changes is where the bytes live.
What this enables
Once storage is workspace-scoped, every related capability follows: per-workspace retention windows, regional placement, dedicated backends for compliance audits, one-click deletion that actually deletes. The work was getting the boundary right; everything on top is policy.
If you are evaluating Docusift against a security review, our security page has the longer-form answer covering subprocessors, encryption, and our compliance posture. For anything not covered, reach out — we answer security questionnaires within a few business days.