When a security reviewer asks whether an agent deployment was controlled, there are only two honest answers. One is a description of the controls. The other is a record a third party can recompute. The first is a policy. The second is evidence. The self-graded dashboard offers the first while looking like the second — it reports on the deployment from inside the deployment.
TokenMark™ separates the two by construction. The gateway that carries the traffic runs in one privilege domain. The attester that seals the record runs in another, and receives only counts and hashes — never a prompt, never a reply. That separation is what lets the record answer the reviewer's question in two halves: what existed before the agent's first call, and what the ledger shows after.
BEFORE FIRST CALL
- BASELINEHash-pinned and agreed in writing. Cannot drift mid-term.
- LANES DECLAREDHuman · Agent · Break-glass. Allowances set per lane.
- OWNER + APPROVERNamed roles, reason codes published.
- ABUSE CRITERIAPinned, published, quantity-only.
- VERIFIER DELIVEREDOffline binary and policy bundle, on your hardware.
AFTER FIRST CALL
- DEPLOYMENT RECORDPrincipal label · lane · first-seen · approver. Sealed.
- COUNTERSTokens, calls, resent context, unread spans, retries — per principal.
- OBSERVED FLAGSUndeclared agentic signatures, routed to the approver.
- BREAK-GLASS LEDGEREvery opening: fired criterion plus two roles, sealed into the statement.
- EXIT REPORTBasis mix disclosed. Your auditor recomputes it.
Before: the controls have to exist before the agent does
Most deployment evidence fails on timing. The policy is written after the incident, the baseline is chosen after the numbers are in, the approver is named when someone asks who approved it. A pre-deployment record closes that hole by sealing the control set with its timestamp before the first call. If the baseline hash in the exit report matches the one sealed on day zero, it did not move. If the approver role appears in the day-zero bundle, it was not invented afterward.
Nothing in the "before" half requires reading content. A lane is a declaration. An allowance is a number. An abuse criterion is a threshold on counts — volume against the lane median, off-hours share, endpoint fan-out. Users select their own lane; TokenMark™ never classifies a request as business or personal by looking at it.
After: what the attester can and cannot say
| Record | Basis | What it establishes |
|---|---|---|
| Deployment declared | VERIFIED | A named principal declared an agent lane at first call. Owner, approver, time. Sealed by a party that did not carry the traffic. |
| Agentic signature | OBSERVED | Counts that look unattended — sub-human cadence, session depth, fan-out. A notice to the approver, not a finding. Never promoted without a declaration. |
| Principal counters | VERIFIED | What the agent consumed, encrypted at rest, released as lane aggregates under a group-size floor the verifier enforces. |
| Provider figures | PROVIDER_ASSERTED | Counts the provider reported and the gateway could not independently observe. Disclosed as such in the basis mix. |
The limit is worth stating plainly: on counts alone, a scheduled job and an agent look the same. TokenMark™ does not attest intent. It attests a declaration and a signature, and it tells you when the two disagree. That is why declaration is the primary basis and observation is the backstop — an undeclared agent is a process gap, and the record names the gap without reading a single token of what the agent said.
A control that exists only in the vendor's description is a promise. A control that appears in the day-zero seal and again in the exit report is evidence.
What the reviewer gets
Two artifacts, one verifier. The day-zero bundle and the exit report are both recomputable on the reviewer's own hardware, offline, from the pinned policy. The reviewer does not trust TokenMark™'s arithmetic; they re-derive it. Where the reviewer's numbers differ from the statement, the statement fails — and a TokenMark™ invoice computed from a failed statement is not owed.
Federated and multi-entity organizations get the same two halves per member entity, rolled up without identity: labels stay opaque, the identity map stays on the customer's side, and the verifier rejects any statement that carries a name or an email address.
Interest disclosure: TokenMark™ is a commercial AI spend assurance product of Atom Works™, Corp., and the separation described here is the subject of one or more pending U.S. patent applications. The evidence pattern itself — controls sealed before first call, outcomes sealed after — is described so that any vendor can implement it; a test only one vendor can pass is an advertisement, not a standard. No standards body, regulator, or auditing authority has adopted or endorsed this pattern.