Security that starts with where the product runs.
The most important security property of Data.co is architectural: your content is processed in your infrastructure, under your network controls, and never sent to us. This page covers the controls in the product, how we secure our own hosted service, and how to report a vulnerability.
Built into Data.co Control.
Fail closed
No valid license, an invalid policy set, an unknown model or tool, or an audit record that cannot be written all result in a deny.
Identity everywhere
Every request carries a verified identity, including agents and the users they act for. Agent tokens are stored only as SHA-256 hashes.
Egress guard
The runtime connects only to the inference endpoints and MCP servers you configure. Any other destination is rejected before a socket opens.
Secret isolation
Upstream credentials are referenced by environment variable name and held by the gateway, never passed to models or agents.
Tamper-evident audit
Hash-chained, synchronously written audit records that can be verified online or offline. The runtime will not start if the log's tail fails verification.
Hardened container
The runtime runs as an unprivileged user on a read-only root filesystem, with Linux capabilities dropped in the reference compose file.
How software, licenses, and policies reach your environment.
- 1
Checksummed images
Runtime images are distributed as archives with SHA-256 checksums that you verify before loading, including after transfer across an air gap.
- 2
Signed licenses
License files are Ed25519-signed and verified offline against a public key whose key ID you confirm out of band with your Data.co contact.
- 3
Signed policy bundles
Policies can be delivered as bundles signed with a key you generate and hold. The runtime accepts only bundles signed by keys you list, and runs their tests before swapping them in.
- 4
Rollback
The previous policy files are kept when a bundle is applied, and a failed reload leaves the last valid set active.
Controls on app.data.co and api.data.co.
The hosted plane holds accounts, roles, API key hashes, licensing, billing state, and Control configuration. It does not receive customer content.
| Area | Control in place |
|---|---|
| Sign-in | Verified email required; 12-character minimum passwords; TOTP two-factor and passkeys; organizations can require two-factor for members |
| Enterprise SSO | OIDC and SAML, configurable only by organization owners and admins; denied attempts are audited |
| Brute force | Database-backed rate limits on sign-in, sign-up, password reset, and two-factor verification |
| Tenant isolation | Organization taken from the session or verified API key, never from the client; isolation covered by automated tests |
| API keys | Shown once; stored as a prefix and SHA-256 hash; scoped, expirable, and revocable |
| Audit | Security and staff actions written to a table whose triggers reject updates and deletes |
| Secrets | Organization secrets encrypted with AES-256-GCM and write-only in the interface |
| Transport and headers | TLS with HSTS, framing denied, content sniffing disabled |
| Payments | Handled by a payment processor; card data does not touch our systems |
Found a security issue?
Report it privately through data.co/contact with "Security" in the subject. Our security.txt at /.well-known/security.txt lists the same channel. We will acknowledge receipt, investigate, and keep you informed. Please do not access data that is not yours, degrade services, or test against customer deployments.
Questions buyers ask
What network access does a deployment need?
None to operate. Optional outbound access to app.data.co enables online licensing and update checks; air-gapped deployments use offline license files and signed bundles.
Who manages encryption keys?
In your deployment, you do. The runtime stores its audit log and state on volumes you provide, so disk encryption and TLS termination use your own key management. Policy signing keys are generated and held by your team.
What does the audit log contain, and what does it leave out?
Identities, resources, actions, decisions, policy IDs, explanations, dataset names, and argument keys. It never stores prompt text, tool argument values, documents, or records, so the log does not become a second copy of sensitive data.
How should we back up a deployment?
Copy rotated audit segments as they appear, snapshot the active log and the approvals store regularly, and record the latest audit head somewhere separate, such as a ticketing system or write-once storage, so a wholesale rewrite would also be detectable.
Do you perform penetration testing?
Results of third-party testing have not been published yet. Status will be posted on the trust center. Customers are welcome to test their own deployments under their usual process.
How are security patches delivered?
As new versioned images with release notes and checksums. Managed services customers can have patching handled under their agreement.
See it against your own use case.
A 30-minute technical walkthrough, policy simulation on your scenarios, and a deployment recommendation for on-prem, private cloud, or hybrid.