Know Your Agent (KYA): Verifying the Agent, Then Limiting It

Fraud teams spent years learning to block bots. Now some of the bots are customers. A shopping agent that buys groceries for a real person, with that person’s permission, looks a lot like the scripted traffic that checkout defenses were built to stop.

Know Your Agent is the industry’s answer to the first question that raises: is this agent legitimate, and who is behind it? Card networks, payment companies and identity vendors have shipped or announced agent verification since 2025.

It is worth being precise about what verification buys. It tells you who is asking. It does not tell you whether this request, on top of everything the agent has done today, is still within what the user allowed. This page covers what KYA means in practice, what each network has built, and the second half of the job: limiting a verified agent.

What Is Know Your Agent (KYA)?

Know Your Agent (KYA) is the verification of an AI agent before it transacts: which agent is acting, which developer or platform operates it, which user it represents, and what that user authorized. It mirrors Know Your Customer (KYC) for people, and is typically implemented with registered agent credentials and cryptographic signatures on the agent’s requests.

The term has two uses. Generically, it names the problem. Specifically, KYA is also a protocol, published with an extension called KYAPay: “Know Your Agent (KYA) is a protocol that provides AI agent developers with a standardized way to identify themselves, the platform they are running on, and the users they represent.” KYAPay “extends the protocol by declaring the user intent and supporting tokenized payment credentials.”

How the Networks Verify Agents

Each network frames agent identity a little differently.

Visa: Trusted Agent Protocol. Visa’s Trusted Agent Protocol repository frames the merchant’s problem as three questions: “Is this a legitimate, trusted, and recognized AI agent? Is it acting on behalf of a specific, authenticated user? Does the agent carry valid instructions from the user to make this purchase?” The agent presents a signature that includes “timestamps, a unique session identifier, key identifier, and algorithm identifier,” and the signature is bound to the merchant’s domain and the operation being performed. Visa says this lets the merchant check that the signature is current and prevent relays or replays.

Mastercard: Agent Pay. On September 30, 2026, Mastercard announced new services for Agent Pay, including “a probability score indicating the likelihood that a transaction was initiated by an AI agent,” and work with Skyfire, “a provider of Know Your Agent (KYA) technology for AI agent identity, verification and payments.” The release places these within an Agent Pay Trust Framework “which brings together identity, intent, controls, execution and intelligence.” For the network’s broader program, see Mastercard Agent Pay.

American Express: ACE. The Agentic Commerce Experiences page lists Agent Registration first among its developer-kit services: “Ensure only verified AI agents are authorized to transact on the American Express network.” The same page says three of the five specifications were available as of April 14, 2026, while “Agent Registration and Cart Context specifications are still under development.” Registration also gates Amex Agent Purchase Protection, covered in agentic chargebacks.

The common shape: a registry of known agents, a credential or key per agent, a signature per request, and a way to tie the agent to a user and an instruction.

How Agent Verification Works on the Wire

Under the program names, Visa and Mastercard share a mechanism. Cloudflare writes that “Both Trusted Agent Protocol and Agent Pay leverage Web Bot Auth as the agent authentication layer.” Web Bot Auth gives an agent “a stable identifier by using HTTP Message Signatures with public key cryptography,” the standard published as RFC 9421.

The agent registers a public key in a directory; Visa and Mastercard each host one for their registered agents. Every request then carries two headers. Adapted from Cloudflare’s example, with the values elided and the tag a paying agent uses, they look like this:

Signature-Input: sig2=("@authority" "@path");created=…;expires=…;keyid="…";alg="Ed25519";nonce="…";tag="agent-payer-auth"
Signature: sig2=:…:

The tag separates browsing (agent-browser-auth) from paying (agent-payer-auth), the nonce guards against replay, and created and expires bound the signature in time. Per Cloudflare’s post, a verifier checks that both headers are present, fetches the key named by keyid from the directory, checks the time window, checks that the nonce hasn’t been seen, checks the tag, rebuilds the signed content and verifies the Ed25519 signature.

That proves a registered key signed this request, for this site and path, within this window, once. It says nothing about what the agent has already spent.

KYA in Visa’s Rules

Visa has also written agent verification into its network rules. The April 2026 edition of the Visa Core Rules and Visa Product and Service Rules requires an Agentic Payment Provider, the application that shops and pays for a cardholder, to “Enroll in and comply with the Visa Intelligent Commerce program and register with Visa, directly or via an Agentic Payment Enabler.”

It must verify the cardholder’s identity under the Visa Intelligent Commerce specifications before it stores a card or acts on an instruction, and before any agentic purchase it must state when the instruction expires and get the cardholder’s acknowledgement that they are responsible for its actions. When it buys, it must “Use only the Cardholder-defined criteria for purchasing the goods or services.”

