Nothing leaves your network that you did not configure.

The consequence is testable rather than rhetorical. If your network policy allows outbound connections only to your model providers, your tool servers and your webhook receivers, Token Observe functions completely — adding your identity provider and your sink host only if you enabled them. A delivered image can run fully air-gapped and the dashboard bundles no CDN assets; an air-gapped install never calls the price catalogue at all and loads rates through POST /api/prices instead.

Egress is allowlisted, not merely configurable, and the reason is specific to what this process holds. A provider row names both a URL and an environment variable, and Token Observe resolves that variable and sends its value to that URL as a bearer credential — so an unconstrained registry write would be equivalent to reading every secret in the process, in the one process that deliberately concentrates every provider key in the estate. The MCP case is worse than the provider case and is guarded harder for that reason: an MCP server row names a variable whose value is sent raw as an Authorization header to a URL in the same row, it is writable at operator rather than admin rank, and the outbound call is triggered by any viewer listing that server’s tools. Unguarded, it would read any variable in the process and post it anywhere.

So there are four allowlist pairs rather than one — providers, MCP servers, webhook receivers, and vendor organisation-admin credentials — each pair naming which hosts may be registered and which environment-variable prefixes may be referenced. MCP hosts default to loopback only, because a sidecar is the one topology safe to assume and “somewhere on your network” and “somewhere on the internet” are the same string to this process. Webhook hosts have no safe default at all, because a webhook destination is always third-party, so an unstated policy resolves to the existing rows alone. The credential prefixes default to purpose-specific names such as AZURE_OPENAI_ and AWS_BEDROCK_, with bare AZURE_ and AWS_ deliberately absent so that a host’s ambient cloud credentials, AWS_SECRET_ACCESS_KEY included, stay unnameable from a provider row.

One primitive is disclosed here because it is not on the destination list and a reviewer auditing the source for network clients will find it: the event publisher contains an SMTP module for emailing approval notifications, and the composition root never configures it, so this release opens no mail socket. Presence of a primitive is not presence of a feature, and stating that is cheaper than being asked about it in week three of a security review.

The most sensitive table in the system is trace_events, because prompts and tool arguments are where unplanned personal data accumulates. What it actually holds is bounded: a post-redaction prompt excerpt capped at 4,000 characters, MCP tool arguments and results capped at 16,000, the policy decisions, the redaction records as kinds and counts rather than values, and response metadata — stop reason, token counts and content-block types. The excerpt is read back off the outbound payload rather than off the original, so the search index cannot contain what the redactor just removed.

One caveat is stated here rather than glossed, because it is the single place raw model output is persisted. When a policy requires approval for a tool call the model proposed, the approval’s action summary is built as the tool name plus up to 160 characters of that proposal’s arguments, and that happens before egress redaction runs on the response. So an approval record — and the approval.requested webhook event built from it — can contain up to 160 characters of unredacted text the model generated. It cannot contain unredacted text from the prompt, because the request was redacted before it reached the provider, and approvals raised on the MCP gateway and on the request path carry no arguments at all, only the tool name or the policy reason. Treat the approvals table and the approval webhook at the same sensitivity as trace content.

What is deliberately not persisted matters as much as what is. Model response text is not stored — the response event records the stop reason, upstream request id, token counts and content-block types, not the text. The full prompt is not stored, only the bounded post-redaction excerpt. No API key exists in the database in any form; provider keys, MCP auth headers and webhook signing secrets are referenced by environment-variable name and the value lives in the process environment and nowhere else. Agent tokens are held as SHA-256 with a display prefix, and the plaintext exists once, in the response that minted it. OIDC ID tokens are verified and read but not stored, and no offline scope is requested and no refresh token held, so nothing persists that could be replayed against your identity provider. Request bodies, query strings and headers never reach the logs, at any log level.

The most interesting of those refusals is the smallest. When a caller presents a credential Token Observe does not recognise, the rejection is counted in an hourly roll-up — the reason and the count — and the presented token is not stored, and neither is a digest of it. A digest would buy nothing defensively, because an unknown credential resolves to no key in the database by definition and there is nothing to compare it against. What it would create is an offline oracle against a secret that may well be live somewhere else in your estate: a mistyped production key from another system, a credential pasted into the wrong base URL. Anyone who could read that table could then confirm guesses at that secret at their leisure, against a copy that outlives the mistake. A governance product must not turn someone else’s typo into a durable cracking target.

Encryption is stated plainly, because this is where reviewers find surprises. In transit to providers, tool servers and webhooks it is HTTPS as configured by the endpoint URL. Inbound, Token Observe speaks plain HTTP and expects you to terminate TLS in front of it; it does not manage certificates. At rest, the database file is not encrypted by Token Observe — encryption at rest is whatever your volume or host provides. Field-level protection is real but partial: passwords are scrypt-hashed with a per-user salt, agent tokens are SHA-256, temporary Effect recovery envelopes are AES-256-GCM under a key derived from an external secret that is never stored, and prompt excerpts and ordinary tool arguments in trace_events remain plaintext JSON.

