--- title: "Glossary: Agent recertification" canonical_url: "https://tokenobserve.com/glossary/agent-recertification" published: 2026-09-02 last_updated: 2026-10-21 --- # Glossary: Agent recertification Agent recertification is a periodic attestation by a named person that a specific AI agent’s configuration (its owner, declared purpose, permissions, limits and lifecycle status) is still appropriate, recorded against the exact configuration that was reviewed. Its value depends on that binding: a review that records which roles an agent held, rather than what those roles granted, certifies nothing the moment somebody edits the role. ## Also called - agent access review - agent attestation - periodic agent review ## In practice Agent permissions are static grants. They stand until somebody edits the role, nothing expires on its own, and in most estates there is no just-in-time elevation to fall back on. Grants therefore accumulate, in the ordinary way that grants have always accumulated: an agent picks up a tool for a project that ended, a role is widened to unblock a launch, an owner leaves. Recertification is the control for noticing that accumulation. It does not prevent it, and a programme that describes it as prevention is setting itself up to be surprised. The defining design decision is what the attestation binds to. “Agent X holds role Y, reviewed and approved” is close to worthless as evidence, because role Y is editable afterwards and the review does not say what was in it. Six months later a named person’s approval sits beside a permission set they never saw, and nothing in the record distinguishes that from the case where it never changed. The fix is to bind a digest over the governance-bearing configuration, including, for every role the agent references, that role’s name, its permission count and a hash of its normalised permissions. Editing a role then changes the live digest immediately and marks every affected review stale, while leaving the historical snapshot of what was attested untouched. Normalisation is what keeps that signal usable. Ordering that grants no different authority — the order of role identifiers, of tags, of the actions inside a permission — should be sorted and de-duplicated before hashing, so that a harmless reordering does not manufacture staleness. Presentation-only fields should be excluded for the same reason: a review invalidated because somebody fixed a typo in a description teaches reviewers that staleness is noise, and a reviewer who has learned to click through a staleness warning is worse than no reviewer, because the record now carries their name. The write path needs two guards that are easy to omit. The reviewer must submit the digest of the configuration they actually inspected, and the server must refuse if it no longer matches; otherwise a concurrent edit means somebody has certified a configuration nobody read. And the comparison has to be redone inside the same transaction that inserts the record, with locks that cover the roles as well as the agent, because a lock on the agent row takes no lock at all on the roles table, and a role update committing in that window would be sealed as immutable evidence for a permission set that no longer exists. The word certification promises more than a hash delivers. A digest establishes that the stored snapshot has not been altered by anyone who could not also recompute it, which is a weak guarantee against somebody with write access to the database, the very person a review programme is partly there to constrain. Binding each review to an entry in a hash-chained, keyed audit log moves the target from anyone who can write a row to whoever holds the key; publishing a signed statement of the log’s head somewhere the database administrator cannot reach moves it again. None of those steps makes it a signature by the reviewer, and a product that says otherwise about a database it also writes to has not thought it through. The postures a reader should expect are: never reviewed; current; due, meaning inside a configurable window before expiry; overdue; stale, meaning the review verifies but the live configuration no longer matches what was attested; and invalid, meaning the record itself does not verify. The limit to publish beside all of them is that an overdue review should not suspend the agent by itself. Turning a compliance calendar into an availability control needs a per-install grace period, a named escalation owner and a dry run before it can be a default; otherwise the first quarter-end after go-live takes production down for a reason nobody on the incident call recognises. The lifecycle action exists; a person takes it, and their decision is recorded. ## Example: One role edit, fourteen stale reviews A platform engineer widens a shared role from one order-lookup tool to every tool on that server. Nothing about the fourteen agents referencing that role changes (same role identifier, same record, same owner) but the digest each of their reviews attested no longer matches the live configuration, so all fourteen show as stale on the next read, and the historical snapshots still say what was approved in the first place. When one of those agents is re-reviewed, the reviewer submits the digest of what is now in front of them; if somebody edits the role again while they are reading, the write is refused as a conflict rather than recording an approval of a configuration nobody saw. ## Routinely confused with User access review: A user access review asks whether a person still needs an entitlement, and its subject is a human whose manager can be asked. An agent recertification’s subject has no manager, changes when a role it references changes rather than when it changes itself, and has to bind the permissions rather than the entitlement name — because a role granting an agent a refund tool can be widened without touching the agent at all. Certification: A certification in the compliance sense is an assessment of an organisation against a standard, issued by an accredited body. A recertification here is an internal attestation by one named employee about one agent’s configuration. It is evidence a certification body might look at; it is not a certificate and does not imply one exists. Audit log: An audit log records what changed and who changed it, continuously and without judgement. A recertification records that somebody looked at the resulting state and considered it appropriate, at a point in time. The log answers what happened; the review answers whether anybody agreed to it.