Compliance and security
Compliance and security posture
Here is our AI agent compliance posture, in plain language. It maps DataShield to the rules that gate agent deployments. It shows what we can prove today, and what is still in progress. We do not put a certification on this page before it is true. Want the full, control-by-control detail? Request Trust Center access. It sits behind an NDA.
Alignment and mapping are live today. Formal certifications are on the roadmap and labeled honestly.
How to read this AI agent compliance posture page
Two words do a lot of work in vendor forms. So we use them with care. Aligned and mapped mean this: one DataShield part meets one rule. We can show you how. Certified means an outside auditor signed off on it. We are not SOC 2 or ISO 27001 certified yet. You will not see those words used as done, anywhere on this site. Here is what we offer instead. Most vendors cannot match it: an audit trail you check yourself, not one you take on trust.
How the mechanisms map to the regulations
HIPAA Security Rule
§164.312(b) audit controls map to our SHA-256 hash chain, with Ed25519-signed checkpoints. §164.312(a) access control maps to per-tool-call authorization, with mid-session revocation. §164.514 de-identification maps to tokenization at ingest, plus quasi-identifier generalization. A BAA conversation is welcome. Healthcare deployments are why the data plane exists.
EU AI Act
Article 12 automatic, lifetime event logging maps to our tamper-evident audit chain. Process supervision keeps the evidence plane up. So gaps stay small and in view. Article 26(6) six-month retention maps to retention you control. This is an engineering and compliance map, not legal advice.
GDPR
Article 17 erasure maps to crypto-shred. Destroy a subject's key, and re-identification turns impossible. The audit chain still checks out. EDPB Opinion 28/2024 names pseudonymization as a fix. That is the reversible-tokenization pattern DataShield uses. It is not the one-way redaction that wipes data for every downstream use.
Certification status, stated honestly
SOC 2 Type II
On the roadmap, not yet started. Here is our stance for now: you can check the audit chain on your own. That beats an annual sign-off on our org chart, for evidence you can trust. We know procurement still needs the report. It is on the roadmap.
Penetration testing
Internal red-team reviews happen on every release. We track findings to closure. A published third-party assessment of the audit-chain claims is on the way. We will not call the product pen-tested until it is.
What we will not claim early
Nothing appears on this site before it is true. That is the same discipline our messaging went through. See a certification badge here? It links to the report.
Key custody and deployment
You hold the keys
In self-hosted and dedicated single-tenant deployments, tokenization (HMAC) and audit-signing (Ed25519) keys are yours, held on your instance. You set the tokenization key as a secret. The signing key lives in a key directory only the service reads. A leaked key can unmask deterministic tokens. So key custody is a top deployment topic, not a footnote. Signing runs through one custody choke point, with kid-rotated keys and fail-closed checks. KMS or HSM custody is a built seam in Auth. It is not a shipped integration.
Where it runs
Self-hosted or on your own infrastructure, with your keys. The evidence stays in your control. You can check the audit chain on your own, without us. That is the point. You should not have to trust the vendor under audit.
Source escrow
Regulated-industry design partners get a source-escrow option and direct engineering access. That is a real answer to an honest question: will an early-stage vendor exist in three years?
Questions a vendor-risk team will ask
The short, honest answers. The Trust Center has the long ones.
Are you SOC 2 certified?
Not yet. SOC 2 Type II is planned, not yet started. Meanwhile, you can check the audit chain on your own. Design partners get source escrow. We do not show a badge we have not earned.
Can you prove your logs were not altered?
Yes, and you can check it without us. The audit trail is a SHA-256 hash chain, with chained Ed25519-signed checkpoints. A check finds tampering, insertion, deletion, and truncation. Try a sample chain yourself at /verify.
Who holds the encryption and signing keys?
You do. In self-hosted and dedicated single-tenant deployments, the keys sit on your instance, under your control. KMS or HSM custody is a built seam, not yet a shipped feature. GDPR erasure works by destroying per-subject keys. Backups must follow the same custody rules, or the erasure is just theater. We write this down at deployment.
How do we get the full detail?
Request Trust Center access. It sits behind a mutual NDA. Inside: the threat model, control-by-control mappings, key handling, incident response, and the hard questions, in full. It is invite-only, not public.
The full detail lives in the Trust Center, behind an NDA. Control mappings, threat model, key handling, and the hard questions, answered in full.
Request Trust Center accessYou've seen the proof
Ready for a number? Scope your deployment and we'll price it against your own economics.
Get your quote →