Most organizations understand how to grant software access. Fewer have designed an equally reliable way to make that access stop, especially after an autonomous agent has already started a chain of work.
The problem becomes more urgent when agents can run for hours, call subordinate agents, hold sessions open, schedule work and access systems across organizational boundaries. A permission that was reasonable at 9:00 a.m. may be inappropriate by noon. A customer can withdraw approval. A manager can leave. An account can be compromised. A project can be canceled. Meanwhile, the agent may still be moving.
NIST's October 27, 2026 proposed agent identity tenets put short-lived, dynamic and revocable authorization near the center of the architecture. IBM's October 26 Agent Identity launch similarly describes short-lived task-scoped tokens, policy enforcement during execution and credential control tied to the delegation context.
The implication is operational, not merely cryptographic: authorization should be checked at the moment of action, not assumed forever because a login once succeeded.
Expiration is useful; revocation is indispensable
Consider a finance agent authorized to collect statements, categorize transactions and draft a cash forecast. Its access should expire after a task window. That reduces the exposure from forgotten credentials and idle agents. But expiration alone is insufficient. If the owner revokes access five minutes after the task begins, the system must be able to interrupt future calls before the original expiry time.
Effective revocation therefore requires coordination among a principal, an authority record, a policy decision point, credential issuers, tool gateways and downstream services. Deleting a line in an agent's prompt is not revocation. Neither is deleting the agent from a dashboard while an API token remains valid elsewhere.
NIST's recent tenets call for just-in-time grants, audience-specific tokens, verification against current context and risk, and no standing privilege when idle. These are proposed principles rather than binding security requirements, but they offer a practical design baseline.
MoonVault view: authority should disappear when its purpose ends, not when somebody remembers to clean up the credential.
Revocation must follow the delegation chain
Suppose Agent A can ask Agent B to collect vendor documents, and Agent B uses a third-party data service. Even if Agent A is stopped, the delegated job may still be queued and Agent B may still have permission to retrieve information.
Revocation must reach each downstream boundary that can perform work. It should be possible to answer: which sub-agents were created, which credentials were issued, which resources remain reachable, which tasks are in flight, and which actions cannot be undone?
This is not simply a user-interface problem. Systems need reliable grant identifiers, resource and audience scopes, cancellation semantics, token invalidation or introspection, and a record of downstream delegated capabilities. Sub-agents should never gain authority that exceeds the originating grant. That property is often called attenuation.
The hardest boundary is work already in motion
Stopping a task is not necessarily reversing it. A stopped agent may already have sent an email, submitted a payment instruction or modified a customer record. Some operations can be canceled before a commit point. Others require compensation, dispute resolution or an explicit human recovery action.
The individual October 17 Agent-to-Wallet Protocol draft makes this distinction visible: it identifies a commit point for a credential operation and allows cancellation before, but not after, that point. The draft is exploratory and has no IETF standards status. Still, it illustrates why revocation must be designed alongside the actual business transaction.
A trustworthy system should distinguish at least four states: requested, authorized, executed, and settled or reversed. Conflating these states can create false confidence after an emergency stop.
Who is allowed to revoke authority?
A principal should ordinarily control grants made in their name. But business operations introduce more complicated questions. Can the security administrator interrupt an agent? Can a controller terminate finance access? Can an authorized successor assume responsibility during incapacity? What if the original approver no longer works for the organization?
These decisions belong in documented policy and governance. They should not be improvised by the agent being restricted. In some cases, an emergency suspension may take effect immediately while formal ownership, succession and recovery procedures determine what happens next.
NIST's September report on token and assertion protection emphasizes secure token lifecycle and key-management practices for federated systems. IBM's announcement describes centralized agent inventories, owners, policy and just-in-time credentials. Neither eliminates the organizational work of defining who may grant, narrow, suspend or restore authority.
Design for recovery, not only containment
- Before execution: Grant the smallest right needed, bind it to purpose, audience and duration, and define what requires human approval.
- During execution: Recheck policy at consequential operations and monitor changes in risk, ownership and environment.
- On interruption: Suspend new actions, invalidate access, identify in-flight operations and preserve independent evidence.
- After interruption: Determine which actions completed, what can be corrected, and who can safely reauthorize work.
The continuity question is MoonVault's particular interest. An organization needs to retain control even if the original agent, employee, credential broker or platform provider no longer exists. Control must be transferable under defined rules without allowing an agent to appoint its own replacement authority.
This is a design thesis, not an existing MoonVault feature. The October standards and product developments make the issue more concrete: permission is not a switch left permanently on. It is a living relationship with an origin, a purpose, a duration and a way to end.
Earlier MoonVault analysis: why accountability begins with a delegation record.
Primary sources and evidence status
- NIST, Design Tenets for Agent Identity Management Systems, October 27, 2026 (proposed principles).
- IBM, Agent Identity general availability, October 26, 2026 (vendor-described implementation).
- NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse, September 2026 (implementation guidance).
- A2WP Internet-Draft, October 17, 2026 (individual proposal, not an adopted standard).