Identity, permissions and delegation

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 entirely 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

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 actually 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.

What the record proves is worth stating precisely, because the word certification invites 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 — exactly the 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.

in practice

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 exactly 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.

not the same as

What agent recertification is 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.
next

Related terms

Agent registry

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.

Action-level permissions

Action-level permissions authorise a specific operation on a specific named resource — one tool on one server, or one model — rather than granting access to a system as a whole. The unit is what matters: an agent granted a system inherits every operation that system exposes, including the ones next to the operation it actually needed.

Deny by default

Deny by default is an authorisation model in which an action is refused unless some permission explicitly allows it, and in which an explicit deny overrides every allow. An agent holding no roles, a role with an empty permission list, and a resource no permission names all produce the same answer — refused — so the failure mode of a misconfiguration is a blocked request somebody notices rather than a standing grant nobody does.

Agent identity

Agent identity is what establishes which AI agent is making a given call: a credential the agent presents, and a registered record that credential resolves to, carrying the agent’s owner, declared purpose, permissions and lifecycle status. It is a different thing from the identity of the human the agent is acting for and from the identity of the workload the agent runs inside, and treating any two of the three as interchangeable is the most common source of authorisation error in agent systems.

Identity, permissions and delegation

The terms next to this one

What it means for an agent to be allowed to do something, and why the answer stops being obvious the moment one agent can ask another.

get in touch

Definitions are the easy part.

The glossary is written to be useful whether or not you ever buy anything. If you have got to the point of deciding how to implement one of these in your own estate, say what your agents do and you will get a straight answer about what it would actually take.

no form · no qualification step · no sales desk · the other three ways in