Agent registry
One record per agent, and it is the record the gateway enforces against.
An inventory nobody enforces against is a spreadsheet.
Most businesses discover their agent estate twice: once in a spreadsheet somebody assembles for an audit, and once in an incident. The gap is structural: an inventory kept beside the runtime is updated by whoever remembers, and the runtime by whoever ships.
The questions an auditor asks are field-shaped. ISO/IEC 42001 A.4.2 wants an AI system inventory; EU AI Act Art 26(1) wants a declared purpose to compare behaviour against, and Art 26(2) wants oversight assigned to a named person. Each is a field on the record, and a field is only worth having if the enforcement path reads it.
How it works
Step 2 of the request path. The order is encoded in the evaluator, and where each step sits is the reason the guarantee holds.
- 01
Register the record
POST /api/agents with name, owner email, team and declared purpose. Status defaults to draft, so a record can exist before anyone decides to run it. Role ids are validated inside the writing transaction, because a dangling id would silently reduce the agent to deny-by-default. - 02
Issue a credential, once
The create-key response carries the only copy of the plaintext that will ever exist; only its SHA-256 and a display prefix are stored. Minting is admin-only, because it hands out gateway authority. Revoking is one write. - 03
The gateway resolves this record, not a copy
Step 2 loads the agent, its roles, the engaged kill switches and its spend window. Step 6 reads them in a fixed order: kill switches, lifecycle, RBAC, budget and rate ceilings, then the policies scoped to this subject. - 04
Recertify against an exact configuration
An operator submits the digest they inspected. The store re-derives the canonical snapshot inside the insert transaction and compares again, so a concurrent edit returns a typed 409 rather than certifying configuration nobody read.
- beat 01Name the caller
- 1Authenticate
- 2Resolve the agent
Nothing is decided for an anonymous caller. The key resolves to one registered agent with a named owner, and its roles, its ceilings and any stop switch in force are read live from the store on every request, not from a cached copy, so a suspension takes effect on the next call instead of after a redeploy.
- beat 02Start the record, then read what is being sent
- 3Open the trace
- 4Sanitise
- 5Scan
The trace is opened before anything can refuse the request, which is why a blocked call is recorded as thoroughly as one that went through. Only then is the text normalised and scanned, in that order, so the detectors see what the model will read rather than what a human reviewer can see.
- beat 03Decide once
- 6Govern
- 6bIntersect with the named human
- 7Enact
One function returns one verdict: allow, block, or hold it for a named person to approve. Every check lives in that one place rather than scattered along the path, which is what makes it possible to read your rules and know what they do.
- beat 04Send it, and only then spend the money
- 8Route
- 9Call upstream
Routing fixes which provider and model will serve the call, so where an agent has a USD ceiling it is tested against the price you will pay, not the one the caller typed. Routing is also the last step that can still refuse locally: after it, the request has left your network.
- beat 05Govern the answer, then count the cost
- 10Govern the response
- 11Meter and record
A tool call the model proposes is judged before it reaches your agent. Metering runs last and on every ending, including the refusals and the streams a client abandoned halfway, because the tokens were spent either way and a partial trace is still evidence.
Step names and their grouping are the product’s own, and the order is encoded in the evaluator rather than drawn for the page.
Every field on the record is read by something.
Four fields are required: name, owner email, team and declared purpose. The owner email is the human accountable for a thing that is not a human. The declared purpose is the field a regulator asks for, and it travels verbatim into every review snapshot. Everything else is here because some part of the request path reads it: a field nothing consults is documentation, and documentation drifts.
- Risk tier
- minimal, limited or high. Displayed and reviewed, and what an ISO/IEC 42001 A.5.3 assessment attaches to, but not a policy-scope dimension.
- Team and tags
- Kill switches and policy scope match team case-insensitively and tags case-sensitively. Finance and finance are one team; pci and PCI are two tags.
- Data policy
- Three independent booleans (zero retention, no training, a required region) rather than one flag, because providers differ on each and routing honours all three.
- Routing ceiling
- A ceiling, not a target: an agent capped at standard never reaches a reasoning model however the router scores the task.
POST /api/agents
{ "name": "support-triage", "team": "Support",
"ownerEmail": "priya.shah@example.com",
"purpose": "Draft first-response ticket replies for a human to send.",
"roleIds": ["rol_2Fq8xN"], "tags": ["customer-data"],
"budget": { "dailyUsd": 25, "monthlyUsd": 400 },
"dataPolicy": { "requireNoTraining": true, "requireRegion": "eu" } }
201 agt_7Qk2Zpv4 status: draft riskTier: limited
Sample data in the real Token Observe interface, recorded from a local evaluation with a temporary database, a mock provider and one request. No live provider key was used. The product stamps its own demo rows SYNTHETIC EVALUATION in these pixels.
A review binds a digest, not a role id.
A recertification is an append-only attestation by one named reviewer over one exact configuration: owner, team, status, roles and their grants, tags, purpose, risk tier, budgets, rate limits, data policy and routing. Description and timestamps are excluded, because a review invalidated by a typo fix trains reviewers to click through.
The work is done by the role grant. Each role is bound by name, permission count and a SHA-256 over its normalised permissions, not by its identifier. Widening a role changes the live digest and marks every affected review stale, while the snapshot of what was attested is untouched. Posture is one of six values, and invalid is presented as an audit binding mismatch rather than as evidence.
POST /api/agents/agt_7Qk2Zpv4/recertifications
{ "expectedAgentUpdatedAt": "2026-08-14T09:12:44.108Z",
"expectedSnapshotDigest": "9f1c4b…c4a2",
"validForDays": 90,
"reason": "Q3 access review. Refund tool grant removed." }
409 agent changed after the review began;
reload and review the current configurationEach line closes off an assumption a reader would otherwise carry into a proof of concept.
What this does not doWhat this leans on
Agent permissions
Deny by default, explicit deny wins, and delegation intersects, so an agent cannot borrow authority it was never granted.
Spend controls
Hard USD ceilings, per-minute rate limits and a kill switch, all decided before the request leaves your network.
Audit chain
Every administrative act hash-chained, and anchored with a signature your auditor can check alone.
Where this comes up
Jobs that draw on it
Guides that lean on it
The term, defined
An agent registry is the system of record for the AI agents an organisation runs: one record per agent carrying its identity, a named human owner, a declared purpose, its permissions, its lifecycle status and its operating limits. It becomes a control rather than a document only when it is the same record the enforcement point resolves on every call, because an inventory maintained alongside the runtime is updated by whoever remembers while the runtime is updated by whoever ships.
What happens to a running agent when someone edits its record?
The change applies to that agent’s next governed request. There is no redeployment and no propagation step, because the gateway resolves the record at step 2 rather than from an exported copy. A suspension bites on the next call, refused with a typed 403 naming the lifecycle state and published as an agent.suspended event.
Does an expired recertification stop the agent?
No, by design. Token Observe exposes the posture (never, current, due, overdue, stale or invalid) but runs no notification scheduler and does not auto-suspend. Automatic suspension turns a compliance calendar into an availability control, which needs a grace period, an escalation owner and a dry-run path rather than a surprising default.
Why does editing a role make an agent’s review stale?
Because the review attests what the agent could do, not which identifiers it referenced. The snapshot binds each role’s name, permission count and a digest of its normalised permissions, so widening a role marks every agent referencing it stale. Binding role ids alone would let a reviewer’s name sit beside a permission set they never saw.
Prefer to ask a person? Write to James
Bring us the agent you are least comfortable with.
Create a cloud account and workspace. No card or server installation. Model calls and Google BigQuery scans can incur separate provider charges.