Publishing TAP v1.0. Identity for AI agents.

Today we published TAP v1.0, the Trusted Agent Protocol. The specification is open. The reference implementation is in our source tree. Any AI provider, agent framework, enterprise platform, or security product can adopt it without paying us a license fee, signing an agreement, or asking permission. The format is published the way DKIM is published, the way OAuth 2.0 is published, the way every internet protocol that mattered ended up published.

This post explains what TAP is, what problem it solves, and why we are putting it in the public domain rather than keeping it as a proprietary advantage.

The competitive advantage is not the spec. The competitive advantage is being the entity that ships the standard the rest of the industry adopts.

The problem TAP solves

Today, when an AI agent acts on your behalf, the receiving system has no standard way to answer three questions.

Who is the agent? Not "is the request authenticated by an API key" but "is this specific agent, with this specific capability set, the one I should be talking to right now, given the user it is purportedly acting for?" API keys conflate the principal (the user) with the actor (the agent), and they conflate the user's authorization to use the system with the agent's authorization to act for the user.

What is the chain of authority that produced this action? When you ask your AI to schedule a meeting, your AI calls a calendar API, which is also an AI in many implementations, which calls a meeting-room API, which is itself an agent. By the time the meeting room is booked, the chain of "who authorized whom to do what" has fanned out across at least three agents. Today, none of them carry a structured representation of the authority chain. The receiving system either trusts the immediate caller (the meeting-room API trusts the calendar agent unconditionally) or it requires the user to authenticate fresh at every step (which makes the agent useless).

Is that authority still valid? Authorization is a state, not an event. The user might have revoked the agent's authority five minutes ago. The receiving system, today, has no way to know. It assumes the credential it was given at the start of the chain is still valid until proven otherwise. This is the structure of a stolen credit card that takes six weeks to cancel.

TAP makes all three questions answerable in a deterministic, cryptographically verifiable, sub-millisecond handshake.

What TAP is, structurally

TAP is built on three primitives.

Attestation certificate

A signed statement that a specific agent, at a specific moment, has been authorized by a specific principal to perform a specific capability set, expiring at a specific time. The certificate format is similar in shape to an X.509 certificate, but the fields are agent-specific: agent identifier, principal identifier, capability set, scope (which counterparties it is valid against), expiry, and issuing authority.

The capability set is structured. It is not a free-text description of what the agent is "allowed to do." It is a list of action types and parameter envelopes drawn from a published capability vocabulary. An attestation that says "this agent is authorized to send emails" is not valid TAP. An attestation that says "this agent is authorized to invoke email.send with to matching alice@example.com OR bob@example.com, expiring at timestamp T" is valid TAP.

The vocabulary is part of the spec. New action types can be added by anyone, with conventions for namespacing and backwards compatibility.

Authority chain

A linked sequence of attestation certificates, each one signed by the principal of the previous one, with documented delegation rules. The chain expresses, at any depth, the path from the original human principal through any number of agent-to-agent delegations to the agent currently attempting an action. The receiving system can walk the chain and verify each step's signature without trusting the immediate caller.

Delegation transitivity is bounded. A principal can authorize an agent to delegate, with explicit constraints on what subsequent delegations are allowed to authorize. An agent that has not been granted delegation authority cannot extend the chain. An agent that has delegation authority can extend the chain only within the bounds the principal granted.

This is the structure that makes agent-to-agent calls auditable. Each delegation is a signed statement. The chain is a verifiable record. There is no point in the chain where authority is implicit.

Counterparty handshake

A structured exchange between an acting agent and a receiving system, in which the acting agent presents its attestation chain, the receiving system verifies the chain, and the receiving system either accepts or rejects the action. The handshake is designed to close in single-digit milliseconds for the common case (fresh certificate, valid chain, expected scope), with fallback paths for revocation checks and cross-domain verification.

The handshake is not a proprietary protocol. It is a small extension to existing transport layers (HTTPS, with structured headers; or a dedicated WebSocket frame for streaming agents) and a set of conventions for verifying signatures against a public key infrastructure that the issuing authority maintains.

What TAP is not

