Threat model and security posture

Every assumed threat, mapped to a mechanism

Threat model

We assume: agents can be prompt-injected; tokens can be stolen; MCP servers can be malicious or poisoned; administrators can be compromised; and logs are a target precisely because they're evidence.

Controls mapped to those assumptions:

• Injected agent → scope ceilings bound what any agent can do regardless of what it was talked into; authority tiers gate sensitive tools; blast radius is the token, not the account
• Stolen token → scope ceiling caps it at issuance; mid-session revocation kills it on the next call once detected
• Malicious MCP server → governed datasets are tokenized at ingest — a hostile tool reads tokens, not identifiers; detokenization requires separate privileged authorization
• Compromised admin → configuration changes pass propose/approve governance with non-negotiable security floors; break-glass access is scoped, auto-revoking, and lands in the tamper-evident chain
• Log tampering → the hash chain with signed checkpoints makes alteration detectable and classifiable — verify it yourself

Key management

In self-hosted and VPC deployments, you hold the keys:

• Tokenization keys (HMAC) — yours, in your KMS/HSM; we document rotation. Deterministic tokens are a linkability oracle if the key leaks, which is why key custody is a first-class deployment topic and not a footnote
• Audit signing keys (Ed25519) — KMS/HSM signing choke point; kid-keyed rotation, verification fails closed on unknown keys
• Erasure — GDPR crypto-shred works by destroying per-subject keys; backups of key material follow the same custody rules or erasure is theater, so we document the backup path explicitly during deployment

Signing-as-a-service (rolling out): audit signing already runs through a KMS/HSM choke point with kid-rotated keys and fail-closed verification. Non-exportable signing keys — where no service in the stack ever holds private key material — are rolling out across the platform.

MCP security best practices — applied to our own servers

Our MCP surfaces are tokenized by Auth-issued MCP tool tokens (RFC 9068), bound to scope ceilings and authority tiers, rate-limited and metered per agent, and audited into the chain. Services bind to localhost behind TLS-terminating reverse proxy; streamable HTTP transport; no stdio servers on production hosts.

Vulnerability disclosure

Report vulnerabilities to support@myorg.ai — machine-readable contact in /.well-known/security.txt (RFC 9116). We commit to acknowledgment within 2 business days and a substantive response within 10. Safe-harbor: good-faith research against your own deployment or our published demo surfaces will not be met with legal action.

Honest status

• SOC 2: not yet certified. Our position until then: the audit chain is independently verifiable by you, which is a stronger property for evidence integrity than an annual attestation of our org chart — but we know procurement needs the report, and it's on the roadmap.
• Penetration test: not yet externally tested; internal adversarial reviews are part of our release process and their findings are tracked to closure.
• Certifications we will not claim early: nothing appears on this site before it's true. That's the same discipline our messaging went through.
• Design partners: regulated-industry design partnerships come with source-escrow options and direct engineering access. Start with a quote.