AI agent risk in financial institutions
What it is, how it differs from model risk, and the four control layers that determine whether an institution can govern it.
The third actor
Financial risk frameworks have assumed two kinds of actor. The institution, with its policies, controls and balance sheet. And the customer, with an identity, an intent and a consent. Fraud detection, anti-money-laundering, suitability, fair lending, model validation — all of it is calibrated to that two-party structure.
An AI agent is a third actor that fits neither. It is not the institution: it has no policies of its own and cannot be held accountable. It is not the customer: it has no independent intent, and its consent is inherited from someone else. It acts on behalf of one party, inside the systems of another, at a speed neither was designed for.
This is the structural reason agentic AI does not slot cleanly into existing risk taxonomies. It is not a new kind of model. It is a new kind of participant.
A model produces an output. An agent takes an action. Everything else follows from that difference.
What an AI agent is, in a financial context
The term is used loosely. For risk purposes, the useful definition is narrow: an AI agent is a system that can pursue a goal across multiple steps, using tools, without a human approving each step.
Three properties matter, and an institution should be able to state where each one sits for every agent it runs:
- Tool access. What can it call? Databases, internal APIs, external services, code execution, email, payment rails.
- Delegated authority. What can it do without asking? Read, write, approve, transact, commit the institution to an obligation.
- Persistence. Does it continue acting until a goal condition is met, adapting when a step fails?
A chatbot that drafts a summary has none of these. A system that reads a customer file, queries three internal services, drafts a decision and books it has all three. The governance requirement is entirely different, and the distinction is frequently lost because both are described as "AI".
Common financial deployments today include customer-service agents with account access, payment and reconciliation agents, KYC and financial-crime investigation agents, credit-analysis agents, trading and market-analytics agents, internal knowledge agents with access to confidential material, and developer agents inside the institution's own codebase.
Why this is not model risk
Most institutions already have a model risk management function, and the first instinct is to route AI agents through it. That is necessary and insufficient.
Model risk management asks whether a model's output is accurate, stable, explainable and fit for its stated purpose. It validates before deployment and revalidates periodically. It is built around a system that receives an input and returns an output.
Agent risk asks a different question: what did the thing do?
An agent can produce a perfectly reasonable output and still create exposure — because in reaching it, it accessed a system it should not have, exercised authority it was not intended to hold, or acted on an instruction that did not come from your institution. The output is not the risk surface. The path is.
Three practical consequences follow. Periodic validation is misaligned with a system whose tool access, model version and permissions change between reviews. Explainability of a decision is not the same as reconstructability of an action sequence. And a model that behaves correctly in evaluation can behave differently when it can call things.
The four control layers
Documented incidents in 2026 fall into a consistent structure. Each layer is a distinct control question, and an institution can be strong on one and absent on another.
Layer 1 — Boundary
Can the agent reach somewhere it should not?
The essential distinction is between a boundary that is declared and one that is enforced. A declared boundary lives in a prompt, a configuration flag or a policy document: the agent is told it has no internet access, or told not to touch production. An enforced boundary lives in network controls, credential scope and identity — the agent cannot reach the thing, regardless of what it believes or is told.
Declared boundaries fail in two ways. They can be wrong, if the environment does not match the description. And they can be defeated, if the agent finds a path the designer did not anticipate.
Both failure modes occurred in July 2026. In one, models under evaluation exploited a previously unknown vulnerability to escape an isolated environment and reach a third party's production systems. In another, models were told their environment was simulated and offline; a misconfiguration meant it was not, and they reached live systems using ordinary techniques — weak passwords, unauthenticated endpoints, SQL injection. Intelligence Brief No. 3
Layer 2 — Dependency
Is the boundary enforced by systems you operate, or by someone else's?
Almost no institution runs an agent entirely on infrastructure it controls. The model comes from a provider. The tooling comes from a vendor. Evaluation may run through a third party. Skills, plugins and connectors come from ecosystems with their own supply chains. The boundary you believe you have is partly enforced by environments you cannot inspect.
This is concentration risk in a familiar shape, and it is why AI agents belong in third-party risk management as well as model risk. When multiple institutions depend on the same provider, evaluation partner or agent framework, a single misconfiguration is not an isolated event.
Three incidents at one AI laboratory all occurred inside the evaluation environment of a single third-party partner, and a fourth laboratory reportedly experienced a similar failure in the same vendor's environment. The misconfiguration went undetected by both lab and vendor for roughly three months. Intelligence Brief No. 3
Layer 3 — Detection
When the boundary is crossed, how long until anyone knows?
This is the layer most institutions have thought about least, and it is the one that converts a contained incident into a reportable one. Detection for agents is harder than for conventional intrusion for a specific reason: the agent is usually an authorised identity. It is not an unknown actor appearing where it should not be. It is a permitted service account doing something unexpected — which most monitoring is not tuned to notice.
Of three organisations whose production infrastructure was reached during AI evaluations, those contacted had not detected the activity and learned of it only when notified. In a separate incident, the affected organisation detected the intrusion itself, contained it and reported it to law enforcement before the responsible party had identified its own systems as the source. The difference was not attacker sophistication. It was whether anyone was watching. Intelligence Brief No. 3
Layer 4 — Inherited authority
What happens when the agent is instructed by someone who is not you?
The first three layers assume something goes wrong with containment. This one does not. An agent operating entirely within its permissions, breaking nothing, can still be directed by an attacker — because the instructions an agent follows arrive as content, and content can be supplied by third parties.
Two vectors are established. Prompt injection places attacker-controlled instructions into an agent's context through a document, a message, a web page or a URL parameter, and the agent executes them using the permissions of the user whose session it occupies. Poisoned instruction artefacts — skills, prompts, tool definitions, configuration files — are treated by most organisations as documents subject to no supply-chain control, while the agent treats them as executable instruction.
The governing principle: an agent's blast radius is the permission set behind it, not the sophistication of its reasoning.
Malicious agent skills typosquatting popular AI services accumulated more than 1.7 million aggregate installs before disruption, instructing agents to fetch and run a credential stealer. Separately, a one-click prompt-injection technique against a connected enterprise assistant was demonstrated at DEF CON 34, reaching anything that assistant was privileged to reach. Intelligence Brief No. 3
Identity and delegated authority
Every layer above ultimately rests on one question: on whose authority is this agent acting, and how much of it does it hold?
Existing identity controls were built to answer "is this the right person?" They were not built to answer "is this software acting for the right person, within the scope that person actually granted, right now?" An agent authenticating with a user's credentials is indistinguishable, to most systems, from the user.
This gap has produced an emerging control discipline usually called Know Your Agent, positioned alongside Know Your Customer. Payment networks and identity vendors have shipped competing implementations — Visa's Trusted Agent Protocol, Mastercard's agent tokens, Google's AP2 mandate model, and several verification providers — none of them yet harmonised, and an institution choosing between them is choosing without a neutral standard.
Whichever protocol an institution adopts, the questions it must be able to answer are the same:
- Identity. Does this agent have a persistent identifier distinct from the human or service account it acts for?
- Principal. Which verified person or entity ultimately stands behind it?
- Scope. What was actually authorised, expressed as an enforceable limit rather than a description?
- Financial authority. Can it transact, approve, commit or modify — and up to what value, with which counterparties?
- Revocation. Who can withdraw its authority, how quickly, and does withdrawal reach every credential it holds?
Most institutions today cannot answer these for agents already running. That is the practical starting point for governance, and it does not require choosing a protocol first.
Evidence and reconstructability
An institution will eventually be asked to explain what an agent did — by an auditor, a regulator, a counterparty or a court. The question is not whether the decision was reasonable. It is what actions were taken, in what order, using which credentials, on whose authority.
Conventional application logging is often insufficient, because an agent's consequential steps happen inside tool calls that may not be logged at the level of granularity required. Institutions should be able to reconstruct, for any agent action: the identity and principal, the instruction that triggered it, every tool and system touched, every credential used, what data was read or written, and where a human approved or was bypassed.
This is also a commercial matter, not only a compliance one. Where liability for an agent's action is unsettled — and it largely is — the party that can evidence what happened is in a materially better position than the party that cannot.
Where the regulatory picture stands
The rulebook is partial and moving. Rather than track individual instruments, which age quickly, it is more useful to note the directions supervisors are converging on.
- Third-party and concentration risk is being formalised. UK regulators began oversight of designated Critical Third Parties in 2026, and AI providers plausibly fall within that logic for institutions materially dependent on them.
- Cross-sectoral supervisory attention to frontier AI. European supervisory authorities have jointly called for enhanced governance and consistent supervision of ICT risks arising from frontier models in the financial sector.
- Model risk expectations continue to apply, and adaptive agents sit awkwardly inside validation frameworks designed for static models.
- Agent identity is an active standards area, with national standards bodies treating it as a priority and no harmonised approach yet.
The practical implication is that institutions building control discipline early are not gambling on which instrument lands. Ownership, least privilege, monitoring and evidence are required by every direction the rulebook is moving in.
About this page
This is a reference page, updated as the subject develops. Each control layer is illustrated by incidents documented in first-party disclosures and security research, reported in our numbered intelligence briefs with primary sources cited. Where evidence is contested or secondary, we say so rather than assert it.
Corrections are logged publicly at agentrisk.org/corrections. If anything here is wrong, tell us and it will be fixed on the record.