TAP is not an authentication protocol for users. The user authenticates against the principal authority via whatever means the principal supports (OAuth, SAML, passkey, hardware token). TAP picks up after that. It says: given that the user is authenticated, here is how the agent's authority is structured and verified.

TAP is not a permission language. The capability set inside an attestation references a vocabulary of action types. The vocabulary is open. The interpretation of the action types (what email.send means in your specific application) is your responsibility. TAP defines the format, not the semantics.

TAP is not a transport. It runs over existing transports. The handshake adds headers and signatures. It does not require a new network protocol.

TAP is not a substitute for VOAF. VOAF is the audit chain. TAP is the identity layer. The two are independent and compose: an action authorized by a TAP chain is recorded in a VOAF entry, and the VOAF entry references the chain.

Why we are publishing this openly

The conventional advice for a startup that has built useful infrastructure is to keep it proprietary, charge for it, and use it as a moat. We considered this. We are doing the opposite, for three reasons.

Reason one: identity standards only work if everyone uses them

The value of a standard is in its adoption curve. A proprietary identity protocol used only by Vigil-protected agents is not an identity protocol. It is a vendor-lock-in mechanism. The whole point of identity is interoperability. Every agent on every platform should be able to present a verifiable attestation, and every receiving system should be able to verify it without integrating with a specific vendor's stack.

This works only if the spec is open. Once it is open, every provider has a clear adoption path. Every enterprise has a clear procurement path. Every regulator has a clear compliance reference. The proprietary version of this idea has been tried before, by larger companies than ours, and it has not worked. The reasons are structural.

Reason two: the issuing authority is the moat, not the format

DigiCert does not own the X.509 specification. Anyone can issue certificates. DigiCert is a commercially significant company because they are the entity many counterparties trust to issue valid certificates, and because their issuance infrastructure operates at scale with auditable practices.

FICO does not own the concept of credit scoring. Other scoring systems exist. FICO is the system that creditors trust because of the reliability of its scoring practices and the consistency of its issuance infrastructure.

The same pattern applies to TAP. The format is open. The issuing authority is a separate thing. We intend to operate one of the issuing authorities. We do not expect to be the only one. The commercial business is the issuance infrastructure, the verification services, the cross-domain reputation system, and the operational reliability that counterparties depend on. Not the spec.

Reason three: regulatory clarity requires open formats

When NIST eventually finalizes its AI agent governance framework, the regulators will need to reference an identity format. If the only format that exists is proprietary to a single vendor, regulators have a hard problem: they cannot mandate adoption of one company's commercial product. They can mandate compliance with an open standard. We want there to be an open standard available when the regulator is ready to write the rule.

We filed this argument as part of our NIST RFI response. The filing referenced TAP by name. The spec we published today is the version we filed.

What we ask of you

If you are an agent framework operator: implement the verifier side. Receiving an attestation chain, walking it, and verifying signatures are all small additions to an existing request handler. The reference implementation is in the open source repo. The protocol overhead is sub-millisecond.

If you are a provider: implement the issuer side. Issuing attestations to your agent platform requires a signing key, a vocabulary registration for any custom action types, and a published verification endpoint. The reference implementation covers this too.

If you are an enterprise security team: ask your providers when they will support TAP. The question itself is useful. Providers that cannot articulate a path to attestation are operating with a security architecture that cannot survive the next regulatory cycle.

If you are a researcher or implementer with feedback on the spec: the issue tracker is public. We will run a public review window for v1.1 in roughly six months, with breaking changes batched into a v2.0 if any are needed.

What is next

We are working on cross-domain trust, where attestations issued by one authority can be verified across domain boundaries without a shared key. We are working on delegation transparency logs, where the entire chain of agent-to-agent delegations across an enterprise can be inspected by a regulator without traversing each agent's logs individually. We are working on hardware-bound attestations, where the agent's identity is tied to a specific hardware enclave, eliminating attestation theft through credential exfiltration.

These are extensions, not replacements. v1.0 is stable. Implementations built today against v1.0 will continue to interoperate.

The protocol is at runvigil.ai/specs/tap/v1.0. The reference implementation is in our source tree. The signing root is published. Adoption starts now.

We did not build TAP because we wanted to be a standards body. We built TAP because the alternative is a generation of AI agent security built on API keys, and we have all seen how that ends.