Trust · Security posture
Xybern is not alongside your AI systems. It is inline. Our security architecture protects the enforcement layer itself, the system that decides whether every AI action in your organisation runs or does not run.
The inline security question
Because Xybern sits directly inside your AI execution path, not alongside it, there is a security question no other AI vendor faces: what happens to your AI operations if Xybern itself is compromised or unavailable? We answer this question explicitly, because every enterprise architect asks it within five minutes.
If Xybern is unreachable, AI actions do not execute.
Actions queue at the enforcement boundary. Nothing slips through. There is no fail-open mode by default. Zero enforcement gaps, even during incidents.
A breach of one workspace cannot reach another.
Workspace keys are scoped at the HSM level. There is no shared key material between tenants. Cross-workspace access returns a hard 403, not a policy rejection, an architectural impossibility.
Xybern evaluates action metadata and policy. Not content.
The verification engine receives the proposed action type, the agent identity, the trust context, and the applicable policy set. It does not receive or store the content of the action itself.
Encryption architecture
Most encryption documentation describes how data is protected at rest and in transit. Ours shows you exactly how a single AI action is encrypted at every stage, from the agent call into Xybern, through the evaluation engine, to the vault entry. Each hop uses a different encryption standard for a different reason.
Every hop encrypted · no plaintext at rest · customer keys at the vault layer · content never persisted by the evaluation engine
TLS 1.3 everywhere
Every ingress and egress path uses TLS 1.3 with modern cipher suites. Certificate pinning available for private deployments.
AES-256 envelope encryption
Data at rest uses envelope encryption with scheduled key rotation. Keys evolve without disrupting existing vault entries.
Field-level protection
Selective encryption for sensitive fields within enforcement records. Zeroized when the evaluation pipeline completes.
Isolation tiers
Tenant isolation in Xybern is not a configuration option added after the fact. It is the default state. Every workspace is isolated from every other workspace at the storage, compute, networking and queue layer from the moment it is provisioned.
| Layer | Standard | Enhanced | Dedicated | Dedicated + HSM |
|---|---|---|---|---|
| Storage | Tenant-scoped buckets | Account-level segmentation | Per-tenant accounts | Per-tenant accounts + HSM-backed keys |
| Compute | Tenant tags + context guards | Isolated workers and queues | Dedicated autoscaling pools | Dedicated pools + secure enclaves |
| Networking | Scoped security groups | Private link + IP allowlists | Dedicated VPC/VNet peering | Dedicated VPC + private endpoints only |
| Caches / Queues | Namespace isolation | Per-tenant shards | Dedicated clusters | Dedicated clusters + encrypted at rest with CMK |
Key management lifecycle
Xybern supports customer managed keys (BYOK) via your existing KMS or HSM. The key lifecycle, provisioning, rotation, revocation and attestation, is fully auditable, with every key event recorded permanently in the provenance vault.
Provision
Establish CMK in your KMS or HSM
Link to regions, bind to projects. Xybern generates workspace-scoped derived keys from your root CMK. You retain full ownership of the root.
Rotate
Scheduled or on-demand rotation
Envelope re-wrap with signed rotation event. Existing vault entries remain readable. New entries use the rotated key. No disruption to enforcement operations.
Revoke
Immediate access revocation
Revocation takes effect in under 1 second. All in-flight requests using the revoked key are rejected. Background zeroization of derived key materials begins immediately.
Attest
Exportable evidence for audits
Every key provisioning, rotation and revocation event is recorded in the provenance vault with a SHA-256 hash anchor. Export Merkle proof of the complete key lifecycle for any regulatory audit.
Important — key revocation and vault entries
When a key is revoked, existing vault entries written under that key remain readable via the revoked key for audit purposes, this is required by law in most regulated jurisdictions. No new enforcement entries can be written using the revoked key. The revocation event itself is recorded permanently in the vault under the active key, giving you a tamper-evident record of exactly when the key stopped being valid.
Compliance and certifications
Annual third-party audit of security controls, availability, and confidentiality. Report available to enterprise evaluators under NDA.
Data processing agreements available. EU residency option ensures no transatlantic transfer. Right to erasure supported for non-vault data.
Every API verification recorded in the provenance vault, SHA-256 hashed, HMAC-signed, chain-linked. Tamper-evident by construction, not by policy.
Regular third-party penetration testing with full remediation tracking. Results available to enterprise security teams during evaluation.
Get started
We share detailed architecture documentation, penetration test reports, and SOC 2 Type II certification directly with security and procurement teams. No NDA required for the initial architecture review.
