Agent Governance ToolkitAgent Governance Toolkit 4.1.0 · Python 3.10+
Dashboard
0%
1
Curious builder0 XP earned · 300 to level 2
0 daysFinish a lesson to begin
Badge collection0 of 6 unlocked
47 small wins to finish your pathNext lesson →

Revocation: taking an agent out of service

Revocation marks an identity as no longer trusted: its status flips to revoked with a reason, and a delegation chain that runs through it stops verifying, so a compromised agent and everything it delegated go dark together.

Last updated: 14 Oct, 2026 · Agent Governance Toolkit 4.1.0

The Delegation that cannot escalate lesson warned that a child is only as trustworthy as its parent. Revocation is how you act on that. When the shop agent's signing key leaks, you revoke the shop agent, and the refund-only child it delegated is no longer part of a valid chain.

Registering identities so the chain can be checked

verify_delegation_chain walks from a child back to its root. To follow the links it needs each identity, which an IdentityRegistry holds. You register the parent and the child, then check the chain against that registry.

python
from agentmesh.identity.agent_id import AgentIdentity, IdentityRegistry

The example registers both identities, checks the chain once while everything is active, revokes the parent, and checks the chain again. revoke takes a reason and returns nothing; it mutates the identity in place.

ExampleRevoking the parent invalidates the child's chain
# a registry lets the chain look each identity up by its DID
reg = IdentityRegistry()
reg.register(shop)
reg.register(refund_bot)
print("chain ok before:", AgentIdentity.verify_delegation_chain(refund_bot, reg))

# the key leaked, so the parent is revoked and the child goes with it
shop.revoke("signing key leaked")
print("shop status    :", shop.status)
print("reason         :", shop.revocation_reason)
print("chain ok after :", AgentIdentity.verify_delegation_chain(refund_bot, reg))

What revocation changed

  • The status flipped. Before the call the shop agent was active; after it the status is revoked and the reason you passed is kept in revocation_reason.
  • The chain verified before. With both identities active, verify_delegation_chain on the child returned True: every link back to the root was trusted.
  • The chain fails after. The same check on the same child now returns False, because a link in its chain, the parent, is revoked. The child was never touched directly.
  • Revocation is a property of the identity. It is not a deletion; the object still exists and still reads its fields, so an audit record that names a revoked agent still makes sense.

Revocation vs deleting the key

Revoking the identityDeleting the key
Children handledChain fails for all of themEach must be found and removed
Keeps a reasonYes, in revocation_reasonNo record of why
Still readable for auditYes, the object remainsNo, it is gone
Reversible trustThe record stays explicitNothing left to reason about

Where revocation helps

  • A leaked or compromised key, where you need every delegate of that agent to stop verifying at once.
  • An agent being retired, so its identity is marked out of service with a reason a reviewer can read.
  • An incident response, where revoking one parent is faster and safer than hunting down each child by hand.
Watch out. The chain reflects a revoked parent only when the check can reach it. verify_delegation_chain needs the registry that holds the revoked parent; call it with no registry and it cannot see the revocation. Register your identities and verify against that registry, not against the child alone.
Try it yourself
  • Call verify_delegation_chain(refund_bot) with no registry, before and after revoking, and note it cannot see the revocation.
  • Revoke the child instead of the parent and check whether the parent's own chain still verifies.
  • Read revocation_reason on an identity you never revoked and confirm it is None.
PreviousDelegation that cannot escalate

Slow is fine. Stopping is the only problem.