VARP: revoking a compromised agent across every surface.

VARP, the Vigil Agent Revocation Protocol, is the answer to a question that does not yet have a standard answer: when an AI agent is compromised, how does the user revoke its authority across every counterparty it was authorized to act for, fast enough to matter?

This post is the walkthrough for engineers and protocol implementers. The strategic argument for why revocation needs a protocol of its own is in the NIST RFI post. Here we focus on the mechanics.

Authority is a state, not an event. Today, when an agent's credential is stolen, the receiving systems treat the credential as valid until each of them is individually told otherwise. That is the structure of a stolen credit card that takes six weeks to cancel.

The problem in one paragraph

When an AI agent acts on a user's behalf, it presents some form of credential to the receiving counterparty. The credential might be an API key, an OAuth token, or a TAP attestation chain. The counterparty validates the credential and processes the action. So far so standard. The problem appears when the credential is later compromised. The user has to revoke the agent's authority. The user typically has to do this for each counterparty separately. There is no shared revocation state. Each counterparty maintains its own view, and they are not synchronized.

In the AI agent context, the consequences of this gap are larger than in the traditional credential-revocation context, because agents act faster, more often, and across more counterparties than human users. An agent compromised at 9:01 AM that the user revokes at 9:02 AM might still be acting against ten counterparties at 9:03 AM if the revocation has not propagated. The cost of a one-minute propagation delay is much higher when the actor is autonomous and the action rate is hundreds per minute.

VARP closes this gap.

The mechanics, in three primitives

Primitive one: the revocation event

A revocation event is a signed statement, issued by the principal who originally authorized the agent, that revokes one or more attestation certificates. The event carries the agent identifier, the revoked certificate identifiers, the timestamp of revocation, the principal's signature, and a propagation scope.

The propagation scope determines which counterparties receive the revocation. The scope can be specific (a list of named counterparties), categorical (all counterparties of a given type), or universal (every counterparty that has ever received an attestation from this agent). The default for high-severity revocations is universal.

The event is small. A typical event payload is under one kilobyte. The size matters because propagation latency is dominated by the number of counterparties, not the payload size, and we want every counterparty to be reachable in the shortest possible time.

Primitive two: the propagation graph

When a revocation event is issued, the issuing authority propagates it to a graph of relays. The graph is the structure that delivers the revocation across every counterparty in scope.

The graph is not a single fan-out tree. It is a partial mesh, with redundant paths between any two nodes, designed to deliver to every leaf node in under one second under normal conditions. The relays are operated by the issuing authorities, by major counterparties that opt in, and by infrastructure providers that operate VARP relays as a public service.

Counterparties subscribe to relays. A counterparty can subscribe to multiple relays for redundancy. When a revocation event arrives at a relay, the relay forwards to every subscribed counterparty whose scope matches. The forwarding is push-based, not pull-based. There is no polling delay.

The cryptographic verification happens at each counterparty, against the principal's public key, not against the relay. The relay is not in the trust path. It is only the delivery mechanism. A compromised relay can fail to deliver an event, but it cannot forge one, and the receiving counterparty can confirm authenticity without trusting the relay.

Primitive three: the local cache

Each counterparty maintains a local revocation cache, indexed by attestation certificate identifier. When a counterparty receives an action attempt, it checks the cache before processing. If the action's underlying certificate has been revoked, the counterparty rejects the action with a structured response. If the certificate has not been revoked, the counterparty processes the action normally.

The cache lookup is fast. Sub-millisecond for the common case (cache hit, certificate present, status returned). The lookup is on the hot path of every authenticated action, so the latency budget is tight.

The cache is updated on revocation event delivery, not on action arrival. This is the property that makes VARP fast. By the time the next action arrives, the cache already reflects the revocation. There is no synchronous lookup against a remote authority during action processing.

The latency target

The end-to-end target is sub-second propagation from issuance to last counterparty in scope. Concretely:

• Event signing and emission to the first relay: under 50ms.
• Relay propagation to the broader graph: under 200ms for the median counterparty, under 800ms for the longest path.
• Counterparty cache update on receipt: under 5ms.

These targets are met under normal network conditions in our reference implementation. Adversarial conditions (network partition, relay compromise, denial-of-service against a specific path) can stretch the timeline, but the redundant graph structure ensures eventual delivery as long as any path remains intact.

What VARP does not do

VARP does not handle the reissuance side. When a user revokes a compromised agent, they typically need to issue a fresh attestation for a replacement agent. The reissuance path is part of TAP, not VARP. The two protocols compose.

VARP does not handle counterparty discovery. The propagation scope determines who receives the revocation, and the scope is set by the issuing principal at the time of issuance. If the user does not know which counterparties an agent has interacted with, VARP cannot infer this. The discovery side is a separate concern, and we recommend that issuing authorities maintain an interaction log that the principal can consult before issuing a scoped revocation.

VARP does not handle policy decisions about whether to honor a revocation. Counterparties can choose to ignore VARP events for various reasons: they might not subscribe to the relevant relay, they might apply business rules that override the revocation for a grace period, they might be configured to require additional verification before honoring a high-severity revocation. VARP defines the protocol. Honoring is a policy choice at each counterparty.

What VARP enables

When VARP is widely deployed, the user experience of agent compromise changes meaningfully. A user who notices unusual behavior from their AI agent can issue a revocation. Within a second, every counterparty the agent was authorized to act with stops accepting actions from that agent. The user can review the audit trail, identify which actions occurred before revocation completed, and contest those actions with the counterparties using the cryptographically verifiable VOAF chain.

The current alternative is a manual process: the user contacts each provider individually, hopes the provider's incident response is fast, and absorbs the cost of any actions that completed in the gap. The manual process scales poorly with the number of counterparties and with the autonomy of the agent.

This matters today, with a small population of agentic users. It matters more in twelve months, with a larger population. It matters most when AI agents are operating across regulated infrastructure (financial transactions, healthcare records, legal filings) where the cost of a compromised agent acting unchecked is measured in real money or real harm.

The reference implementation

The protocol specification is at runvigil.ai/specs/varp. The reference implementation is in the Vigil source tree, under the vigil-authority crate. The relay implementation is a small Rust service that runs in a single process, with the network protocol layered on top of WebSockets and signed payloads.

The implementation passes the test suite. The test suite covers single-relay, multi-relay, partition recovery, signature verification, scope filtering, and cache consistency. The latency targets are met on commodity hardware in the test environment.

Adoption

VARP is open. There is no license. There is no certification body that gates adoption. Any counterparty can implement the verifier. Any principal can issue revocation events. Any infrastructure provider can run a relay.

We expect the early adopters to be the entities that operate AI agents in regulated contexts where the cost of compromise is high and the existing revocation tooling is inadequate. We are in conversation with a small number of these. The wider adoption curve depends on whether the eventual NIST framework references VARP as a recommended pattern for revocation, which is one of the things our RFI response argued for.

If you operate a counterparty that authenticates AI agent actions, the verifier is a small addition to your existing handler. The reference implementation is in the open. We are happy to review pull requests and answer integration questions on the public issue tracker.

The protocol is the small part. The hard part is the cultural shift from credential-as-event to authority-as-state. VARP is what that shift looks like in code.