Security

How DeepCell protects the documents, credentials, and data entrusted to it.

Last updated
SOC 2 Type II
Observation period underway
Model training
Your content is excluded
Report a vulnerability
hello@deepcell.net

DeepCell is designed to protect the documents and data that organizations entrust to it. This page sets out the controls in place across our infrastructure, our application, and our AI processing, in sufficient detail to be independently reviewed. Where a control is not yet in place, this page states so.

This page describes engineering practice. The Privacy Policy is the binding statement of what we collect and why, and the two documents are maintained in agreement.

1. Summary#

  • Documents are held in an open, portable format and may be exported in full at any time.
  • We maintain zero-retention agreements with the AI model providers we use. Your content is not retained by them and is never used to train models.
  • We retain agent run traces, which include prompts and document fragments, for diagnostic and operational purposes. Section 4 describes this in full.
  • SOC 2 Type II: the observation period is underway and no report has been issued. Section 9 states our current position.

2. Format openness and portability#

A .deepcell document is a single self-contained file containing values, formulas, constraints, reasoning, and revision history. The format is open and text-based.

This carries a direct security consequence: no part of your work exists solely within our service in a form you cannot retrieve. Documents may be exported, inspected, compared across revisions, and retained in your own systems. An organization that discontinues use of DeepCell retains a working document rather than a static export.

3. Local clients and self-hosted deployment#

The deepcell command-line client and the stdio MCP server run on your own machine, which keeps credentials local and removes third-party agent hosts from the request path.

The boundary should be stated precisely. By default these clients are thin pass-throughs to the DeepCell API, and document contents are transmitted to our service; they do not constitute an offline mode. Where data residency requires it, the full stack — API, database, storage, and agent runtime — may be self-hosted, and the client's DEEPCELL_API_URL directs it to your own deployment. Please contact us to discuss this deployment model.

4. AI models and your data#

The DeepCell agent transmits the content it is operating on to AI model providers in order to perform the requested work. This section describes that processing in full.

Model providers. We operate under zero-retention agreements. Prompts and model inputs and outputs are not retained by the provider once a request has been served, and are never used to train models. Providers are described by function in Privacy Policy §7.2; we will identify them, together with their processing regions, on request.

Run tracing. We record traces of agent runs for diagnostic purposes and to improve the agent. These traces contain prompts, document fragments, model inputs and outputs, and run state, and are retained by the tracing provider. This is the one category of content stored outside the application by design, and it is disclosed here for the same reason it is disclosed in the Privacy Policy. Tracing is governed by deployment configuration and may be disabled in a self-hosted deployment.

Document conversion. Export to .xlsx or .pptx transmits the contents of the exported document to a conversion service, which renders it and does not retain it.

5. Authentication and access control#

Passwords are hashed using bcrypt. They cannot be recovered by us and are never transmitted by email.

API keys carry a dck_ prefix. Only a SHA-256 hash of the key is stored; the key itself is displayed once, at creation, and cannot subsequently be retrieved. A short prefix, such as dck_Ab3x, is retained so that keys may be distinguished in a list. Keys may be revoked at any time from Settings → API keys.

Agent connections use OAuth 2.1 with PKCE. Three properties of that flow are deliberate, and each is covered by a regression test:

  • No refresh token is exposed to browser JavaScript. Consent completes through a server-side device-code exchange, so all token issuance remains server-side and the user's own web session is not rotated when an agent connects.
  • Completing an authorization requires the consenting user's own bearer token. A session identifier alone cannot bind an identity, as it is transmitted in query strings and is therefore recorded in access logs and browser history.
  • The consent screen displays the registered redirect host. Client registration is open, so an application's name and homepage are self-declared; the redirect target is the only field a client cannot misrepresent.

Destructive commands are unavailable over MCP. Account export and deletion, authentication and registration, and repository synchronization commands cannot be invoked through an agent tool call. Account erasure requires deliberate action at a terminal and is not reachable by prompt injection.

6. Storage, encryption, and retention#

Traffic is encrypted in transit using TLS, and stored documents are encrypted at rest.

Network identifiers in audit records are removed on a fixed schedule rather than retained indefinitely: 90 days for anonymous demonstration visitors, and 180 days for all other users. Audit records themselves are retained in de-identified form, as the record that an action occurred is what gives an audit log its value.

7. Data export and account deletion#

Both operations are self-service:

  • deepcell account export returns a complete JSON copy of the account, comprising profile, projects, document index, share links, API key metadata, quotas, sessions, threads, and activity. Credential hashes are excluded by design.
  • deepcell account delete erases the account. It requires confirmation of the account email address, and of the password where the account has one. Where a shared project would be left without an owner, the operation is refused rather than completed.

8. Service providers#

We describe service providers by function rather than by name, consistent with the Privacy Policy: the composition of the list changes with our features and service regions, and an embedded list of names becomes outdated faster than the document is revised. The functional breakdown, the data each provider processes, and our cross-border safeguards are set out in Privacy Policy §7.

We maintain a current register of sub-processors, including their identities and processing regions, which is available on request.

9. Compliance status#

SOC 2 Type II — observation period underway. No report has been issued. We do not describe DeepCell as SOC 2 certified, compliant, or audited, and will not do so until a report exists. The report will be made available under NDA once issued.

Data protection. GDPR and PIPL handling, the legal bases on which we rely, our standard contractual clauses, and the procedure for exercising your rights are set out in the Privacy Policy. A data processing agreement is available on request.

10. Reporting a vulnerability#

Please write to hello@deepcell.net with SECURITY in the subject line, including sufficient detail to reproduce the issue.

We aim to acknowledge reports within 3 business days and to provide updates until the issue is resolved. Where a report is made in good faith, allows reasonable time for remediation before public disclosure, and avoids privacy violations, service degradation, and destruction of data, we will not pursue or support legal action in respect of that research.

Automated scanning against production systems is not permitted, and testing must not access or modify data belonging to other users.

11. Contact#

For a security review, the sub-processor register, a data processing agreement, or a self-hosted deployment, please contact hello@deepcell.net.


Website: deepcell.net