TL;DR
Know Your Agent (KYA) uses a machine-readable, transaction-scoped credential to prove an autonomous agent’s identity and authorization, complementing OAuth, API keys, machine identity, and IAM.
- OAuth delegates scoped access, while KYA identifies the autonomous agent and binds its authority to a transaction.
- An API key authenticates possession of a secret, while KYA identifies the agent using it.
- Machine identity verifies a workload or process, while KYA verifies whether its agent may perform a specific action.
- Traditional IAM manages users, roles, and sessions, while KYA covers autonomous actions that occur without a human present.
Is KYA the same as OAuth?
No. OAuth delegates access, while OpenID Connect adds authentication for a subject. An OAuth access token uses scopes such as contacts:read to specify permitted actions, but those scopes do not describe what kind of entity requests access. Even structured permissions can define a payment amount or merchant without identifying the requester as an autonomous agent.
Standard token claims leave the same gap. The sub claim identifies the subject, azp identifies the authorized client, and actcan identify an actor in a token exchange. Those claims do not reliably distinguish a deterministic service, supervised assistant, or autonomous agent. Proposed OpenID Connect for Agents claims such as agent_type, agent_instance_id, and delegation constraints aim to add that context, but they extend OAuth and OIDC rather than change their core purpose.
KYA supplies an identity layer that a service can evaluate underneath or alongside OAuth. A KYA credential can describe the verified agent and its transaction-specific authority, while OAuth still controls access to the protected resource. For example, a service could validate a Skyfire KYA token for agent identity and payment authorization, then apply OAuth scopes to determine which API operations the agent may perform.
Is an API key an agent identity?
An API key is not an agent identity. A key authenticates a connection by proving that the caller possesses a valid string. It does not inherently identify the agent, the human or business responsible for it, or the transaction the owner approved. Every agent sharing the key therefore appears as the same caller.
API keys also provide limited control over autonomous actions. Permissions often apply to every request made with the key, and revocation typically requires rotating the credential across every dependent service. Audit logs can show that a key performed an action, but they may lack an ownership record connecting that action to a particular agent and authorization.
A reported PocketOS incident illustrates the risk. In April 2026, a Cursor agent working on a staging task reportedly found a broadly privileged credential and deleted a production database. The credential allowed the request without checking whether that specific agent could perform that specific deletion.
A KYA credential carries agent identity and authorization metadata. The verifier can evaluate the agent and its permitted action for one transaction, while expiration limits how long the credential remains usable. API keys can still authenticate service access, but they cannot provide those agent-level proofs by themselves.
How is KYA different from machine identity?
Machine identity verifies workload provenance, while KYA verifies whether an agent may perform a specific action. SPIFFE, SPIRE, cloud workload identity, service accounts, and mutual TLS establish that a process runs under an expected identity. A machine identity represents a non-human actor, such as a container, virtual machine, or serverless function.
SPIRE strengthens that assurance through node and workload attestation. It can check cloud metadata, container attributes, or an image hash before issuing a short-lived credential. Those checks establish that the expected workload runs in the expected environment. They do not determine whether an autonomous decision, such as spending $300 with a particular merchant, falls within the agent’s current authority.
KYA adds action authorization at the transaction layer. A KYA credential can identify the agent, describe its delegated authority, and bind that authority to a particular transaction or validity window. Skyfire issues a KYA token that can connect verifiable agent identity with payment authorization, so a merchant can evaluate the agent and the proposed purchase together.
Both identity layers can operate in the same request. A workload can use SPIFFE or a cloud service account to authenticate within your infrastructure, then carry a KYA token when acting on an external marketplace. Revoking one transaction does not require replacing the workload’s underlying identity.
How does KYA relate to traditional IAM?
KYA extends traditional identity and access management to autonomous software that initiates actions without a human present. IAM governs workforce identities, provisions access, and supports human approval. KYA identifies the agent and verifies its authorization for a specific action.
Traditional IAM assigns roles before work begins and often trusts an authenticated identity for the duration of a session. An agent may call several external systems within seconds, while its required permissions change with each task. Predefined roles can multiply into unmanageable role explosion, while broad standing privileges expose resources the current task does not require. Session trust also provides limited control over agents that act across services without human intervention.
Shared service accounts create a separate attribution problem. When several agents use one credential, audit logs cannot reliably identify which agent performed an action, which weakens incident response and compliance evidence. Per-agent identity preserves that attribution.
A KYA credential can bind one verified agent to a defined transaction, permission scope, and expiration window. You can revoke that authorization without disabling the agent’s broader account. Traditional IAM remains necessary when employees create, supervise, or approve agent activity. A KYA layer becomes necessary when the agent acts independently and each action requires its own verifiable authority.
Mechanism comparison: what actually verifies an agent
Each mechanism verifies a different subject or permission.
|
Mechanism |
What It Verifies | Static vs. Continuous | Revocable at Transaction Level | Built for Autonomous Agents |
|---|---|---|---|---|
|
API keys |
Possession of a shared secret | Static | No | No |
| OAuth/OIDC | Delegated access and user or client claims | Token lifetime | No |
No |
| Machine identity | Workload or service provenance | Short-lived, renewable | No |
No |
| Traditional IAM | User, role, and session permissions | Session or policy based | No |
No |
| KYA | Agent identity and authorization for a specific action | Per transaction | Yes |
Yes |
KYA in practice: enterprise use cases
Marketplace checkout requires proof tied to both the agent and the purchase. An API key authenticates an application, while OAuth records delegated access. Workload identity identifies the running process, and traditional IAM records the buyer’s standing permissions. A KYA credential lets the marketplace verify an authorized buyer-agent at transaction time rather than treat it as unidentified bot traffic or require human MFA for each purchase.
Fintech agents need narrower spending authority than standing credentials usually provide. A payment credential can restrict an agent to a specific amount, merchant, and time window. The issuer can revoke one transaction without rotating a shared API key or ending every active session. Skyfire’s KYA token and Agentic Wallet provide an existing example by tying verifiable agent identity to transaction-scoped payment authorization.
KYA and KYC: related but distinct
KYA verifies what an autonomous agent is and what actions or transactions it may perform. KYC verifies a person or legal entity to meet compliance requirements. Read Skyfire’s full KYA definition for details on agent identity and authorization.
FAQ
Is KYA the same as OAuth?
No. OAuth delegates scoped access, while KYA identifies an autonomous agent and connects its identity to a specific authorized action. The two mechanisms can work together in one request.
Is an API key an agent identity?
No. An API key proves that a caller possesses a valid secret, but it does not identify the individual agent, its owner, or its authority for a particular transaction.
How is KYA different from machine identity?
Machine identity verifies that a workload, service account, or process is running as an expected entity. KYA verifies that a particular agent may perform a particular action, such as completing an authorized purchase.
How does KYA relate to traditional IAM?
Traditional IAM manages users, roles, sessions, and workforce access. KYA adds identity and transaction-level authorization for autonomous agents that act without a person present.
Does an agent need KYA if it already has OAuth, IAM, or machine identity?
An agent needs KYA when another business must verify the agent itself and its authority for a specific action. OAuth, IAM, and machine identity can remain in place because they answer different trust questions. Skyfire’s agent authentication and authorization guide explains how to select and combine these tools.
The bottom line on agent verification
No single mechanism verifies an autonomous agent end to end. A complete stack combines existing access controls with KYA, which supplies transaction-scoped identity and authorization for agent actions.
Businesses that let autonomous agents check out or spend on a user’s behalf should add KYA now. They can retain their current identity controls while using KYA to verify who the agent represents and whether each transaction falls within its authority.
