Security primitives
Security primitives for enterprise AI systems.
Built for auditors. Designed for production speed.
Your auditor verifies every control independently. Signed policy packs, tamper-proof audit records, per-tenant isolation, and customer-managed keys. Nothing that slows your inference path.
Identity through SAML 2.0 or OIDC, then a tenant claim in a signed, expiring JWT, then database row-level security enforced by Postgres (not the app), then per-class PII policy handled by PII Sentinel in strict, reversible, or flag-only mode, then an append-only audit write that is WORM, SHA-256 Merkle chained, and fsynced across three zones. A request missing any gate returns zero rows with a typed RFC 7807 error and the same request id that threads gateway, orchestrator, agent, and DB.
Ninety-day default rotation. Rotation events write to the audit log. Per-tenant keys; no shared KMS keyring across tenants. Break-glass rotate under an hour.
Five-minute window on every signed webhook. Timestamp plus HMAC-SHA256. Subscribers verify; replays outside the window return 401.
Internal service-to-service mTLS. Certs rotate automatically; no manual renewals or outages.
API keys stored as SHA-256 hashes, scoped to tenant and capability set. Shown once on creation.
Agents sandboxed. Typed IPC only. No ambient filesystem or network access. Resource budgets per agent per tenant.
Cryptography
At rest and in flight
A
At rest
AES-256-GCM, KMS-managed keys
Tenant data, prompts, outputs, and evidence packs encrypt at rest with AES-256-GCM under KMS-managed keys. Per-tenant envelope keys prevent cross-tenant key reuse. Rotation events write into the audit log and hit the default ninety-day cadence unless a tenant requests sooner.
B
In flight
TLS 1.2+ with internal mTLS
Every external call rides TLS 1.2 or 1.3 with pinned cipher suites. Internal service-to-service traffic uses mTLS with certs issued by an internal CA and rotated automatically before expiry. No manual cert renewals, no expiry outages.
C
Keys
API keys stored as SHA-256 hashes
API keys show once at creation and store as SHA-256 hashes. Each key binds to a tenant and a capability set, so a leaked key cannot widen its own scope. Rotation is self-service from the admin console and every use and rotation is logged.
D
Webhooks
HMAC-SHA256 signed with replay bound
Every webhook carries a timestamp header and an HMAC-SHA256 signature over the body. The replay window bounds at five minutes, and subscribers verify both the HMAC and the timestamp. Rejections return RFC 7807 problem documents so integrators know why a payload was dropped.
Tenant isolation
Row-level security, end to end
Tokens sign with a rotating platform key, carry tenant_id and capability claims, and expire in fifteen minutes. The gateway rejects unsigned or stale tokens with RFC 7807 before a handler ever executes. Refresh rotation prevents replay across sessions.
A Postgres RLS policy reads tenant_id from the JWT claim inside current_setting and restricts every row to the caller tenant. A wrong claim returns zero rows with no error leak. Applied to every table holding tenant data, including evidence packs and audit events.
Reads and writes emit structured events keyed on tenant_id and request id, with the actor identity, the policy version, and the source service. Break-glass paths write with a reason string and land in a dedicated audit slice reviewed weekly.
create policy tenant_isolation on public.assessments using ( tenant_id = ( current_setting('request.jwt.claims')::jsonb #>> 'tenant_id' )::uuid ); -- wrong claim returns zero rows
Identity
How humans and services authenticate
Short-lived access tokens, long-lived refresh with rotation. Revocable from the admin console.
Okta, Azure AD, Ping, Auth0, Google Workspace. Tenant-scoped metadata.
TOTP available today. WebAuthn planned. MFA-required roles set per tenant policy.
SHA-256 hashed, scoped to tenant and capability set. Self-service rotation.
Mutual-TLS between internal services where supported. Certificates auto-rotate.
Admin override requires a documented reason and writes to the permanent audit log.
PII handling
Personal data, handled to your rules
- Names, emails, phone numbers
- Street addresses, government IDs
- Payment cards, health indicators
- Biometric hints, login credentials
- Minors indicators
- Strict: replace with a token, non-reversible
- Reversible: vault with scoped keys and audit
- Flag only: pass through with a tag, no change
- Per tenant, per class, per channel
- Confidence scored on every match
Audit and evidence
Every decision is attributable
A
Append-only log
Actions, approvals, overrides
Every action, approval, and override writes into an append-only log. Entries are SHA-256 Merkle-chained with checkpoints every five minutes, fsynced to disk before acknowledge, and replicated across three zones. Tampering with any entry breaks the downstream chain and surfaces on the next verification pass.
B
Stable request ids
One id, every layer
A single request id threads the gateway, orchestrator, agents, and database. Support and audit see the same events from the same trace, and OTel spans let you replay a request across services without correlating by timestamp.
C
Evidence packs
Signed and timestamped bundles
Evidence packs roll up the audit log, policy versions, and agent outputs into signed, timestamped bundles preformatted for EU AI Act Art. 10, SOC 2, NIST AI RMF 2.0, and ISO 42001 section 8.4. Packs regenerate automatically when the registry changes so auditors never get stale evidence.