Why OAuth isn’t enough

Above the iceberg: what standard OAuth offers. Below: what’s missing that is crucial for agentic AI use cases.

OAuth is the industry-standard protocol for human access authorization on the web. It relies on authorization servers that grant clients access tokens for reaching protected resources, and is commonly used to implement access control for APIs, single sign-on, and more. With the fast rise of MCP, OAuth was a natural fit: tokens like JWTs could give agents access to arbitrary resources.

With agentic workflows growing beyond simple use cases, though, people are already using agents to book flights and make purchases autonomously. Recently, Meta’s Muse agent hit #1 on the app store within weeks of launching, surpassing ChatGPT. Soon after, they announced integration with Shopify to bring on its millions of merchants onto the platform, who would be opted in by default to enable agentic shopping. In the future, agents may be used to handle cross-organizational negotiation or business procurement.

Simple access tokens often fall short of the many requirements we must meet before we can reliably hand work like this to agents. If you have agents making complex transactions on your behalf, how do they verify themselves? How can we distinguish between the user and the agent to enforce policies? And how do we separate one of a user’s agents from another, so each is scoped to its own access? How do we keep the process transparent and auditable? KYA-OS (developed under the Decentralized Identity Foundation) offers solutions to these problems using open web standards. It is not a replacement for OAuth: OAuth can still handle acquiring credentials, while KYA-OS can add the authority layer on top of it, verifying who an agent is and what it has been delegated on every single request.

OAuth refresher, and how it works with MCP

OAuth is built on the core concepts of a Resource Owner, Resource Server, Authorization Server, and Client. When a Client (e.g., Trello) wants to access a resource (e.g., a GitHub repository) on behalf of the Resource Owner (typically the user), it asks the user to authorize it by contacting the Authorization Server (in this case, GitHub). The Authorization Server generates an access token, which the Client shares with the Resource Server when trying to access the resource.

Note · OAuth is an authorization protocol and not an authentication protocol (there is no identity information unless combined with OpenID Connect, an identity layer on top of OAuth 2.0). OpenID Connect is what you log into GitHub with, authenticating yourself before granting authorization.

When it comes to MCP, traditional OAuth integration often ends up looking like this: you ask Claude Code to do something, it makes a tool call for a specific MCP server, and it gets hit with an HTTP 401 Unauthorized. This means the access token does not exist or has expired. Now, the agent has to ask you to reauthorize. It gives you a link to follow, which contains a unique hashed challenge as part of PKCE, and spins up a local callback server. You open the link, make sure you’re logged into the right account (e.g., GitHub), and grant authorization. The webpage redirects to the local callback URL, where the agent harness’s server stores the token and shows you a success page. You now have to tell the agent to proceed, and it tries the tool call again and succeeds. To make it smoother, Clients may receive confidential refresh tokens that they can send to get a new access token in case one expires.

This process has many steps and is easy to get wrong, as both Claude Code and Codex show: neither handles refresh tokens correctly (as of this writing). Moreover, Dynamic Client Registration (DCR), the method for MCP clients to identify themselves without pre-registration, has been deprecated. Clients are now expected to identify themselves with Client ID Metadata Documents (CIMD), which use an HTTPS URL as their client ID. Adoption is uneven so far, with Claude Code, Claude Desktop, and Claude Cowork using CIMD on user-initiated paths while Cursor and Windsurf still use DCR. There are risks with an improper implementation, such as your tokens being stolen if the runtime harness doesn’t isolate them from the agent or doesn’t implement PKCE.

A strength of OAuth is that it explicitly allows tokens to be opaque such that they don’t have to make sense to the client, and can only be read by the server. For complex workflows that involve more than one verifying party, however, we do want the ability to inspect credentials and see who is authorizing requests!

How KYA-OS inverts the model

A visualization of how KYA-OS gets rid of the Authorization Server requirement in OAuth. Instead, we rely on delegation credentials signed directly by the users. This gives more control to the user, enables interoperability with many identity providers, and gives us transparent audit logs, at the expense of a standardized credential format in the place of OAuth’s opaque access tokens.

KYA-OS changes this flow. We still have Resource Servers and Clients, but KYA-OS removes the central Authorization Server as the source of authority. We go from bearer tokens to capability-based ones, and we use delegations rooted in trusted identities. Identities are defined using a W3C standard called Decentralized Identifiers (DIDs). This gives us a lot of flexibility in how we choose to identify ourselves. Are you a website owner? You can prove it with a did:web identifier, or use an upgraded did:webvh with a verifiable history. Want to use an identity from the blockchain to support on-chain credential revocations? Use a did:cheqd to create a ledger-backed DID. did:key supports an identity built directly on a public/private keypair (this is similar to how you have SSH keys where you share the public key, and keep the private key).

A cool consequence is that with support for passkeys and WebAuthn now commonplace across browsers with sync, users can create DIDs backed by passkeys, stored securely in the browser’s keychain (such as Google Password Manager or iCloud Keychain). This previously required dedicated hardware keys or wallet extensions that supported signing. DIDs are a key ingredient of Self-Sovereign Identity, an emerging model where users manage their own credentials instead of tying them to traditional gatekeepers. Being built on this makes KYA-OS flexible and future-proof.

How do delegations work

Using DIDs and VCs to model agent identity and delegation

Delegations rely on a second W3C standard, Verifiable Credentials. These are documents that are meant to represent cryptographically verifiable and tamper-proof versions of real-world documents like driver’s licenses or university degrees. They have an issuer and a subject, along with a digital signature. In our case, they can be used to represent verifiable versions of delegations of capabilities from a user to an agent, and from agents to other agents.

