No. Traditional model risk management fits stable analytical models, but agentic systems combine prompts, retrieval, tools and dynamic execution. That makes them a governance and access problem as much as a modelling problem. Banks need controls that manage runtime authority, data access and supervisory evidence, not only validation of the underlying model.
Why agentic AI does not fit neatly into old model risk buckets
agentic ai changes the risk shape because it does more than score inputs. It can retrieve information, call tools, chain steps and act over time, so the control question becomes whether the system is allowed to do the thing, on the right data, under the right conditions, with evidence that can be reviewed later. Banks should treat that as a combined governance, access and execution problem, not just a validation problem.
That difference matters most when the system can take actions that affect customers, transactions, records or downstream workflows. A static model can usually be assessed for accuracy, drift and stability, while an agentic system also needs boundaries around what it may see, what it may invoke and when a human must intervene.
What changes in practice for bank control design
The main shift is from testing a model artifact to governing a runtime decision chain. For agentic AI, the bank has to understand the prompt, the retrieved context, the tool set, the policy checks and the approval path as one operating unit. If any of those layers is overly broad, the system can create business impact even when the underlying model is not inherently faulty.
That is why banks should evaluate the full action path, not only the model output. If an agent can read sensitive records, trigger a payment-related workflow or write back into a case-management system, the control objective is to keep that authority explicit, narrow and reviewable. NHIMG’s AI Agent Authorisation Guide is useful here because it frames least privilege for agents as task-scoped and per-action, which is closer to the real control problem than treating the agent like a passive model.
Runtime evidence also becomes part of the control design. Banks need to know which prompt, retrieval set, tool call and human override led to the final action. NHIMG’s AI Agent Observability, Audit and Incident Response Guide supports this shift by focusing on attribution, logging and kill-switch readiness, all of which are essential when a system can act before a traditional model-risk review would even see the event.
For banks building broader governance around agentic systems, NHIMG’s Agentic AI Security Guide maps the problem to inputs, memory, tools, orchestration and identity, which is the right breakdown when the risk crosses from model quality into execution control.
How banks should frame supervision, evidence and escalation
Supervision should be based on what the system can do, not just what it predicts. A bank may be comfortable with an analytical model that recommends a course of action, but much less comfortable with an agent that can fetch data, compare sources, invoke a service and commit an outcome. The practical question is whether the bank can prove that each action stayed inside approved authority and data boundaries.
That leads to a stronger evidence standard than many model-risk teams are used to. Banks should be able to show action-level logs, policy decisions, exception handling and human approvals for material flows. If the system touches regulated records, payments, customer communications or privileged internal systems, the escalation path should be the same class of seriousness as other high-impact operational controls.
OWASP’s OWASP Agentic AI Top 10 is a strong external reference for this framing because it explicitly treats identity and privilege abuse, tool misuse and other agent-specific failure modes as first-class risks. For banks, that means the review should ask not only “is the model accurate?” but also “can this system be induced or allowed to use authority it should not have?”
Risk and Threat Considerations
Agentic systems create a larger blast radius than older quantitative models because they can combine weak prompts, broad retrieval and excessive tool access into a real-world action. The risk is not limited to bad predictions, it includes unauthorized reads, unauthorized writes, tool misuse, and supervisory blind spots when actions happen faster than human review.
Failure mechanism: A model that is only validated as a predictor can still be dangerous if its runtime permissions allow it to retrieve sensitive data, invoke privileged tools or continue an action chain without an effective policy gate.
Impact: The bank can end up with data exposure, incorrect downstream actions, unapproved transactions, weak auditability and a false sense that “model validation” covered the full control problem.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic AI risk here hinges on delegated authority and overbroad runtime access. |
| ASI02 — Tool Misuse | The question centers on whether agents may invoke tools beyond intended scope. | |
| Recommendation — Enforce least privilege and per-action authorization for agent runtime access. Restrict tool access to approved actions and monitor every tool invocation. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Banks need narrower runtime authority for agentic systems than for passive models. |
| AU-2 — Event Logging | Supervision depends on reconstructing prompts, tool calls and approvals. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Agentic systems often depend on service-to-service authentication and delegated access. | |
| Recommendation — Limit agent permissions to the minimum access required for each task. Log agent actions, decisions and overrides at sufficient detail for review. Authenticate non-human actors explicitly before allowing them to act on bank systems. | ||
Practitioner Guidance
What to prioritise: Classify agentic AI by action authority first, then by model type. If the system can read, write, call or commit across business processes, it belongs in a higher-control bucket than a stable analytical model even when the underlying model is not especially novel.
What to verify: Confirm that the agent’s permissions, data scope and approval rules are explicit, testable and logged at the action level. If you cannot reconstruct why the agent took a given step, you do not yet have enough control evidence for material use.
Decision rule: If a system can change state, trigger external effects or handle sensitive data, require runtime authority controls and supervisory evidence before broad deployment; if it only recommends, the review can stay closer to classic model governance.
Practitioner takeaway: The key mistake is treating agentic AI as “just another model” when the real risk comes from delegated authority plus execution, which demands controls that are closer to access governance and operational supervision than to model validation alone.