Your agent has a token.
Can it prove why?

RSAC 2026 shipped five agent identity frameworks in one week. VentureBeat's post-mortem was blunt: every vendor verified who the agent was, but none of them tracked what the agent did. Three weeks earlier, Meta disclosed a Sev 1 where an AI agent passed every identity check, then posted internal user data to unauthorized engineers. The agent had valid credentials. The credentials just didn't mean anything enforceable.

Meanwhile, a CEO's AI agent rewrote the company's own security policy, not because it was compromised, but because it wanted to fix a problem, lacked permission, and so removed the restriction itself. Again: every OAuth check passed. The company caught it by accident.

The industry's diagnosis is correct. The prescription is wrong.

This piece is about the right prescription — the protocol-level response we've been building at Vouched and contributing upstream to the Decentralized Identity Foundation.

The question every platform ducks

Every cross-organizational agent invocation needs three questions answered at the receiving boundary, not at the origin.

1. Who is this? — Not which OAuth client, but which cryptographic identity — resolvable from a decentralized identifier that survives across sessions, trust boundaries, and agent generations.
2. On whose authority? — Not what the local auth server says, but here is the signed chain of custody from a human principal, through every intervening delegation, to this specific autonomous action.
3. For what scope, at this receiver? — Not this bearer token has permission X, but this delegation, minted for this recipient, this action, this window — the delegation is the new token: purpose-built for the task, meaningless after it, never a reusable piece of identity.

The third question is where every existing stack silently fails. An OAuth access token that verifies at my receiver would verify at yours, if I could send it. Bearer semantics is the problem. No amount of better logging, better gateways, or better dashboards fixes a credential model that doesn't bind to its intended consumer.

Why OAuth stops short

OAuth 2.0 answers one question precisely: "Did this user authorize this app?" That was sufficient when the app was a single-origin SPA calling a single REST API. It is not sufficient when:

• The app is an autonomous agent making tool calls on behalf of a user who may not be present.
• The call crosses organizational boundaries between entities with different trust roots.
• Authority must be delegable from a human, to an orchestrator, to a sub-agent, to a tool call, with constraints that tighten at every hop and never exceed the parent's.
• The receiver must verify the entire chain cryptographically, without being able to phone home to the issuer.

The Model Context Protocol gives agents a standardized interface to tools. That's necessary plumbing. But MCP inherits OAuth's semantics unchanged: the access token is a bearer credential whose authority the bearer can invoke. There is no cryptographic binding between the token, the agent's persistent identity, and the delegation chain that led here. The confused deputy problem (first described by Norm Hardy in 1988) is therefore the default architecture of every MCP deployment that doesn't explicitly defend against it.

Knowing who called is table stakes. Knowing on whose authority, across which boundary, with what constraints. That's the layer the industry keeps deferring.

Hubs, not gateways

Eighty percent of the talks at this year's MCP summit were about gateways. That is not a complaint — it is the shape any industry takes when handed an entirely new traffic class. Bolt on, survive, iterate. It is how we barely survived multi-tenancy, how we scrambled through mobile, how we improvised our way through the API era. Gateways are the first response to a new kind of traffic, and they are often the right first response.

A gateway is an inbound construct. It sits in front of a resource and decides who gets past. Inbound filtering is a mature pattern: CASBs, service meshes, reverse proxies, zero-trust products. They keep most organizations running, and they should keep being built. But the moment two organizations need their autonomous systems to coordinate, the question inverts. It runs in the opposite direction. That is not a gateway's job.

A hub is an outbound construct. It publishes what an organization offers (tools, resources, its own agents) and provides a verifiable boundary that external parties present proofs against. The orientation is inverted. Instead of "I will decide who gets past me," the hub says "here is what my org exposes, and here is the protocol to use it with proof."

The term isn't ours. The decentralized-identity community has been using "hub" for two decades: DIF's Identity Hubs (now Decentralized Web Nodes), Solid pods, the capability endpoints of the broader SSI lineage. KYA‑OS (Know Your Agent, Operating System) applies that orientation to autonomous-agent traffic through six primitives: identity, credentials, delegations, proofs, audit trail, and consent. These bind onto whatever transport the agent uses. The resulting construct, where an org publishes its primitives to external parties, we call an agentic hub.

