What is Know Your Agent (KYA), and how it applies to four common use cases

Organizations are introducing AI agents across departments, and people are increasingly comfortable using agents for personal and work tasks.

AI companies are improving agents’ reasoning capabilities and investing in safeguards. But agents still introduce security concerns because it’s hard to predict their behavior, and many security models aren’t equipped to handle probabilistic reasoning.

Know Your Agent (KYA) describes a process for gathering information to understand the risk an AI agent might pose. But it isn’t actually a single process. Instead, KYA can vary depending on the environment and use case.

What is Know Your Agent (KYA)?

Know Your Agent, or KYA, is a general framework for understanding AI agents, the people behind them, and the risk that agents may pose. The specifics can vary depending on the use case, but KYA generally helps you answer several important questions about a user:

• Is the user an agent or a human?

• If it’s an agent, who is behind the agent?

• Can you trust the users, employees, and developers behind the agent?

Organizations can use KYA to help secure different types of agentic experiences, including agentic commerce (when someone uses an agent to make a purchase) and enterprise agents (when someone uses an agent to access a company’s resources).

The three dimensions every KYA program balances

Similar to Know Your Customer (KYC) and Know Your Business (KYB) processes, every KYA decision can lead to a trade-off among three things:

• Assurance. How confident you need to be in the results before you approve or deny a request. For example, you might need a higher level of assurance when an agent requests write access to a database than when it requests read access. Or, when an agent wants to make a $1,000 purchase versus a $10 purchase.

• Friction. The time and effort an agent or person has to take to complete the KYA process. Requiring lengthy KYA checks can increase assurance and security, but adding friction can also lead to frustration. If the process happens at onboarding, you might lose users entirely.

• Privacy. The information you request, whether it’s personally identifiable information (PII), and whether a user or agent wants to share the data. Collecting more information might help you make more precise decisions, but you want to be respectful of each user’s right to privacy. There also may be regulatory requirements related to how much (or little) data you collect, where you can process it, how you can use it, and when you have to delete it.

It’s difficult to optimize all three at once. In general, higher assurance comes from collecting more data about users or agents. Some verification checks may also increase friction, particularly when they require the user behind the agent to verify their identity with a government ID or selfie verification.

The four main KYA use cases

People often discuss KYA as one thing, but we’ve found people and companies deploy agents in many different contexts. Distinguishing between these use cases is important because they can impact the KYA processes you want to use.

We focus on four primary use cases for KYA today:

• Agentic commerce

• Authenticating first-party agents at an enterprise

• Authenticating third-party agents at an enterprise

• Authenticating agents that have access to PII

Each use case has its own relying party (the person or organization that needs to verify the agent) and different requirements for friction, privacy, and assurance.

1. People and businesses using agents for online purchases

With agentic commerce, the relying party is the merchant or payment service provider (PSP) that wants to confirm an agent has permission to make a purchase.

The main concern is balancing friction with fraud prevention. For players who issue funds or cards, there may also be anti-money laundering requirements for onboarding new users and monitoring transactions.

Too much friction can result in lost business when prospective customers, or their agents, decide to shop elsewhere. At the same time, approving an unauthorized agentic purchase can lead to disputes and chargebacks.

In this context, KYA should help the merchant or PSP determine:

• Did the right human authorize the agent to make a purchase?

• Is the specific purchase within the user-defined authorization limits?

• Is there an audit trail and documentation for chargeback representment?

For people shopping with an agent, companies like Lithic, a fintech issuer/processor, create programmable cards that give cardholders more control over where, when, and how much an agent can spend money. Robin Gandhi, Lithic’s chief product officer, shared his thoughts on agentic commerce with Persona in a guest blog post.

He also discussed KYA on the Persona community podcast, Personally:

2. Enterprises building first-party agents

Many companies are creating agents for internal use, which makes the organization the relying party. In these first-party enterprise use cases, KYA can help the company determine:

• Who authorized the agent?

• Should the person be able to authorize the agent?

• Is the person still in control of the agent?

• Does the agent have authorization to access a system or perform a task?

• Regardless of the person behind the agent, is the agent acting within company policy?

Similar to how Know Your Workforce checks can extend KYC into the employee life cycle to help prevent data breaches and account takeover, first-party KYA extends Know Your Workforce into the agent life cycle.

In these circumstances, assurance is a priority and organizations might introduce high-friction flows to improve security at select moments. However, they also want low-friction processes for employees who want to use the agent for everyday tasks. They may be able to leverage a wide range of signals to accomplish this because employees are using company-owned devices and agents to access the company’s systems.

3. Enterprises granting access to third-party agents

