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.
Know Your Customer
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.
How the world is reacting to agents
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?
Challenges in adapting KYC to an agentic internet
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:
- through tools built on protocols like MCP, which take access tokens to perform actions;
- by directly taking control of the user's desktop or browser session, as Gemini in Chrome and Claude Cowork do; or
- by taking the user's credentials and browsing on their behalf, which is what Meta's Muse does.
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:
- KYC is often done at specific points in time (such as on registration), with periodic refreshes. This can be enough for humans, but agents can change significantly between requests, for example if the model or system instructions drift over time. We need verification and risk assessment to be continuous, similar to the concept of perpetual KYC, a process that updates identity data and risk profiles in real time.
- Existing methods of Customer Due Diligence (CDD) and Enhanced Due Diligence (EDD) assume humans are in control of every action taken, and the math changes considerably when we throw agents into the mix. How does being able to transact at machine speed change the risk profile of a user? And would we trust an agent operating on behalf of a relatively less trusted party the same as one operating on behalf of a well-known one? How could we compose trust levels of humans and the agents acting for them?
- A user's permissions are limited by their identity. How do we translate that to agents acting on their behalf, and how would we define policies governing how much users can delegate to agents?
- Operators are often required to keep records of user activity (BSA five-year retention, FATF Rec. 11). Agents act at machine speed and can spawn sub-agents, so what does responsible logging and tracking look like in this world? How do we manage responsibility if an agent takes a wrong action on behalf of a user, and how do we tell those actions apart from the ones the user took directly?
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.)
Formally giving identity and delegation to agents
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.
How does KYA-OS address the issues we talked about?
- Continuous verification - the Delegation Credential itself does not act as an authorization to access or modify any resource. Agents instead have to prove their identity cryptographically to the server every time they want to access a resource. The proofs we use here are also specific to the context of the interaction, so they can't be stored and replayed in a fraudulent way outside of it.
- Separate risk - agents having their own identity means that we can assess risk for them separately from the customers. A clear log of activity created by Delegation Credentials provides evidence of how a user is employing agents, and allows operators to adjust their assessments based on the requests coming in.
- Scoped delegation - permissions are managed explicitly through Delegation Credentials. If an agent spawns a sub-agent, it can only delegate a subset of its own permissions to that sub-agent, instead of sharing a broad, general access token. The sub-agent will also have its own identity and be able to present an inspectable delegation chain to the site owner, meaning the site owner can choose how to handle nested levels of delegation.
- Auditability - together, Delegation Credentials and identity proofs give us a fully auditable log of agent actions taken on behalf of a user. Furthermore, since the identity and delegation level of each agent is known, auditors can differentiate actions by which Responsible Party authorized them and which chain of sub-agents carried them out.
An example implementation (KYA-OS-MCP) wraps an MCP server in the protocol, using the primitives above.
KYA complements KYC
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.
Differences between KYC and KYA
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. |
KYA can establish reputation and reliability even in the absence of KYC
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.
Conclusion
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.