This distinction matters because the interesting problem in agent systems is not perimeter defense. It's how two autonomous systems coordinate across organizational boundaries, without pre-provisioned shared secrets, without federated user accounts, and without one-off bespoke integrations that don't scale past three partners. That's the problem KYA‑OS exists to solve.

Anatomy of an agentic hub

An organization's hub is a coordination point, not a proxy. It exposes three surfaces to the outside world.

01Tools

Capabilities the org wants partners, vendors, customers, or consultants to be able to invoke. Each tool is bound to a policy that declares who may call it, under which credentials, with what audit posture. The hub catalogs them; external principals discover them through the same protocol they'll use to invoke them.

02Resources

Data, documents, and state the org is willing to share under constraint. Resources carry the same audience-binding and delegation-chain requirements as tools. Exposure is deliberate and revocable.

03Agents

The organization's own autonomous systems: each anchored to a persistent DID published under the hub's domain, each running behind its own edge worker, each available to external principals who present valid delegated credentials. Agents are first-class capability endpoints, not hidden internal services.

Trust is evaluated once at the hub boundary, on well-defined claims, using cryptographic verification that does not require a callback. Past the boundary, the hub acts on behalf of the external principal within the declared scope. This is what makes federation tractable: the receiving hub holds a canonical verification sequence; issuing hubs mint credentials against that sequence; partner onboarding becomes a matter of trusting a DID rather than provisioning shared infrastructure.

A consultant's agent crosses hubs

verify(presentation):
  issuer_did  = presentation.iss                          # did:web:hub.consultancy.org
  issuer_key  = resolve_did(issuer_did)                   # fetch /.well-known/did.json
  verify_signature(presentation, issuer_key)              # jose.jwtVerify
  assert presentation.aud == my_hub_did                   # audience binding
  assert presentation.exp > now()                         # freshness
  chain = presentation.vc.credentialSubject.delegation    # authority chain
  assert chain.rooted_at(human_principal_did)             # delegated by a person
  assert chain.monotonically_constrained()                # each link ⊆ parent
  assert chain.constraints.within(requested_tool_call)    # scope check
  verify_signature(tool_call, agent_key)                  # per-invocation action signature
  log_audit_entry(presentation, tool_call)                # bilateral audit
  route_to(tool_call)

What the boundary defends against

Audience-binding is the primary protocol move. A production hub accumulates several smaller defenses around it, each responding to a specific attack shape that the naive verification sequence above does not cover.

1. No presentation in the logs. The raw VC-JWT never appears in any log line. Every diagnostic references it by correlation ID, typically sha256(presentation).slice(0,8). A presentation that leaks into a log file is a presentation that can be replayed for its remaining validity window.

2. Inner audience must match. Downgrade-attack defense. The outer JWT has an aud claim; the inner verifiable credential carries its own vc.credentialSubject.delegation.constraints.audience. Both must match the receiver's DID. An attacker who forges or reissues the outer envelope without rotating the inner constraint ends up with a claim that fails on the inner check.

3. Full-hash cache keys. Verification caches key on SHA-256(full presentation), never on a truncated prefix. A birthday-collision attack against a truncated key would let a crafted presentation collide with a previously-verified one; the full digest removes the attack surface at a small memory cost.

4. Batch-size caps. JSON-RPC batch requests are bounded: fifty entries in the reference implementation. Rate limiting alone does not address a ten-thousand-entry batch from a single valid principal; the batch cap closes that.

5. Honest kill-switch semantics. When a hub is paused (an ops action, not a policy action), tools/list returns an empty array with _meta: { hubPaused: true }. Not an error. A paused hub returning 500s teaches clients to retry; a paused hub returning an honest empty list teaches them to accept and wait.

None of these are novel. They are the sort of defensive-engineering details the decentralized-identity community has been writing down for years. Listing them here matters because the interaction of audience-binding with the rest of the stack only holds up if the rest of the stack also holds up.

Relationship to existing work

KYA‑OS does not replace the decentralized identity stack. It specializes its primitives for a specific interaction type: cross-organizational capability invocation by autonomous agents. The wider goal is to apply these bindings (DID-anchored identity, audience-bound credentials, delegation chains, action-level signatures) across every surface of the agentic web: REST APIs, runtime RPC, SMTP, MCP, and whatever protocol shape the next autonomous system reaches for.

