Threat model and security posture

The AI agent threat model

We assume the worst. Attackers prompt-inject agents. They steal tokens. MCP servers turn hostile, or attackers poison them. They compromise admins. Logs are a target, because logs are the evidence.

Here is each threat, next to the thing that holds it in check:

• Injected agent → a scope ceiling bounds what any agent can do, no matter what it was talked into. Authority tiers gate the risky tools. The blast radius is the token, not the account.
• Stolen token → the scope ceiling caps it when we issue it. Once you spot the theft, mid-session revocation kills it on the next call.
• Malicious MCP server → we tokenize governed datasets at ingest. So a hostile tool reads tokens, not identifiers. To detokenize, you need separate, privileged authorization.
• Compromised admin → config changes go through propose/approve governance, with security floors no one can waive. Break-glass access stays scoped. It auto-revokes. It lands in the tamper-evident chain.
• Log tampering → the hash chain has signed checkpoints. Any change shows up, and the report names which kind it was. Verify it yourself

Key management

In self-hosted and dedicated single-tenant setups, you hold the keys:

• Tokenization keys (HMAC): yours, held in your environment. It is a secret you set, or a machine key on your instance, not in a KMS today. Rotation re-keys every token, so we plan it with you instead of pretending it is free. A leaked key can unmask deterministic tokens. So key custody is a top deployment topic, not a footnote.
• Audit signing keys (Ed25519): held in a key directory on your instance that only the service reads. Keys rotate by kid. Checks fail closed on an unknown key. Auth has a KMS/HSM custody seam built in. The hardware side has not shipped.
• Erasure: GDPR crypto-shred works by destroying the per-subject key. Key backups must follow the same custody rules, or erasure is just theater. So we write down the backup path when we deploy.

Signing-as-a-service (rolling out): audit signing already runs through one custody choke point, with kid-rotated keys and fail-closed checks. We are rolling out KMS/HSM-held, non-exportable signing keys across the platform, so no service in the stack ever holds private key material.