Banks Are Blind to 88% of Their Agentic AI Risk Surface

The frameworks your risk team uses were built for a different kind of model

SR 11-7 is a validation framework. It asks whether a model produces accurate outputs given its specification — nothing more. It was never written to answer what happens when an AI agent autonomously executes a multi-step transaction, acquires capabilities beyond its declared scope, or acts on instructions smuggled into a document it retrieved itself.

Those aren't hypothetical edge cases. We've watched institutions hit all three in production, usually without the vocabulary to classify what just happened, because the risk catalogue they're validating against doesn't contain it.

We spent the past year building a risk atlas that does contain it: 185 catalogued risks across banking and financial services AI deployments, 21 governance domains, and — critically — a crosswalk showing which frameworks cover each risk and which don't.

So what: if your model risk register was built against SR 11-7, NIST AI RMF, or ISO/IEC 42001 alone, assume it has structural gaps around anything your institution now lets an AI system do, not just say. That gap needs a named owner before your next model risk committee meeting, not after an incident forces the question.

How the atlas separates two genuinely different risk architectures

The atlas splits into two registers because a chat assistant answering a customer question and an agent autonomously processing a loan application don't share a risk surface — they fail through different mechanisms with different consequences.

The non-agentic register covers GenAI without autonomous action: chat assistants, RAG pipelines, summarization, document classification. It runs to roughly five dozen risks across nine domains, with "Chat" alone carrying close to half of them — unsurprising, since a customer-facing assistant sits at the intersection of prompt injection, jailbreak attempts, data elicitation, and regulatory boundary violations simultaneously, in real time.

The agentic register covers systems that plan, call tools, invoke external APIs, and execute multi-step workflows without a human reviewing every step: 107 risks, of which 98 — 92% — are genuinely new failure modes introduced or materially amplified by autonomous operation, not SR 11-7 risks with a new label. We built both registers against NIST AI RMF, the OWASP LLM and Agentic AI Top 10 lists, MITRE ATLAS, the MIT AI Risk Repository, ISO/IEC 42001, and the EU AI Act, then layered in BFSI-specific failure modes from incident analysis and adversarial testing.

So what: if your governance committee reviews "AI risk" as a single line item, split it. The controls that work for a RAG pipeline — input filtering, output review — don't touch a tool-calling agent's risk surface at all.

Tool & Affordance Risk is the domain with no precedent in model risk management

When an agent can call APIs, write to databases, or send payment instructions, the governing question stops being "what does this model say?" and becomes "what does this model do?" Of the eleven risks in this domain — excessive permission acquisition, tool-call manipulation, privilege escalation through tool chaining, irreversible action execution without confirmation — nine are rated High or Critical, and none appear in SR 11-7.

We've sat in rooms where a model validator confidently signed off on an agent's underlying LLM and had no framework at all for the agent's actual permissions, because validating the model in isolation tells you nothing about what it can touch once deployed with live tool access.

So what: you cannot validate a tool-calling agent by evaluating the model alone. Validation scope has to include the agent's actual tool grants, actual downstream systems, and red-team testing against those specific permissions — infrastructure most banks haven't built yet.

Multi-Agent Security is a network problem wearing a model problem's clothes

Once agents start coordinating — an orchestrator delegating to sub-agents, agents sharing memory, agents calling each other as tools — the risk moves to the network layer: prompt injection that propagates between agents, trust-boundary violations where a sub-agent acts on instructions it can't verify, cascading failures where one compromised sub-agent corrupts everything downstream of it.

Eleven risks sit in this domain, over 70% rated High or Critical, and every one of them needs controls — agent authentication, inter-agent message validation, execution-boundary enforcement — that sit outside any model risk management framework currently in supervisory use.

So what: if more than one agent touches a workflow, your control inventory needs an entry for the handoffs between them, not just for each agent individually. That's where the exposure actually lives.

RAG is the most under-secured deployment pattern in most banks today

A RAG pipeline's retrieved content is itself an attack surface. A document the model treats as trusted context can carry embedded instructions that redirect its behaviour or exfiltrate data — and a guardrail that only inspects the user's prompt and the model's final response never sees it happen.

Indirect prompt injection via retrieved content is one of the highest-severity risks in the non-agentic register and one of the least commonly tested, because most guardrail deployments stop at the conversation layer and never look at the retrieval step itself.

So what: if your RAG security review only covers the chat interface, you have not reviewed RAG security. Add a control that inspects retrieved documents before they reach the model's context window.

Governance and accountability gaps are an institutional problem, not a technology one

Across both registers, eighteen catalogued risks trace back to undefined ownership, missing evidence trails, inadequate monitoring, and ungoverned shadow usage. A technically well-defended AI deployment can still carry enormous regulatory exposure if nobody can produce evidence of who owns it and what controls were active when it acted.

We've watched exam teams ask the same question in every jurisdiction we work in: not "is the model safe," but "who owns this, and can you prove it." Institutions that deployed AI without a governance process — not without a safety layer — are the ones that struggle to answer.

So what: before your next examination, make sure every AI deployment in production has a named accountable owner and a control-evidence trail that doesn't require a week of cross-team archaeology to produce.

What to do with the atlas this quarter

1. Filter by deployment pattern first. Chat assistant → start with the Chat domain. RAG pipeline → start with RAG. Any agent, regardless of what it does → start with Tool & Affordance Risk and Multi-Agent Security; those two carry the highest unaddressed severity in almost every institution we've reviewed.
2. Triage the 106 High/Critical risks before the rest. For each one, the question isn't "do we know this risk exists" — it's "do we have a tested control, a named owner, and evidence on file."
3. Check the framework crosswalk, not just the risk description. A risk with no mapping to NIST AI RMF or ISO 42001 isn't low-priority by default — it may be exposing a gap in those frameworks that your regulator will ask about anyway.
4. Compute residual exposure per domain, not a checkbox. "We have a guardrail" is not a control-effectiveness score. Inherent severity minus actual, tested control effectiveness is the number that belongs in front of your board.
5. Re-scope what "model risk management" means inside your institution. A risk register that covers validation and performance monitoring but not tool risk, multi-agent security, or agentic governance is a register for the AI you were running three years ago.