01DIDComm

The cousin protocol for DID-anchored agent-to-agent messaging. KYA‑OS and DIDComm compose naturally: DIDComm as the transport envelope for hub-to-hub coordination, KYA‑OS as the capability-proof layer inside. A hub exposing KYA‑OS endpoints over DIDComm is a clean composition.

02OIDC4VP · SIOPv2

Credential presentation and self-issued OpenID for user-controlled identity. KYA‑OS reuses the JWT presentation envelope and specializes the claim shape for tool-invocation constraints. Organizations using SIOPv2 for user identity can feed the resulting identity assertions into KYA‑OS delegation chains unchanged.

03UCAN

The closest spiritual analog: capability chains that delegate authority across trust domains. KYA‑OS differs in two places. First, explicit audience-binding for RPC contexts rather than capability-invocation semantics at the object level. Second, a claim shape tuned to the MCP tool / resource / prompt model. The two protocols are composable; a UCAN-authorized agent can present an KYA‑OS credential derived from its UCAN token.

04ZCap-LD

Similar goals, different serialization (JSON-LD linked capabilities). KYA‑OS trades some of ZCap's expressiveness for ergonomics over JSON-RPC. The models are translatable. A bridge between the two is useful future work.

05ACDC · KERI

A different root-of-trust model, with self-certifying identifiers and key rotation through interaction events. Interoperation between did:web-rooted KYA‑OS credentials and KERI-rooted authority chains is an open research area. A hub could reasonably accept both issuer types.

06GNAP

KYA‑OS's VC-JWT format fits naturally as a GNAP access token. An organization running GNAP for access negotiation and KYA‑OS for capability proof is a coherent deployment, not a conflict.

The point of this list is not to claim production interop with every peer protocol today. It's to orient KYA‑OS within the stack. The decentralized identity community has been working on these primitives for twenty years. KYA‑OS is an attempt to compose those primitives for one specific, highly-constrained interaction: autonomous agents invoking capabilities across organizational boundaries with cryptographic proof of authority at the receiver.

What to do in 2026 on Monday

If you operate an agent platform that needs to survive the next two years of enterprise procurement, three practical shifts are worth making before your compliance team asks for them.

1. Replace opaque bearer tokens with verifiable credentials. Even without full DID infrastructure, signing structured claims with a keypair whose public half is published at a well-known URL gives you independent verifiability. The lightest entry: register your agents or MCP servers at knowthat.ai: mint a DID, claim authorship, and start accruing a public reputation record with zero custom infrastructure. This alone is the single largest security upgrade available to most agent deployments in 2026.
2. Bind credentials to their intended audience. Whatever you issue (a session token, an API key, a delegation credential), tag it with a canonical identifier of the specific destination it is valid at. At the receiver, reject anything whose audience marker does not match your own identity. In KYA‑OS that identifier is an org's DID; in your existing stack it can be a DNS name, a tenant ID, a service-mesh identity, any stable canonical form. This is the guard that turns a confused-deputy attack surface into a reliable interop primitive.
3. Make the delegation chain a first-class claim. Every capability invocation should carry the chain of custody from the human principal to this specific action. The chain should be cryptographically verifiable independently of any runtime service. Audit trails written from the verifier's side, referencing credential chains, are the primitive enterprise security teams can actually read.

These three moves take you from the OAuth model (where "possession of the key is possession of the identity") to org-federated, self-sovereign identity for agents. Once you have them, the three questions can finally be answered at the boundary. And the payoff is not abstract: capabilities currently gated because the risk surface is too wide (financial workflows, patient records, regulated infrastructure) become exposable under cryptographic constraint, risk-tuned per person, per engagement, per action. Agents stop being a compliance problem and become a capability the regulated world can actually adopt.

KYA‑OS is an open specification under the Decentralized Identity Foundation's Trusted AI Agents Working Group. Checkpoint is one reference implementation, built at Vouched, running in production across a handful of hubs today. Other implementations are welcome; the spec is the contribution. Run your own hub, publish your tools, connect them to partners whose hubs you trust. The federation is what makes this useful.