DIDs are key here, as they identify the subject (e.g., an agent) and an issuer (e.g., you, the user) granting certain permissions (e.g., access to your shopping cart on Instacart).

This is similar to how an OAuth scoped token delegates certain permissions to the holder. Except here, having possession of the delegation credential itself does not give you access to any resources. It merely states that the subject of the credential is authorized by the issuer to access the resource, and a server would then ask the subject to cryptographically prove its identity whenever it tries to access a resource by signing a challenge with its private key. This means delegation credentials do not need to be kept secret like access tokens. A third party gaining access to a delegation credential does not give them access to the resource.

But they can still have built-in expiration dates, and also be revoked in case, for example, the agent’s private key leaks, and we want to rotate it to a new one. In KYA-OS, the way to do so is using the W3C StatusList2021 standard. It has Bitstrings where we set the validity of each credential as a bit. See an example here, which uses a status list resolver running on Cheqd. The best part is that revocation cascades: revoking a delegation automatically revokes every descendant delegation in the chain, so killing a compromised agent will kill every sub-agent it spawned in one action.

A key advantage here is that this enables delegation chains - a user can delegate certain permissions to an agent, and the agent can delegate them to a sub-agent. If we were just sharing an access token, there would be no identity attached to the entity making the requests, and the only option would be to share the full set of permissions that the token carries. With delegation credentials, we have a full chain of authority that we can follow up to the root (the Responsible Party), and it lets parties share only subsets of permissions if we want to (in fact, the spec enforces that child delegations must equal or narrow the parent’s scopes at every link). This has benefits for logging, auditability, and risk management, and gives us more fine-grained control over access to resources.

How does this look when combined with MCP?

Using KYA-OS, the process looks more like this: the user will have a DID tied to their account. This can be a browser based one backed by a passkey, a digital wallet, or one that lives on their system similar to an SSH key. The agent launched by the user also has its own DID, managed by the agent harness. If the user’s key is on their system, they can run a command to delegate permissions for a specific resource (e.g., reading their GitHub repositories) to an agent, generating a delegation credential. If the user has a passkey tied to an account on a certain domain, they can also use the browser to derive a DID and sign a valid Delegation Credential with it.

When the agent makes a request to an MCP server with KYA-OS, it simply attaches a delegation credential and a request signature proving its possession of the DID. Notice how in this case there is no mandatory rendezvous with an Authorization Server!

Can KYA-OS be used with OAuth?

Yes! If you have a setup where you rely on an external identity provider (such as Okta), you can still integrate KYA-OS. In this case, we have a consent service (which can be the application itself or an external service) that hosts DIDs for valid accounts and passes along Delegation Credentials signed by the user. The flow now involves an additional trip to the identity provider to authenticate the user. After this, the consent service can be sure it is receiving a DID for a valid account session. It can then use PKCE to pass along the Delegation Credential VC back to the MCP client. The client uses this to make requests with signed proofs, as before.

Separating the identity and consent services lets us support scenarios like complex enterprise workflows where several agents and people are able to interact with full auditability. We can have transparent, decentralized status lists based on the W3C Bitstring Status List standard. Unlike opaque tokens, delegation credentials carry information about their expiration date transparently, allowing clients to easily recognize when they’ve expired and request new ones.

The DIF also offers an example implementation which lets you wrap any existing MCP server with KYA-OS in just two lines. It adds signed proofs to every tool response and auto-generates an Ed25519 identity for the server.

It’s important to note that OAuth has finalized extensions like DPoP (RFC 9449) and mTLS (RFC 8705). mTLS does X.509 certificate verification for the client as well as the server, and allows us to bind access tokens to specific certificates. This binds tokens to specific clients that manage their own identities, much as delegation credentials do, but it does not address delegation itself.

How would this work with emerging agents like Muse, Instinct, and OpenAI Dots?

Recently, we’ve been seeing a rise in agents that take over your tasks more proactively and run in the background while you’re not interacting with them. Meta’s Muse does not present itself as an agent and uses a full-blown browser in a cloud VM to browse on the user’s behalf. Muse can also impersonate the user on most platforms, using its secure credential store to log in with the user’s username and password. While this is the fastest way to give an agent access to everything without requiring special support from the application, it’s also disastrous if the agent ends up doing something undesirable. There’s no way to revoke its permissions short of changing your password and trying to lock it out of your account, which is tedious and undesirable. A framework that delegates authorization to agents instead of letting them impersonate you is a more sensible way to integrate agentic AI into your workflow.

If you’re familiar with cloud platforms, it’s like giving your agent a separate account with limited permissions on each platform, which gives you the ability to easily manage them from one place.

How can I use KYA-OS?

KYA-OS is great for any scenario where agents have a significant amount of autonomy or need to be traceable. If you’re part of an organization making heavy use of agents, a good first step is to wrap all your MCP tools with KYA-OS, which starts recording a proof for every tool call, along with the identity of the caller. To get started, clone the same repository and try it out!

Vouched.id also offers a complementary platform called Agent Checkpoint Detect which detects agentic traffic on websites and attaches KYA-OS credentials when it finds any. The Enforce half of the platform applies these policies site-wide to agents interacting with your content. One result of having verifiable agent identity with delegations is that governance now becomes easy to define. You can set bespoke policies for resources based on which agents are acting on behalf of whom, and how far down the chain they are. KYA-OS also supports per-tool consent gates, where specific tools can be marked as requiring explicit human approval before they run, which gives you a way to keep a person in the loop when an agent is about to take a consequential action like making a purchase.