Know Your Agent: The Identity Layer B2B Now Has to Build
Every twenty years or so, B2B compliance picks up a new identity-verification layer. The layer that arrives is usually the one the previous decade's commercial infrastructure was not designed to handle.
The 1990s gave commercial banking Know Your Customer. KYC turned customer onboarding from a relationship document into a structured verification capability that every B2B operator with a financial product now treats as ordinary. The 2010s gave enterprise procurement Know Your Vendor. KYV turned supplier diligence from a one-time legal exercise into a continuous monitoring discipline, and SOC 2, ISO 27001, and the vendor-risk-management category grew up around it. Both layers are now boring in the best sense. They are part of how serious businesses operate, and the operators who skipped them when the category was new spent the next decade catching up.
The 2020s are giving B2B operators a third layer, and the work to build it began in earnest about six months ago. In October 2025, Visa unveiled the Trusted Agent Protocol, a framework for secure communication between AI agents and merchants, developed with Cloudflare. In March 2026, Mastercard introduced Verifiable Intent with Google, alongside an Agent Pay roadmap. In April, the FIDO Alliance announced its Agentic Authentication and Payments Technical Working Groups, and Experian launched Agent Trust with ecosystem partners including Visa, Cloudflare, and Skyfire. In mid-May, FIDO confirmed its founding chairs and contributions, with chairs from CVS Health, Google, and OpenAI, and Google's Agent Payments Protocol (AP2) and Mastercard Verifiable Intent named as the foundation contributions.
The shape of those announcements is consistent. The card networks, the credit bureaux, the identity providers, the model vendors, and the standards body that owns multi-vendor identity have all decided the agent counterparty has to be verifiable. The way I read this is straightforward: the third twenty-year layer is Know Your Agent. The B2B operator question is no longer whether the layer will exist. It is what to build to.
What Know Your Agent actually is
Know Your Agent is the operator-side capability to verify the presence, authority, action scope, and audit trail of an AI agent interacting with your business. Two directions matter equally. The first is incoming agents reaching your commercial surfaces (your pricing page, your product API, your support endpoint, your ordering system). The second is outgoing agents acting on your behalf (your staff's email assistants, your sales copilots, your procurement agents, your developer agents). KYA is the same capability in both directions, applied to a different counterparty.
The parallel to KYC and KYV is exact in shape and different in substance. A KYC check answers "is the counterparty real?". A KYV check answers "is the counterparty trustworthy at the organisation level?". A KYA check answers "is this software permitted to act for the principal it claims to represent, in the way it is asking to act, right now?". The third question is the one most B2B operators have no existing capability for. They have an identity provider, but the identity provider does not on its own verify the delegation. They have an authorisation system, but the authorisation system was designed for humans clicking buttons. They have an audit log, but the audit log treats a service-account action as one event when it was in fact a chain of agent decisions made on the principal's behalf.
The mechanism that makes KYA a distinct compliance category is delegation. KYC verifies the human counterparty: this person is who they say they are, and we have evidence sufficient for our regulator. KYV verifies the vendor counterparty: this supplier has the controls we need them to have, and we have continuous evidence of that. KYA verifies software acting on behalf of a named principal, with a delegated scope, and a provable trail of what it did. KYC and KYV were not designed for that, and stretching them to cover agents produces compliance theatre rather than a working control.
This is why the industry-side standards work matters. FIDO Alliance, Visa, Mastercard, Google, Experian, Cloudflare, and Okta are not building competing identity stacks. They are building the pieces of a shared verification model that B2B operators will plug into. The operator question is which pieces they buy and which pieces they build, and that depends on the layer.
What most B2B operators are getting wrong
The most common assumption I see in B2B leadership conversations is that agent identity is a security problem the identity provider will solve. Okta, Microsoft Entra, Google Cloud Identity, Ping, ForgeRock: somebody in that list is already in the technology stack, the assumption goes, and they will handle this when the time comes.
That assumption is incomplete in a specific way. Identity providers solve the authentication layer. They verify that an entity is who it claims to be. They do not on their own verify what an entity is authorised to do, on whose behalf, within what scope, and with what audit trail. Solving authentication alone produced the gap Okta's Asia Pacific and Japan leader Dan Mountstephen described in a Fortune column on 13 April 2026. Drawing on Okta's own research and findings from API management firm Gravitee, the column put the numbers in one place: 91% of organisations already use AI agents, only 10% have a clear strategy to manage them, only 22% treat AI agents as independent identities, and close to 90% have already recorded suspected or confirmed security incidents involving AI agents. Mountstephen framed it precisely: agents are behaving "exactly as configured, in systems that were never designed to account for non-human identities".
The second mistake is treating KYA as a future-state experiment because the agent population looks small. The evidence runs the other way. Stanford's 2026 AI Index Report shows real-world agent task success rising from 20% in 2025 to 77.3% in 2026 on the Terminal-Bench benchmark, with cybersecurity-task success rising from 15% to 93% in the same window. Microsoft has now priced agent governance as a $15 per user per month standalone SKU, bundled into the $99 per user per month E7 suite, with Agent 365 reaching general availability on 1 May 2026. Stripe shipped an integrated agent identity, permissions, payments, fraud, and reporting stack at Stripe Sessions 2026, including agent-tagged API keys and approval rules that apply uniformly to agent and human actors.
The third mistake is the one I find most interesting, because most operators make it without noticing. The assumption is that KYA is somebody else's problem to solve. The bank's. The card network's. The LLM vendor's. The platform's. In twenty years of running technology functions, the pattern I keep seeing is that compliance work which sits at the boundary between the operator and the network always becomes operator work in the end. KYC started as a banking obligation and is now embedded in onboarding flows that every B2B operator with a financial product runs themselves. KYV started as a procurement obligation and is now embedded in the security questionnaires every B2B SaaS company answers. KYA will follow the same shape. The networks will publish the standards. The operators will evidence the controls. The auditor and the insurer will ask the operator, not the network.
That is the readiness gap. KYA is a current commercial readiness category that sits with the operator. Most operators in scope will recognise that about twelve months later than they should.
The KYA Stack: four questions, four layers
If KYA is the new compliance category, the operator question is what to build to. The framework below is the one I have arrived at after several months of tracking the industry-side standards work and comparing it with the operator-side audit and procurement signals. It is built around four layers, each with a defining question. The layers are sequential: each one depends on the one below it. Action scoping is meaningless if authority is unverified. Audit is meaningless if you cannot tell the agent from a human in the first place. The framework is reusable. If your team is talking about agent identity and cannot answer one of the four questions, you have found the layer that needs work.
Layer 1: Presence
Defining question: Is the entity interacting with my business an agent at all, and which one?
This is the most immediately actionable layer. The capability is the ability to detect that an inbound interaction is being driven by an AI agent rather than a human, and to identify which agent and which platform. Visa's Trusted Agent Protocol, Cloudflare's role in both that protocol and Experian Agent Trust, and the broader push toward Web Bot Auth all sit here. The discovery-layer protocols that have arrived over the past six months (ACP, UCP, AP2) all assume presence detection is solved before any commerce conversation begins. If your commercial surfaces (pricing pages, product APIs, support channels, ordering endpoints) cannot distinguish an inbound agent from a human, every downstream layer of the stack fails by default. The first practical investment for most B2B operators is making sure their edge infrastructure (CDN, WAF, API gateway) can identify agent traffic and route it to a different policy than human traffic.
Layer 2: Authority
Defining question: On whose behalf is this agent acting, and is that delegation provable?
This is the layer where the most visible industry-side work is concentrated. Google's Agent Payments Protocol, now a foundation contribution to the FIDO Payments Technical Working Group, uses cryptographically signed Intent, Cart, and Payment mandates to encode the chain of authorisation. Mastercard Verifiable Intent, co-developed with Google, addresses the agent-intent verification problem at the network level. Experian Agent Trust's Agent Trust Token creates what Experian describes as a "secure, verifiable link between consumers and AI agents". FIDO's Agentic Authentication Technical Working Group, with chairs from CVS Health, Google, and OpenAI and vice-chairs from Amazon, Google, and Okta, is building the multi-vendor standard for delegation. A procurement team will not authorise an agent-led transaction it cannot evidence, and the evidence has to be present in the agent's request itself, not in a later phone call. The operator-side question is which of these standards your authorisation infrastructure can ingest, today and twelve months from now.
Layer 3: Action
Defining question: What is this agent allowed to do here, and how do I enforce that at the point of action?
This is where the largest operator-side gap currently sits. The Okta and Gravitee figures from April 2026 (91% of organisations using agents, 22% treating them as independent identities, close to 90% reporting agent-related security incidents) are the clearest market-wide measurement of how few operators are doing the action-scoping work. Microsoft's decision to price agent governance as a $15 per user per month line item through Agent 365 is the market putting a number on the work most operators have not yet started. Stripe's Sessions announcement bundled identity, permissions, payments, fraud, and reporting into one offering precisely because most operators will not build action-scoping themselves. The action layer needs continuous enforcement, not a one-time check at the door. An agent's authorisation may be valid at request time but its action may exceed scope at execution time, and the enforcement has to happen at the second moment, not the first. My read of the current market is that the agents already operating in most B2B environments are inheriting a human's full authority, which is exactly the risk the Okta numbers describe. That is a live risk, not a hypothetical one.
Layer 4: Audit
Defining question: Can I prove, after the fact, what this agent did, on whose authority, and within what limits?
This is the layer where AI assurance, AI insurance, and enterprise customer assurance reviews converge. AP2's cryptographically signed mandates double as an audit record: they create a tamper-evident chain of the intent, the cart, and the payment, with named signatures at each step. ISO/IEC 42001 and the AICPA's emerging AI-extensions to SOC 2 are the early standards bodies' answers to the question of what audit-ready AI controls look like. FIDO's Payments Technical Working Group explicitly lists trusted transaction execution as in scope, which translates to a durable, reviewable record of what executed and under what authority. The operator-side question is whether your existing audit infrastructure can ingest agent action data in a form an auditor or underwriter would accept. If your audit log treats a service-account action as one event when the underlying agent made twelve decisions, you do not yet have agent audit. You have a service-account log with an agent on top of it.
How the four layers relate
The four layers read as a dependency chain. Presence is the precondition for authority. Authority is the precondition for action scoping. Action scoping is the precondition for meaningful audit. The industry-side standards work is moving fastest on layers 1 and 2, where Visa, Mastercard, Google, Experian, and FIDO have been concentrated. The operator-side work has barely begun on layers 3 and 4. That asymmetry is where the commercial readiness risk sits, and it is what makes KYA an operator priority rather than a standards-watching exercise. The pieces sit alongside other commercial and technical readiness work that B2B operators are now being asked to evidence in customer assurance reviews.
What this means for B2B leaders
Three pressures land on the operator at different speeds.
Procurement lands first. The agent-identity questions that appeared in enterprise security reviews from April 2026 onwards are going to keep appearing, and the answers your sales team is currently giving are not yet a full KYA posture. Expect the questionnaire to ask which of your products are reachable by agents, on which protocols, with which authority schemes, and with what action and audit controls. The pattern is the same shape as the early SOC 2 questionnaire shift in the 2010s, but the gap between question and evidence is wider this time, because the underlying technology is moving faster than the auditor's reference material.
AI assurance lands second. ISO/IEC 42001 certifications and AICPA-aligned SOC 2 engagements will increasingly ask for evidence of agent action audit. If you cannot produce a per-agent action log with the principal, the scope, and the timestamps, you do not have a clean audit. The assurance posture you sell into the enterprise will be the assurance posture you can evidence, not the one you describe.
AI risk underwriting lands third. The early signals from Lloyd's syndicates and specialist coverholders like Armilla AI and Testudo are that AI policies will be priced against the quality of the operator's agent-identity controls. The market is forming and the underwriting questions are not yet standardised, but the direction is clear enough to plan around. The operators with a coherent KYA capability will be cheaper to insure than the ones without, and that price gap will widen as the loss data accumulates.
The categories most affected by all three pressures are the ones that have always sat at the leading edge of identity-related compliance: B2B SaaS, payments, identity-adjacent products, and regulated B2B (financial services, healthcare, government). The pressure starts there and works outward. If you operate in one of these segments, your timeline is shorter than it looks. If you operate outside them, your timeline is longer, but the same questions will reach you, on a 12 to 18 month delay.
What to do next
Two practical moves for this quarter are narrow enough to assign to a person.
First, audit which agents are already operating in your environment, in both directions. For inbound agents (the ones your customers' tools are sending into your commercial surfaces), can you identify them at the edge, route them to a separate policy, and log their actions distinctly from human traffic? For outbound agents (your staff's email assistants, sales copilots, procurement copilots, developer agents), can you name the agent, identify the principal, evidence the delegation, and produce a continuous action log? If the answer is no for either direction, you are working at Okta's 22%, and the gap to close is operationally specific.
Second, decide which layers of the KYA stack you build versus buy. The networks (Visa, Mastercard, Experian) and the platforms (Microsoft Agent 365, Stripe's agent stack, Google AP2 inside Cloud) are offering integrated capability on the lower layers. The presence and authority layers (1 and 2) can mostly be bought; choosing which standards to support and which provider to align with is the consequential decision, not the build itself. The action and audit layers (3 and 4) are operator work. They depend on your specific data, your specific scopes, your specific audit infrastructure, and they are not something a network can do on your behalf. Sequencing the build-versus-buy decisions in that order concentrates the build effort where it actually has to be.
The asymmetry to remember is that the standards work is on a 12 to 24 month horizon, while the procurement, assurance, and insurance pressure is on a 6 to 12 month horizon. Operators who wait for the standards to settle before starting the operator-side work will arrive too late. Similar logic applies to the parallel machine-readable differentiation work that sits one layer above this in the AI-mediated buying stack.
Of the four layers (presence, authority, action, audit), which one has the most explicit owner in your organisation today, and which one has none? The honest answer is usually where the work starts.
Sources: Visa, "Visa unveils Trusted Agent Protocol", press release, 14 October 2025: usa.visa.com. Mastercard, "How Verifiable Intent builds trust in agentic AI commerce", March 2026: mastercard.com. FIDO Alliance, "FIDO Alliance to develop standards for trusted AI agent interactions", 28 April 2026: fidoalliance.org. Experian, "Experian launches Agent Trust", 30 April 2026: experian.com. FIDO Alliance, "The agentic era is here. Now we need to make it trustworthy", 14 May 2026: fidoalliance.org. Dan Mountstephen, Fortune (commentary), 13 April 2026: fortune.com. Stanford HAI, "The 2026 AI Index Report", April 2026: hai.stanford.edu. Microsoft Security Blog, "Microsoft Agent 365, now generally available", 1 May 2026: microsoft.com. Stripe, "Everything we announced at Sessions 2026", 29 April 2026: stripe.com. Cloudflare, "Forget IPs: using cryptography to verify bot and agent traffic", May 2025: blog.cloudflare.com. Lloyd's of London, Armilla AI coverholder profile: lloyds.com. Testudo, "Lloyd's syndicates commit more capacity to generative AI liability insurance", 26 February 2026: testudo.co.