Know Your Agent (KYA): Baselayer Identity Suite for Banks

Banks already know how to ask "can I trust this business?" They do not yet have a standard way to ask the same thing of software that opens accounts, buys APIs, and moves money on someone else's behalf.

On September 22, 2026, Baselayer — a 2024 identity and risk shop founded by Timothy Hyde and Jonathan Awad — launched an Agentic Identity Suite alongside a $35 million Series A led by M13 (Torch Capital, Picus Ventures, Afore Capital, and Socure's Matt Thompson also participated). The product names that matter for builders are Know Your Agent (KYA) and counterparty verification, not the round. The company says the same network that already verifies businesses for 2,300+ financial institutions (claimed as one in five U.S. FIs) now extends to agents.

This is the bank-side twin of stories explainx.ai covered the same week: NVIDIA OpenShell (what the agent is allowed to do on a machine) and Perplexity SPACE egress tests (whether the sandbox actually holds). KYA asks a different question: who does this process represent, and should the other party proceed?

TL;DR — what KYA actually is

What people are asking after the headline

Is this just KYB with a new acronym?

Mostly yes, and that is the point. KYB (know your business) is the stack Baselayer already sells: verify the entity, score risk, watch for fraud rings. KYA copies the same questions onto a new subject: an agent that is not a legal person and does not carry a driver's license.

Hyde's quote in the release is the useful one: agents "don't carry ID," so static fraud rules either block legitimate automation or miss a scripted attack that looks like a customer. The suite is supposed to let an institution know cryptographically which agent it is dealing with, who it represents, and whether its own agent should proceed.

If you already instrumented agent traces for security platforms, you have action evidence. KYA wants principal evidence. Those logs are complementary: a clean OpenShell session that still cannot prove it is ACME Corp's authorized procurement bot will fail a bank.

Did Stripe really say 70% of API commands are agents?

Baselayer's release attributes to Stripe, June 2026, that 70% of commands used to access data through its API now come from AI agents. explainx.ai did not independently audit Stripe's telemetry. Treat it as the number the identity vendor chose to put in a fundraising PR — directionally consistent with agent checkout and Mastercard Agent Pay for Machines, not a figure to paste into a board deck without Stripe's own write-up.

The rest of the "agentic commerce is here" paragraph is similarly vendor-stacked: Visa, Mastercard, and American Express shipping agent protocols; Shopify turning on agentic sales channels by default for roughly a million merchants. Those are real product directions. They still do not tell a mid-market bank how to map agent_id to a beneficial owner.

Why a fraud consortium instead of another SSO product?

Awad's framing is historical: trust layers for new commerce modes get built after fraud is unbearable. The suite includes an interoperable trust layer and an agentic fraud consortium — shared signals across FIs so a burned agent identity or mule pattern is not rediscovered bank by bank.

That is closer to card-network fraud sharing than to Okta. It also means your agent's reputation may not be local. If a consortium flags a harness, model, or integrator, every participating FI can apply the same freeze. Builders who rotate API keys and think they have a new identity will be surprised if the graph keys off stable cryptographic agent IDs instead of IP addresses.

KYA vs NVIDIA OpenShell vs agent wallets

These three get conflated in feeds because they all say "trust" and "agents." They sit on different layers.

OpenShell is containment. NVIDIA's September 28, 2026 platform pairs an Apache 2.0 sandbox with optional BlueField-4 Sentry so policy is not "the model promised." That is the right tool when your threat is space escaping, covert channels, or unauthorized tool use — the class Perplexity documented in SPACE Part I.

KYA is attribution. A bank does not care that your gVisor jail is pretty if it cannot bind the transaction to a customer file. Google Cloud's sandbox note that egress often beats hypervisor choice is the same lesson in ops language: the money leaves on the network, not through a VM escape.

Wallets are instruments. Cloudflare Wallets, Mastercard AP4M credentials, and x402 payers bound spend. They do not, by themselves, tell a correspondent bank that the bot is allowed to represent a Delaware LLC. Nevermined appearing on both Baselayer's partner list and Mastercard's AP4M partner set is a hint that identity vendors and payment vendors are courting the same integrators.

Do not "choose KYA instead of OpenShell." If you ship an agent that spends, you want runtime policy, principal binding, and capped rails. Missing any one is how you get a demo that works in staging and a freeze on day one of production.

What the suite claims to do (and what it does not)

Claimed product jobs

1. Know the agent — cryptographic identity, not a User-Agent string.
2. Know the principal — the human or business the agent represents.
3. Know the mandate — what it is allowed to do (authorization), not only who it is.
4. Know the other side — counterparty verification so your agent does not pay a mule.
5. Share risk — consortium so repeated agent fraud is a network problem.

Awad's CEO line in the release: they already help one in five U.S. FIs answer "can I trust this business?"; now they want "can I trust this agent, who does it represent, and what is it allowed to do?"

What is not in the press release

• Schema for agent credentials (DID, X.509, FIDO passkeys, proprietary tokens — unnamed).
• Latency, SLA, or on-prem vs SaaS deployment for KYA specifically.
• How disputes work when the agent and the human disagree (the "my bot was jailbroken" chargeback).
• Independent attestation that $1 billion in prevented losses is KYA-era rather than classic KYB.

Until those land in a developer guide or an examiner letter, treat KYA as distribution plus a product name, not a spec you can implement against.

Standards names to actually track

Baselayer says it is in the FIDO Alliance Authentication Working Group, Legal Context Protocol, and the x402 Identity Working Group with Cloudflare, Google, Visa, and Mastercard. For builders, the last one is the practical hook: if you already meter tools with x402, identity on that rail is how a 402 payment stops being an anonymous prepaid drip.

Legal Context Protocol is the unsexy one that will matter in contracts: what law and mandate attach to an agent action. If your agent signs a vendor agreement, someone has to say whether that signature binds the company. KYA without legal context is a risk score looking for a lawyer.

FIDO in this setting is a bet that phishing-resistant auth patterns extend to non-human clients. That is still an open design fight (device-bound keys vs software agents in CI). Do not assume your GitHub Action can pass FIDO the way a laptop can.

What builders should do this week

You do not need a Baselayer contract to prepare for KYA-shaped questions. You need artifacts a bank or processor will eventually request.

1. Name a principal per agent. Not "the marketing bot." A legal entity, a cost center, and a human owner on-call. Store it next to the runtime id.
2. Separate identity from capability. OpenShell-style allowlists answer capability. Put mandate (max spend, merchants, hours, tools) in a signed document the wallet and the bank can both hash.
3. Log the triple. agent_id, principal_id, counterparty_id on every money-adjacent tool call. Your observability stack already has traces; add those three fields before a vendor asks.
4. Assume reputation is portable. If a consortium exists, rotating a Cloudflare Worker URL will not reset you. Design so a compromised skill cannot mint a new "clean" agent identity without the principal's key.
5. Do not confuse vaults with KYA. Products that store agent passwords are secret stores. They do not tell a correspondent bank who you are.

If you sell to enterprises, write a one-pager that maps your agent to KYB fields they already collect: legal name, beneficial owners, expected transaction graph. That document will get you further in 2026 than a slide that says "we use GPT."

What banks and FI teams should do

If you already run Baselayer (or a peer KYB vendor), the question is whether agent onboarding is a new product or a new entity type on the old form.

• Inventory agents as counterparties. Treat "our customer's Claude" as a third-party processor with standing authority, not as a browser.
• Demand cryptographic binding, not a checkbox that says the chatbot is in-policy. If the vendor cannot show how an agent ID is issued, revoked, and disputed, you are buying a dashboard.
• Keep runtime controls in-house. KYA will not sandbox a rogue tool call. Pair identity with egress policy and agent security monitoring.
• Stress the consortium. Shared fraud data helps you; it also creates correlated freezes. Know your appeal path before you depend on it for revenue agents.

The M13 partner quote from Karl Alomar is the investor version of the same stack: agents as economic actors, identity as infrastructure, distribution (2,300+ FIs claimed) as the moat rather than a whiteboard protocol. That is why this story passes explainx.ai's "what you build or pay" test: your agent's ability to transact will be gated by whoever already owns bank distribution, not by whose README has the prettiest DID.

Honest limitations

• Primary source is a company press release. No independent customer named with a KYA go-live date in that copy.
• Partner list is a logo salad (FIS, Prove, Socure, Exa, Parallel Web Systems, Natural, Nevermined, Lane, "and more"). Partnership ≠ production KYA.
• Funding is real as announced; product maturity is not proven by the round. $35 million buys GTM, not a completed identity standard.
• Stripe 70% and $1 billion prevented losses are cited, not reproduced here.
• No public schema means open-source harness authors cannot implement "KYA-compatible" in a weekend.

What this means for what you build or pay

If you build agents that never leave your VPC, KYA is optional until a SaaS you call starts charging per identified agent. If you build agents that pay, book, or onboard, budget for:

• a wallet or card credential with caps (AP4M, Cloudflare Wallets, or issuer tokens);
• a runtime that constrains tools (OpenShell or equivalent);
• an identity mapping a bank will accept — which may arrive as Baselayer, a card-network Verifiable Intent blob, or a processor's proprietary agent ID.

You will pay for the last one as onboarding friction and vendor take-rate, not as a cute API call. The institutions that already collected KYB files do not want a second greenfield identity graph. That is Baselayer's bet, and it is why KYA is more interesting than another $35 million AI headline.

Related on explainx.ai

• NVIDIA Open Agent Safety Platform (OpenShell + Sentry) — runtime trust, not principal identity
• Top AI agent security platforms in 2026 — watching what agents do after they are admitted
• Mastercard Agent Pay for Machines — payment rails that still need a who
• Perplexity SPACE escaping, Part I — why sandbox identity is not bank identity
• Cloudflare Wallets for AI agents — spend instruments with owner caps
• September 28 coverage-gaps digest — where this item first landed as a brief
• x402 Monetization Gateway — pay-per-call rail now growing an identity working group
• Official: Baselayer Series A / Agentic Identity Suite (PR Newswire)

Product names, FI counts, fraud-loss figures, and partner lists above reflect Baselayer's September 22, 2026 announcement. Verify against current bank integrations and working-group drafts before you design production identity around KYA.