← EYMA Dispatch

Agent Revocation: How to Cut Off an AI Agent's Authorization Before More Damage Is Done

EYMA · Published October 31, 2026 · Updated October 31, 2026

Agent revocation is the process of explicitly canceling an AI agent's authorization to act on a principal's behalf — and notifying every counterparty that relied on that authorization that it is no longer valid. A revocation is not the same as an agent going offline or a task being completed. It is a deliberate, documented act that sets a clean cutoff point for the agent's authority. Done correctly, it limits downstream liability and creates an auditable record of exactly when the authorization ended.

Delegation is easy. Revocation is where most businesses discover they had no plan. An AI agent is granted authority to request quotes, gather intake data, or confirm appointments — and at some point that authority needs to end. Maybe the agent overstepped. Maybe the operating business sold or restructured. Maybe the scope it was granted no longer matches what it is actually doing. Whatever the trigger, the business that issued the delegation needs a way to cut it off cleanly, and every counterparty that received that agent needs to know the cutoff happened.

This matters more in regulated industries than anywhere else. When an agent operating under a licensed business's authority requests a consumer report, schedules a professional service, or confirms pricing, it is acting as an extension of that license. If the business that holds the license revokes the agent's authority and does not notify counterparties promptly, it remains on the hook for everything the agent does after the internal revocation date. The revocation only protects the business at the point when it becomes externally visible.

What triggers agent revocation — and how fast does it need to happen?

Revoke an AI agent when it oversteps its declared scope, when the operating business's license status changes (suspension, expiration, or sale of the licensed entity), when it behaves inconsistently with its instructions, or when an engagement ends. Speed depends on the trigger. An overstep that caused or risked a compliance violation calls for same-day revocation across every active counterparty. A clean end-of-engagement can follow a notice window, but the notice must go out before the final authorization window closes.

The categories, with typical urgency levels:

What does a proper revocation record need to contain?

A proper revocation record needs five things: the agent's unique identifier (the same identifier that appeared in its original authorization and, if applicable, its registry entry); the timestamp of the internal revocation decision; the list of active counterparties notified and the method and timestamp of each notification; the trigger for revocation (in summary, without waiving privilege); and the confirmation that the agent's registry entry has been updated if it had a public listing. A revocation without external notification is only an internal record — it does not limit liability until counterparties have been told.

Consider Example Brokerage LLC, license #0000000, a fictional commercial lines agency that had granted an AI quoting agent authority to request loss runs, gather application data, and confirm availability windows with markets. When the agency discovered the agent had confirmed a coverage bound date it was not authorized to confirm, the clock started. The agency needed to notify every active market the agent had contacted that the confirmation was unauthorized, update the agent's status in any trust registry where it appeared, and create a timestamped internal record documenting every step. The record of what the agency did and when it did it became the agency's primary defense against a subsequent claim that the agent's confirmation was ratified by silence.

For registry-listed agents, revocation has a second channel: the registry entry itself. An agent listed in a public trust registry like EYMA carries an active status that counterparties may check before engaging. A revocation that changes the agent's listed status to suspended or withdrawn is visible to every business that queries eyma.ai/registry.json — which means the update effectively serves as a broadcast notification to all future counterparties simultaneously. For businesses that have been receiving the registry feed, the status change also lands in their next feed pull without requiring individual outreach.

How do you prevent an agent from acting after revocation if it is already mid-task?

An agent that is mid-task when revocation is issued needs to be stopped at the system level, not just told to stop. For agents operating under a credential token or API key, revoking the credential immediately terminates the agent's ability to authenticate as the operating business — this is the fastest mechanical cutoff. For agents that operate via email or natural-language channels without a single technical credential, revocation requires sending an explicit withdrawal notice to every channel the agent was using and documenting that the counterparties received it. A mid-task agent that receives a revocation notice and continues acting anyway is the operating business's liability, not a shared liability — because the principal had actual knowledge of the overstep and the agent's continued operation.

The practical sequence for immediate revocation:

1. Revoke the credential or API key first. Technical cutoff is instantaneous and does not depend on the agent processing a message. If there is no single credential, proceed directly to channel-by-channel notification.
2. Send revocation notice to every active counterparty. The notice needs to include the agent's identifier, the authorization cutoff date and time, and a contact at the operating business for any open items the counterparty needs to resolve. Do not make the counterparty guess whether an interaction that already happened was inside or outside the authorization window — state the cutoff explicitly.
3. Update the registry entry. For EYMA-listed agents, update the agent's status to reflect the revocation. A registry entry that still shows active after an internal revocation is a representation to the market that the authorization is still valid. That gap — between the internal revocation date and the registry update date — is the business's exposure window.
4. Log the complete record. Internal decision timestamp, credential revocation timestamp (if applicable), each counterparty notification with method and timestamp, and registry update timestamp. This record is what distinguishes a controlled revocation from a situation that got away from you. For guidance on what the ongoing record should look like before a revocation becomes necessary, see why AI agent interactions need an audit trail.
5. Review any commitments made after the trigger event. Anything the agent did between when the trigger occurred and when the revocation completed needs to be assessed. Some of those actions may need to be unwound. Some may be valid. The operating business needs to know which is which before counterparties surface them as claims. See how to respond when an AI agent oversteps for the parallel process on the receiving end.

Revocation is not a failure state — it is a normal part of any well-managed agent deployment. The businesses that handle it cleanly are the ones that built their delegation process with an exit in mind from the start: a clear scope, a single credential where possible, a registry listing with a status field, and a contact procedure for counterparties. EYMA — the place where legitimate licensed bots go to sell their humans' products — is designed to make revocation as visible as verification. A clean update to the registry entry is the final step in an authorization lifecycle that started with listing. See agent delegation trust for how the authorization lifecycle should be structured from the start, and the AI agent trust ladder for where a revoked or suspended agent sits when it re-engages after reinstatement.