Security model and privacy

This page describes what the current code stores, what it never stores, how keys are held and how tenants are kept apart. It is a description of the developer preview, not a certification.

Trust boundaries

• Axiom decides; the application commits. Gateway and the embedded SDK authenticate the agent, check its grant and policy, collect approvals and claim execution once. The receiving application still checks tenant access and business rules and is the only source for "the refund was posted", which it states in a signed outcome attestation.
• An approval never executes anything. Only the original agent's authenticated resume, after a fresh grant and policy check, can claim execution. No MCP tool or API lets a person approve without the authenticated approval page or a connector readback.
• One executor per action. Execution is a single conditional claim. Embedded-SDK services are claimed only by the provider; after a cutover only the customer-hosted gateway that holds the project's executor flag may claim. Every Axiom path (REST, HTTP and MCP proxies, Axiom MCP server) enforces this.
• Notifications carry no authority. Wake events contain IDs, a timestamp and a sequence number; receivers must read authenticated status.
• Each claim names its signer. Axiom signs its own observations (observation key); the provider signs outcomes with its own key; dispatch authorisations use the grant key. See Receipt and event formats.

Authentication

Principal	Mechanism
Agent	OAuth 2.1 client_credentials with private_key_jwt (RFC 7523) signed by an enrolled key, or a workload identity token (SPIFFE JWT-SVID or OIDC) from an issuer in the tenant's trust profile. A DPoP proof (RFC 9449) is mandatory; the 5-minute token is bound to the key thumbprint and every call carries a fresh proof bound to method, URL and token hash. Proof jtis are single use.
Person (console)	Passkeys (WebAuthn), email magic links (15 minutes) or enterprise OIDC SSO. Sessions are opaque random tokens; cookies are HttpOnly; Secure; SameSite=Lax; unsafe methods also need the x-axiom-csrf header.
Person (MCP client)	Authorization code + PKCE (S256 only) with dynamic client registration and RFC 9728 metadata. Browser sessions are not accepted on the MCP endpoint. Refresh tokens are single use.
Provider / CI	Project API key (axk_…) with explicit scopes. In embedded-SDK mode the provider forwards the agent's token and DPoP proof; Axiom checks the proof was made for the provider's own origin, so a provider cannot replay it against Axiom.
Customer-hosted gateway	Compact JWS signed by the gateway's registered key, iat within ±120 seconds, jti single use.

What is stored

• Hashes, not secrets, for access and refresh tokens, sessions, API keys, magic links, invitation tokens and OAuth codes (SHA-256). A database leak cannot be replayed as a credential.
• Public keys and credential lifecycle rows for agents (thumbprint, kind, validity, status, superseded-by, revocation reason). The agent's stable ID survives rotation.
• The canonical action: tenant, agent, service, operation, resource and the declared material fields only, plus the approver-facing summary and the optional free-text intent.
• Approval decisions with approver identity, the digest they approved, how it was verified and the native record reference, plus Axiom's signed observation.
• Receipts and their salted disclosures; the action timeline; the audit stream delivered to SIEM.
• Outcome attestations and the provider's detail fields (returned to the agent as outcome.result).
• For MCP proxy calls only: the tool arguments and the upstream tool result, so a client that reconnects can resume and receive the result. HTTP proxy request and response bodies are not stored.

What is never stored

• Agent and provider private keys. The quickstart generates the sample agent's key in the browser, and the CLI writes keys to the local machine with 0600 permissions; Axiom only receives public keys and proofs of possession.
• The non-material payload passed on submit or resume: it is forwarded to the upstream on dispatch and dropped.
• Prompts, model reasoning and payment credentials: the contract has no field for them.
• Connector and upstream secrets in configuration: fields marked secret must be given as a secret reference (env:NAME, or Secret Manager on GCP), never as a value.

Privacy controls

• Approver visibility. A material field marked approver_visible: false is hidden from the approval page but still bound by the digest.
• Redacted exports. ?reveal= limits disclosed fields; the signed commitments still prove each disclosed value. Commitments are salted, so a low-entropy hidden field (an amount, a currency) cannot be confirmed by guessing against a plain hash.
• Enrollment terms. An organisation that adopts a project receives metadata or full visibility and none, since_enrollment or all evidence, as the project owner accepted.
• SIEM redaction. Any dotted field can be dropped per destination, except id and seq.
• Retention. Receipts carry retain_until from the plan's history days and are deleted by the maintenance sweep after it, for completed actions, unless they are on legal hold.

Key custody

• One signing key per role: identity, grant, observation, policy, event. Each signature carries a kid.
• Private keys never live in the database. A key row's private_ref points to a Worker secret (env:AXIOM_KEY_<ROLE>) or a Cloud KMS key (kms:…); a composite resolver can mix both per role. Customer-held keys plug in through the same Signer port.
• Public keys stay in the JWKS after rotation (status retired), so historical receipts keep verifying; revoked keys are marked revoked. Verifying an old signature and checking a key's current status are separate steps.
• Agent certificates, when requested, are issued under a purpose-specific client-authentication profile and chain only to the anchors at GET /v1/public/ca/trust-anchors, never to the Web PKI.

Tenant isolation

• Tenant and actor are always derived from the authenticated principal or the authoritative record. A request body naming another tenant is refused (tenant_mismatch).
• Status, resume, cancel and receipts are visible only to the original agent (and to people with evidence access in the project or tenant). Everyone else gets 404: an action ID alone never proves permission.
• List, search and export queries take their scope from role memberships in the repository layer, not the UI. An email domain match never grants access to a project; SSO grants at most an organisation role configured on the connection.
• The Gateway only forwards mapped routes and tools, always to the service's configured upstream origin; a crafted path cannot redirect it. Public services fetch only public URLs through an SSRF policy and are rate-limited per client address.
• Webhook URLs must use HTTPS outside development.

Known limitations in this preview

• Tenants and organisations record a region (us or eu), but one deployment serves both; per-region stacks are a deployment decision (see Deployment).
• The trust profile's status_freshness_seconds and accepted_issuers are stored but not yet enforced; gateway bundles use a fixed 300-second freshness window.
• An enrollment's retention_days term is recorded but not enforced; receipt retention follows the project's plan.
• The connector webhook endpoint (POST /v1/connectors/:id/webhook) is unauthenticated by design. Its body is never trusted for a decision: it only queues a server-to-server readback in which Axiom authenticates to the native system and verifies approver, digest and deadline itself. It is rate limited to 60 calls per minute per connector so it cannot be used to generate unbounded readbacks.
• The customer-hosted gateway runtime and the Kong, Apigee and AWS API Gateway adapters are not in the repository yet; the fleet, heartbeat and bundle API they will use exists.