With third-party agents at enterprises, the relying party is still the organization hosting the agents. However, because the organization didn’t develop and doesn’t control the agents, it needs to be extra cautious about supply-chain attacks, data sharing, and unauthorized API use.

With both first- and third-party agents, the organizations can start KYA and prompt employees to verify their identities at onboarding and specific moments, including:

• An agent attempts an unpermitted action: For instance, an agent with read-only access wants write access to perform a user-requested action.

• The session token expires: An organization-defined time period could require users to periodically reverify their identity and their agent.

• The user is on a new device or in a new location: A reverification could be required when an employee attempts to access an agent from a new device or location.

• An agent makes unusual requests: Agents may need to reverify if systems detect abnormal behavior for the agent, such as unusually high request volume or the agent trying to access systems or apps that don’t align with its intended purpose.

4. Organizations allowing agents to access PII and other sensitive data

Organizations need to pay special attention to agents that might access PII and other sensitive data. For example, a health clinic that wants to use an agent to help patients create accounts or understand test results.

In some cases, the organization will still be the relying party, but there are also situations where that responsibility gets passed to the identity verification provider or identity and access management platform.

No matter which organization acts as the data controller, there can be serious regulatory and reputational risks related to data breaches, and agents could provide a new attack vector for external and internal threat actors. In these situations, privacy and assurance have to be a priority, even if it requires a high-friction experience.

Agents also need to be deployed in a manner that aligns with local regulations. For example, if the agent can access Protected Health Information (PHI) at a covered entity or its business associates in the US, the agent’s deployment will need to comply with HIPAA. Or, agents that may process EU residents’ data will need to comply with the GDPR.

How KYA compares to KYC

KYA focuses on verifying an agent’s identity or access, and KYC focuses on meeting compliance requirements when onboarding and monitoring users at financial institutions. However, in some circles, KYC has also become shorthand for identity verification (IDV) in general.

In the KYA context, verifying the individual behind the agent can be the most important step, especially for access management and account takeover detection. IDV can also tie the agent to a specific individual, which can be helpful for authentication, access management, and audits.

How does KYA fit into agentic AI security?

Agentic AI security is the general framework for the tools, controls, policies, and processes that you can use to keep your agents secure and your environment safe from agents. KYA describes the more specific processes you use to verify the identity and authorization for an agent and the person or organization behind the agent.

In short, KYA is part of agentic AI security, but your overall security setup will address a wider range of concerns and challenges.

For example, broader agentic AI security systems are designed to:

• Defend against prompt injection: A malicious input can redirect an agent’s goals or actions even if its identity is fully verified.

• Secure the supply chain: Agents are built on third-party models, frameworks, and tool integrations. Any of those components can be compromised before you deploy the agent.

• Monitor agent behavior continuously: Agents act autonomously and quickly, so it’s important to monitor their behavior to identify anomalies, drift, and malicious activity.

• Apply least-privilege access: A verified agent should only reach the resources it’s authorized to access and needs for a given task.

• Protect data in transit and at rest: Encryption and data minimization controls should apply regardless of whether an agent is verified.

• Maintain human-in-the-loop authorization for high-risk actions: Some decisions need a human review, which may include reauthorizing or reverifying the person before allowing the agent to continue.

KYA can tie the agent to an individual who may ultimately be responsible for the agent’s actions, which is important when you need an audit trail or if there’s a disputed transaction. However, similar to how many organizations have a zero trust framework for employees, you shouldn’t assume an agent is safe just because it’s verified.

How Persona helps organizations build and implement KYA

There isn’t a one-size-fits-all approach to go from the conceptual framing to deploying KYA. Each use case has different requirements, and even organizations that have similar use cases will have varying business goals that affect their ideal assurance, friction, and privacy controls.

However, it’s not all theoretical. Persona is actively working with several companies on KYA solutions.

The card issuer Lithic, mentioned above, is one. Crossmint is also building a payment layer for agentic commerce, including wallets, stablecoin rails, virtual cards, and programmable spending controls. And AstraSync uses Persona to build a KYA infrastructure that verifies the people behind each agent and the agent itself.

We’re able to support diverse use cases because organizations can pick and choose which aspects of our verified identity platform they need. These include:

• Relay: Quickly establish proof of humanness with minimal PII.

• Government ID and selfie liveness verifications: Collect and verify your choice of government-issued IDs across 200+ countries and territories, and verify live selfies to bind agents to real humans.

• Passive signals: Silently collect device, network, and behavioral signals to gain insight into users and agent-driven journeys.

Contact us if you want to discuss how to build and implement identity verification and KYA.