That last rule is the second half of KYA in one line. Registration says who the agent is. Staying inside the cardholder’s criteria, purchase after purchase, is a check against current state.

KYC vs. KYA

The last row is the point of this page. KYC never told a bank whether a payment was safe; transaction monitoring did. KYA is in the same position.

What a Verified Agent Can Still Get Wrong

Take a properly registered agent with a valid credential and a signed user mandate. Every one of these can still happen:

It overspends across sessions. The same agent runs on a phone and a laptop, or as parallel workers. Each instance is verified. Each checks a budget that does not count the other’s last few minutes.

It loops. A tool call fails ambiguously and the agent retries the purchase. Each retry carries a valid signature.

It acts on a revoked mandate. The user cancels the instruction. The agent’s cached copy still says active.

It is manipulated while verified. Injected instructions on a web page steer a legitimate agent toward a seller or item the user never asked for. Identity is intact; intent is not.

Its credential is stolen. Signatures prove possession of a key, not the absence of an attacker.

None of these is an identity failure. Each is a failure to read current state about the agent at the moment it acts.

Then Limit It: Authorization-Time Context

The second half of KYA is a set of reads made when the agent asks to pay. Call it authorization-time context:

Mandate status and scope. Active, unexpired, not revoked, and covering this merchant, category and amount.

Spend against the mandate. Committed and in-flight spend for this period, across every instance of the agent.

Recent behavior. Purchases in the last few minutes, retries of the same order, new merchants, ticket size compared with this agent’s own history.

Policy version. The caps and blocks in force now, not at the agent’s last restart.

These are derived values that change on every purchase, and every instance of the agent reads them at once. A counter recomputed by a background job gives each instance a validity window during which it can act on a total that no longer exists.

A Worked Example: One Agent, Two Instances

The numbers below are illustrative.

A user authorizes a travel agent to book ground transport for a conference trip, cap $300. The agent runs a planning worker and a booking worker. A dashboard counter refreshes every two minutes.

At 09:00 the counter reads $180 booked. At 09:00:20 the planning worker books a $95 airport transfer. At 09:00:50 the booking worker, rebooking after a schedule change, sees $180 on the counter and books a $110 car for the same leg. Both requests carry valid agent signatures. Both pass verification.

At 09:02 the counter reads $385. The user is $85 over a cap that both workers checked, and holds two bookings for one trip.

Identity worked. Limits failed, because they were read from state that did not include the agent’s own last minute. It is a race condition between two instances of one verified agent.

Holding Agent Limits Correctly

Make the limit check and the spend one transaction, against one row per mandate:

BEGIN;

UPDATE mandates
SET    spent = spent + :amount
WHERE  mandate_id = :mandate_id
  AND  agent_id   = :agent_id
  AND  status     = 'active'
  AND  expires_at > now()
  AND  spent + :amount <= cap
RETURNING spent, cap;                     -- zero rows: ROLLBACK, do not pay

-- Duplicate guard: same item and leg already booked under this mandate?
SELECT 1 FROM bookings
WHERE  mandate_id = :mandate_id AND item_key = :item_key AND status <> 'cancelled';
-- a row: ROLLBACK, do not pay

INSERT INTO bookings (booking_id, mandate_id, agent_id, item_key, amount, status)
VALUES (:booking_id, :mandate_id, :agent_id, :item_key, :amount, 'reserved');

COMMIT;

Under PostgreSQL’s READ COMMITTED, a concurrent UPDATE of the same mandate row waits for the first to commit and then re-checks its WHERE clause against the new values, and the duplicate check that follows sees the first worker’s booking. Revocation is an update to the same row, so it takes effect for the very next request. Store each check’s inputs with the outcome, too; when a dispute arrives, that record is your evidence.

For a single mandate, this is ordinary Postgres and you should use it. It gets harder when the limit is a behavioral one: this agent’s purchases in the last ten minutes compared with its 30-day baseline, or spend across every agent a user has authorized. Those are aggregates over tables every agent writes to at once, and they have to be current when the check runs.

Where Tacnode Fits

The Tacnode Context Lake™ holds the half of KYA that sits with the agent platform or fintech: the decision context each authorization reads and the decision it writes. Mandates, per-agent limits, revocations and decision records held in Tacnode are covered by full ACID transactions, so two instances of one agent cannot both spend past its cap, and a revocation is visible to the next request. Behavioral context, such as purchases in the last ten minutes against a stored baseline, is computed on demand against the latest committed data in the same system. Payment confirmations from your processor or ledger can arrive by change data capture and join that state, as current as the feed. Agent verification stays with the network’s registry and the signature check, and authorization with the issuer; Tacnode enforces nothing inside a card network’s or issuer’s ledger.

That closes the context gap between “this agent is who it says it is” and “this purchase is still within what its user allowed.” For the per-agent limit model, see agent spend limits; for the record each decision leaves, see decision ledger.

FAQ