The scope is derived from the signed-in user by the server and applied inside the trace and usage-store queries, then repeated on detail, search, export, compliance, spend, governance, approvals, savings and seat-registry paths — because scoping the list alone leaves the detail URL as a way around the boundary. Surfaces that cannot be honestly projected onto one team return 403 to a scoped user rather than a partial answer: the audit chain, the anchors, the retention controls, the shadow-AI radar, the seat census and the fleet summary. Sensitive trace list, search and detail reads append attributable audit events of their own, and demoting an admin or operator to auditor or viewer without an explicit scope drops any inherited wildcard to the empty scope, so a role reduction cannot accidentally preserve full-corpus access.

Two smaller decisions are worth a procurement reviewer’s attention. Authorisation is checked before existence, so probing identifiers cannot distinguish a real account from an absent one. And accounts are disabled rather than deleted — there is no delete endpoint for a user — so the audit trail keeps resolving the actor, while a patch that would leave the install with no enabled admin is refused outright.

Single sign-on is Authorization Code with PKCE, verified against the issuer’s JWKS, with the ID token read and discarded. Setting ACP_LOCAL_LOGIN_ENABLED=false makes OIDC the only login path and refuses to boot unless the OIDC configuration is complete, which is the mode the local technical-readiness check requires. The directory group snapshot is capped at 500 keys per person and replaced wholesale at each sign-in — a group the provider stopped sending has been revoked, and merging would hide that — and it ages out on its own window, 24 hours by default. Provider-specific caveats are surfaced by a status endpoint rather than discovered in production: Entra’s group overage, Okta’s extra scope, and the fact that Google Workspace emits no group claim at all.

SCIM is a bounded Users lifecycle, not a directory mirror, and it is off until a bearer token is configured. Every SCIM-created account is a viewer with no evidence scopes, and SCIM cannot set or change roles, evidence scopes or passwords. It may disable a higher-authority row, but only a named admin can rename or reactivate one — which is what stops email-first joining from turning the provisioning credential into the role or scopes already held by an unbound account. Setting a user inactive revokes all of their sessions before the disabled row is written, and disabling the final active administrator is refused. Bodies are capped at 64 KiB and 32 nesting levels; the token is at least 32 bearer characters, is never logged, and is compared through fixed-length SHA-256 digests with a timing-safe comparison. There are no Groups, no live directory read and no hard delete.

Local passwords are scrypt with a per-user salt behind two independent throttles — a per-IP budget as the CPU shield, deliberately generous so a shared office address is not locked out and not reset by a successful sign-in, and a per-account budget as the credential-stuffing shield, cleared on success so it counts consecutive failures. Local accounts have no MFA. That is the residual risk recorded below, and it is why the recommended posture is single sign-on with local login disabled.

The same property that removes the data processing agreement cuts both ways, and the vendor says so: if the database file is lost and there is no backup, the traces and the audit chain are gone, because there is no vendor-side copy. Back it up like evidence — to storage the operators of the database cannot rewrite — and check that the chain still verifies after a restore, before anything else.

Retention is implemented, and the default is to keep everything. That default is a decision you have to make rather than one you can inherit: the trace retention window is unset by default and unset means keep forever, which over-satisfies the six-month minimum in EU AI Act Article 26(6) and satisfies nothing in GDPR Article 5(1)(e), so a GDPR-regulated deployment must set it. The default is deliberate in both directions — retention has to be decided rather than assumed, and an upgrade that silently began deleting a customer’s evidence would be the worse failure. Once set, an hourly pass ages traces out in small batches, each its own short transaction, so a purge interleaves with gateway traffic instead of stalling the inline, fail-closed request path.

Read this before quoting a retention period to a data protection officer, because they will ask. The window and the erasure endpoint act on traces, trace events, the search index and trace scores, and nothing else. The audit log is never touched, by design, which is what lets the record of a deletion outlive the deleted data and why erasure is safe to offer at all. Approvals are not purged and cannot be erased by subject, which makes them the one place payload-adjacent text survives a purge that removed the trace it came from. Radar findings are not purged and cannot be erased by subject, and they may carry staff usernames and workstation hostnames. Webhook deliveries keep the exact bytes POSTed. Identity-provider group snapshots age out on their own authority-aligned window, and the rejected-caller roll-up purges on a 90-day window of its own, so quoting the trace window for it is wrong in both directions.

Erasure itself is audited on both halves. A dry run returns the count before anything is removed, and both the preview and the deletion write an audit entry — the preview because reading the prompt corpus for a named person is itself an act worth recording. The entry carries a SHA-256 digest of the subject identifier rather than the identifier, along with the trace ids removed: enough to tie the entry to the export that preceded it, without the erasure record becoming a fresh copy of the thing just erased.

And the backup boundary is stated precisely rather than rounded off. Those controls act on the live primary database only. A retained full-snapshot backup necessarily preserves whatever data existed when it was taken; restoring a pre-erasure snapshot can resurrect erased traces and can also lose the audit row that recorded the later erasure. There is no external deletion-tombstone ledger and no automatic reapplication of deletions after recovery. Until a separately approved backup-retention window, destruction evidence when that window closes, and a controlled isolated recovery procedure that reconciles every deletion in the lost interval are all in place, “erased from the live primary” is the precise claim — not “gone from every copy”.