As AI agents become more capable, they're also becoming increasingly convenient to use. Along with smarter model releases every other week, we've seen the rise of apps like Meta's Muse and Instinct. Using them can be as simple as messaging a number on WhatsApp.
From there, the agent can handle everything from operating a browser to managing your passwords. It can browse the web, keep tabs on events in the background and notify you, and even make payments.
This presents a problem for platforms, which have so far treated logged-in sessions as human and distrusted those that look like bots. Agents sit in a middle ground: their traffic is bot-like in its fingerprint, but dynamic and purposeful like a human's. Some, like Muse, can even conceal that they're automated, which makes them hard to detect.
So what can platforms do? How can they give users a convenient new way to access what they offer, while keeping out malicious automated traffic and holding admitted agents accountable? This is where Know Your Agent (KYA) comes in.
KYC (Know Your Customer) is a well-known process in spaces like financial services, telecommunications, crypto exchanges and custodians, and more. It's often put in place due to regulatory requirements to know who a business is serving, to enforce policies, and to keep a paper trail of running operations. This lets those businesses stay auditable, prove compliance with all regulations, and quickly trace and flag any issues.
Beyond compliance use cases, ID verification is also broadly used to establish accountability and linkability - to make sure the user is responsible for their actions and able to attest that they're a unique individual. This can be a dating app using IDV to add a "verified" badge to signal more trust, or a ride-share app doing its due diligence to make sure its driver actually has a driver's license.
Introducing AI agents, though, complicates things. Bots have always been a presence on the internet, but agents are a new kind of actor. They have the flexibility of people and the ability to follow vague goals and make decisions, all at the speed of machines.
Platforms are split on how to respond. Many have fully embraced the new agent wave by setting up MCP servers, from Gmail to DoorDash, and Shopify recently announced official support for Muse.
Others have shut their doors, such as JPMorgan Chase and Charles Schwab. That's a reasonable move, given the many unknown risks of letting a swarm of probabilistic bots onto your platform.
As we observed in our June report, agentic traffic on the internet has been on the rise. What happens when we look at an agentic internet through the lens of compliance and auditability? Is it a binary choice between embracing new technology and running a reliable business? Or can we get the best of both worlds?
Picture an internet where agents are everywhere, doing everything on behalf of people: buying groceries, booking flights and hotels, even managing asset portfolios.
Things get more complicated in cross-organization or multi-agent scenarios. What if you hire a firm to book travel for your employees, and it wants to use agents to find and book on their behalf? What if your personal agent wants to launch sub-agents with restricted permissions to handle certain browsing tasks?
Current agents operate in one of three ways:
The last two cases count as impersonation rather than delegation: to site operators, those agents are indistinguishable from the users themselves.
When we apply the current regulatory framework to a world where most operations are suddenly done by agents, several challenges come up:
These questions aren't just for eager, proactive site operators. Frameworks like the EU AI Act and the NIST AI RMF push organizations toward a clear understanding of the AI activity on their platforms.
Existing ways of detecting agents, such as simply checking the User-Agent header, fall short here. (Check out our article on detecting agent traffic.)
One way to address these problems is to give agents their own formal identities, along with credentials that represent what they've been delegated to do.
The W3C has open standards we can use to model this, including Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). One project built on them is KYA-OS, under the Decentralized Identity Foundation. It provides a more robust, auditable protocol for the places where OAuth is used today.
In the physical world, people carry IDs issued by trusted institutions like governments, and present them whenever they need to prove who they are. With DIDs, agents prove their identity cryptographically, with a key instead of a face.
Using public key cryptography, each agent gets a public identifier that corresponds to its key. The agent can then prove it owns that key as often as every interaction.
Delegations are stored as Verifiable Credentials: users sign with their own DID keys to specify which scopes they delegate to an agent.
When operators receive a resource request, they know which agent is acting and on whose behalf, which actions it's permitted to take, and for how long. Importantly, they can trace the delegation chain all the way up to the Responsible Party, the human or organization the whole chain ultimately acts for.
Unlike OAuth, this doesn't rely on a centralized authorization server to control how credentials are issued and how long they last. It can be governed in a decentralized way instead, which matters when agents frequently cross organizational boundaries.
An example implementation (KYA-OS-MCP) wraps an MCP server in the protocol, using the primitives above.
A key advantage of KYA-OS is that it doesn't touch the KYC layer at all. Users are identified by DIDs, and those identities can still be verified through traditional KYC processes.
In the specification, this is supported by the Entity Card, which can reference a credential attesting that the Responsible Party has gone through ID verification. The credential states that the party was verified, and at what level, without exposing any personal data.
A verifier then checks the cryptographic claims to confirm that the Responsible Party is the root of the agent's delegation chain.
As a result, we can tie any agentic action back to a verified user. This is similar to how Know Your Business (KYB) verifies multi-layered ownership chains, where KYC is crucial at every level to verify the beneficial owners.
An easy way to summarize it is as follows: KYC establishes who the customer is, while KYA establishes which agent is acting and whose authority it carries. The table below provides an analysis of how the two are different:
| KYC | KYA | |
|---|---|---|
| Who is verified | The human customer, as a single party. The account is the person. | The agent making the request, and the human whose authority it carries. Neither half means much alone. |
| What it cannot tell you | Whether a human or an agent is behind the request being made right now. | Whether the verifier trusts the Responsible Party (the root of the delegation chain). |
| The question it answers | "Is this person who they say they are, and should we serve them?" | "Which agent is this, who authorized it, and how far does that authority reach?" |
| What counts as evidence | Government ID, biometrics, liveness checks: proof that a specific, unique human exists and is present. | A signature from the private key the agent holds, plus a credential the human signed granting it scope. |
| When it happens | At onboarding, with periodic refresh. A person's identity is stable enough for that to hold. | On every request. An agent's model, instructions, or operator can change between one call and the next. |
| How far it reaches | One party. There is no native concept of delegation, though KYB traces ownership chains across organizations. | A chain: the Responsible Party, the agent they authorized, and any sub-agents, each link narrowing the scope it inherits. |
| When something goes wrong | Remediation lands on the person. Flag, freeze, or offboard the account. | Revoke one agent's credential and every sub-agent beneath it, without touching the human's account or their other agents. |
When we have identities bound to agents, we can also establish independent networks that track their reputation and enable community scoring. One example is Knowthat.ai, a Vouched.id-hosted registry storing reputations for over 70,000 MCP servers and clients. It is not meant to be the only registry, though: the open ecosystem backed by DIDs lets anyone run their own based on criteria they value.
KYA-OS is an open standard that composes nicely with KYC and aims to resolve the dilemma between speed and compliance for risk-averse businesses. With KYA and KYC together, we get full auditability and know who the Responsible Party is, while allowing agentic access to resources.
It's important to note that governance and detection go hand in hand. We can't verify whether agents are obeying the protocol if they refuse to identify themselves. This has happened before, for example when AI agents ignored robots.txt while acting on behalf of users.
That's why Vouched.id also offers Agent Checkpoint Detect, a collection of bot and agent detection methods with deployment options for the client side, middleware, and the edge.