Know Your Agent: Why Every LLM Platform Is About to Need Identity Verification
LLMs stopped being text generators and became actors that move money and data. Content filters cannot answer the only question that matters at that point: who is accountable for this action?
For two years the security conversation around large language models was about what they say. Jailbreaks, refusals, guardrails, red-teaming the output. That conversation is now obsolete, because the models stopped being text generators and became actors. They hold API credentials. They call tools. They move money.
Once a model can act, the interesting security question is no longer "what did it say?" It is: who is accountable for what it just did? That question is not answerable with a content filter. It is answerable only with identity.
Key Takeaways
- Agency, not language, is the vulnerability. OWASP ranks Excessive Agency in its Top 10 for LLM applications, and published a dedicated Top 10 for Agentic Applications in December 2025.
- The human check is under active attack. Entrust's 2026 Identity Fraud Report links deepfakes to one in five biometric fraud attempts, with injection attacks up 40% year over year.
- Regulators are already naming the gap. The UK's FCA is telling banks to prepare for "know your agent" checks as AI tools begin making payments.
- The deadlines are real. EU AI Act Article 50 transparency obligations have applied since 2 August 2026, with fines up to €15 million or 3% of worldwide turnover.
- The standards are unfinished. Three separate IETF drafts are competing to define delegated agent authorization — and every one of them terminates in a human principal who has to be verified by something.
Excessive agency is the real vulnerability class
OWASP's Excessive Agency entry describes the problem precisely: an LLM-based system is granted the ability to call functions or interface with other systems, and the decision about which function to invoke is frequently delegated to the model itself, based on input prompts or on its own prior output. Agent systems chain these calls, feeding each result into the next invocation.
The vulnerability is what happens when that chain executes a damaging action in response to ambiguous, unexpected, or adversarial input. The model does not need to be "hacked" in any classical sense. It needs only to be persuaded, and it has been designed to be persuadable.
This is serious enough that OWASP's GenAI Security Project published a separate Top 10 for Agentic Applications in December 2025, treating agentic systems as a distinct threat surface rather than a footnote to LLM security.
Note what mitigating excessive agency actually requires. Every recommended control — minimum necessary permissions, human-in-the-loop approval, scoped tool access, complete audit logging — presupposes that you know which principal the agent is acting for. Permissions are meaningless without an identity to attach them to. You cannot grant least privilege to an anonymous actor.
The fraud data: the human check is the thing being attacked
The obvious answer is to verify the human at the point of authorization. Attackers know this, which is why the verification step itself is now the target.
Entrust's 2026 Identity Fraud Report found deepfakes linked to one in every five biometric fraud attempts, with injection attacks — feeding synthetic video directly into the verification stream, bypassing the camera entirely — rising 40% year over year.
Sumsub's Identity Fraud Report 2025-2026, drawn from more than four million fraud attempts, reports that while the overall global fraud rate is stabilising, high-quality sophisticated attacks rose 180% across 2024-2025. The pattern is a shift from volume to precision: fewer attempts, each far harder to catch.
The strategic implication is uncomfortable. Generative AI simultaneously (a) makes agents capable of consequential action, and (b) makes the cheapest identity checks — a selfie, a document photo, an OTP — unreliable. Weak verification and autonomous agency are a bad combination, and they are arriving together.
This is why passive liveness and injection-attack detection stop being a nice-to-have the moment an agent can spend money on a user's behalf. The verification step is now adversarial infrastructure, not a form field.
Regulators got there before the standards did
In June 2026, senior officials at the UK's Financial Conduct Authority told The Banker that banks should start preparing for a new era of "know your agent" checks. Their reasoning is that agentic commerce — AI that shops, transacts, and manages accounts for users — forces banks to rethink how they establish who is on the other end of a transaction.
That framing has spread quickly. Industry commentary in American Banker makes the same point from the compliance side: there is a new entity accessing banking systems, checking balances and transferring funds, and it is not a person.
Meanwhile the hard compliance dates are already live. As of 2 August 2026, the transparency obligations in Article 50 of the EU AI Act apply to providers and deployers of certain AI systems, with the European Commission's guidelines adopted on 20 July 2026. Non-compliance can trigger fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher, and the regulation reaches any provider placing AI on the EU market or whose outputs are used there (Cooley).
Add the obligations that already existed — AMLD6 customer due diligence, MiCA for crypto-asset services, DORA operational resilience for financial entities, GDPR for the identity data itself — and a regulated firm deploying agents is not waiting for a future rulebook. It is already inside four.
The standards gap, and why it always lands on a verified human
The protocol layer is visibly unsettled. There are at least three active IETF drafts attacking delegated agent authorization from different directions:
| Draft | Approach |
|---|---|
| Agent Authorization Profile (AAP) for OAuth 2.0 | Extends OAuth 2.0 and JWT with structured claims so systems can reason about agent identity, task context, and operational constraints. |
| OAuth Profile for Delegated AI Agent Authorization | Defines grant types for delegation to an agent acting on a user's behalf. |
| Agent-Delegation header | Carries a chain of attenuated delegation links across administrative domains; each link narrows scope and shortens expiry, and a verifier checks every link. |
These drafts disagree about mechanism. They agree about shape: a delegation chain, where each link is narrower than its parent, and the chain is only as trustworthy as its root.
That root is a human. An attenuated delegation chain proves an agent was granted scope by someone — it says nothing about whether that someone is real, sanctioned, of legal age, or the same person who opened the account. Cryptography can prove delegation happened. It cannot prove the delegator exists. That is an identity-verification problem, and no OAuth profile will solve it.
What this looks like architecturally
The practical pattern separating the two concerns:
- Verify the human once, properly. Document verification, passive liveness, and face match at onboarding, with injection-attack detection — because this is the step attackers are targeting.
- Bind the agent credential to that verified identity. The agent's token references a verified principal rather than a bare account ID, so scope can be reasoned about.
- Screen the principal continuously, not once. Sanctions and PEP status change after onboarding. An agent authorised in January may be acting for a sanctioned person by June.
- Re-verify on risk, not on schedule. Step up to biometric authentication when the agent crosses a value threshold or changes behaviour, rather than re-running full KYC on a calendar.
- Log the whole chain. Human identity, agent credential, action, and decision — because Article 50 and AMLD6 both eventually ask you to reconstruct who authorised what.
The important design point is that steps 1 and 3 are ordinary identity infrastructure. The genuinely new work is step 2 — and it is only tractable if step 1 produced something worth binding to.
How Didit fits
Didit is infrastructure for identity and fraud: one API across the Authenticate → Verify → Monitor lifecycle, with public pay-per-use pricing and no minimums.
For the verify-the-human step, User Verification (KYC) covers ID Verification at $0.15, Passive Liveness at $0.10, Face Match 1:1 at $0.05 and IP Analysis at $0.03 — or the full KYC bundle at $0.33, with 500 free checks per month on the core features. Age Estimation ($0.10) matters for consumer AI products facing age-assurance rules, and Reusable KYC is free, so a user verified once is not re-verified by every agent they authorise.
For the ongoing-risk step, AML Screening runs $0.20 per check across 1,300+ lists, with ongoing monitoring at $0.07 per user per year. Transaction Monitoring is $0.02 per transaction with a fiat and crypto rule engine plus case management and SAR workflow; Wallet Screening / KYT sits inside it at $0.15 per check. Business Verification (KYB) starts at $2.00 per business with UBO extraction, for agents acting on behalf of companies rather than consumers.
For the wiring, the MCP Server, Workflow Orchestrator and SDKs are free — which means an agent framework can call verification as a tool without a separate licence negotiation.
Underneath: 220+ countries, 14,000+ document types, 1,000+ data sources, 200+ fraud signals, sub-2-second inference, and a 5-minute integration. SOC 2 Type 1 and Type 2 (Type 2 issued 30 July 2026), ISO/IEC 27001, and iBeta Level 1 PAD certification for the liveness claims. Didit's verification is formally attested by an EU member-state government — Spain's Tesoro, Banco de España and SEPBLAC — as safer than in-person verification. 2,000+ companies run it in production.
The honest summary
Identity verification is not becoming mandatory for LLMs because of a single regulation. It is becoming mandatory because of a convergence: models gained the ability to act, the cheap identity checks became forgeable at the same moment, regulators started asking who authorised the action, and the delegation standards being drafted to answer that question all bottom out in a human whose existence someone has to prove.
Content safety was the 2024 problem. Accountability is the 2026 one, and accountability is spelled identity.
FAQ
What does "know your agent" actually mean?
It is the extension of customer due diligence to autonomous software acting for a customer. In practice it means establishing which verified human or business a given agent is authorised by, what scope it holds, and keeping an auditable record — rather than treating the agent as an anonymous API client. UK FCA officials have publicly urged banks to prepare for exactly these checks.
Why isn't OAuth enough for AI agent authentication?
OAuth and the agent-authorization drafts extending it can prove that scope was delegated down a chain, and can narrow that scope at each link. What they cannot do is establish that the person at the root of the chain is real, of age, and not sanctioned. Delegation and identity are different problems; agent authorization assumes a verified principal rather than producing one.
How do deepfakes change identity verification for AI products?
They move the attack from the document to the verification pipeline itself. Entrust's 2026 report links deepfakes to one in five biometric fraud attempts and records a 40% year-over-year rise in injection attacks, where synthetic video is fed straight into the stream rather than shown to a camera. Passive liveness with injection detection, rather than a selfie comparison, is the relevant control.
What are the concrete compliance deadlines?
EU AI Act Article 50 transparency obligations have applied since 2 August 2026, with Commission guidelines adopted 20 July 2026 and fines up to €15 million or 3% of worldwide annual turnover. Firms in financial services should read that alongside existing AMLD6, MiCA and DORA obligations, all of which already require reliable customer identification.
Does an agent need its own verified identity, or is verifying the human enough?
Both, for different reasons. The human establishes accountability and satisfies due-diligence obligations. The agent credential establishes scope — which actions this particular agent may take, for how long. Verifying only the human leaves you unable to constrain or revoke an individual agent; issuing agent credentials without a verified human leaves you unable to say who is responsible.
Related articles
- The UK's first A7 alert describes a network built to pass identity checks
- A four-digit merchant code decided whether memecoin buyers faced KYC
- Korea let a crypto exchange pull government records for KYC instead of asking for documents
- FinCEN's Banque Misr proposal names one bank and 103 front companies
- All 400 wealth managers refresh KYC now, but 26% record no expected activity
- The travel rule is being rewritten for every cross-border payment, not just crypto