Why do AI agents complicate traditional model risk management in financial services?

AI agents complicate model risk management because the old framework assumes a fixed, versioned model that changes only when the artifact changes. Agents can alter behavior through tool use, delegated steps, or workflow changes without a model version update. That means standard revalidation triggers can miss the real risk, especially in systems that act across multiple tools and data sources.

Why This Matters for Security Teams

Traditional model risk management was built for bounded models: a known version, a known training set, and a documented change process. AI agents break that assumption because the risk often emerges in orchestration, tool use, memory, and downstream actions rather than in the base model alone. Financial services teams therefore have to supervise behaviour, not just artifacts, and that changes how validation, monitoring, and approval should work.

This is why the current guidance around agentic systems is converging on broader controls such as the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework. They both push teams to account for dynamic behaviour, not only model lineage. NHIMG research on OWASP NHI Top 10 also reflects how quickly agent access paths become security issues when credentials, tools, and delegation are not managed together.

In practice, many security teams encounter the control gap only after an agent has already chained tools, moved data, or executed a workflow that never appeared in the original model approval file.

How It Works in Practice

Agentic systems complicate model risk management because they introduce runtime decisions that sit outside the classic model inventory. A fixed model can be revalidated after retraining, but an agent can change effective behaviour through prompt context, tool selection, retrieval content, task decomposition, or a new workflow integration. That means the control question is no longer only “is this model approved?” It becomes “what is the agent allowed to do, with which tools, under which context, and with what proof of identity?”

For financial services, a more workable approach combines model governance with workload governance. The model itself still needs lineage, testing, and approval, but the agent also needs identity, policy, and task-scoped limits. Best practice is evolving toward runtime authorisation, ephemeral secrets, and workload identity so that access is granted for a specific action and revoked when the task completes. That direction aligns with the CSA MAESTRO agentic AI threat modeling framework and implementation patterns discussed in NIST SP 800-63 Digital Identity Guidelines.

• Use task-level approvals for high-impact actions such as payments, customer data access, or trade execution.
• Bind the agent to a workload identity rather than a long-lived service account.
• Issue just-in-time credentials with short TTLs and automatic revocation.
• Evaluate policy at request time so tool use depends on context, not only pre-set role membership.

NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs both reinforce the operational point: when identities, secrets, and entitlements are not lifecycle-managed together, agent risk moves faster than quarterly model review. These controls tend to break down in multi-tool, cross-domain banking workflows because the agent can traverse systems faster than reviewers can reconstruct the decision path.

Common Variations and Edge Cases

Tighter agent controls often increase latency and operating overhead, requiring organisations to balance safety against workflow friction. That tradeoff becomes sharper in financial services because some agent actions are low-risk and high-frequency, while others are rare but consequential. There is no universal standard for this yet, but current guidance suggests using stricter controls where the agent can initiate external effects, reach customer records, or influence regulated decisions.

One edge case is an agent that never directly touches production data but still shapes credit, fraud, or claims outcomes through recommendations. In those cases, model risk teams should treat the agent as part of the decision system, even if the underlying model is unchanged. Another edge case is retrieval-augmented or multi-agent designs, where the original model approval misses risk introduced by the retrieval corpus, the planner, or the toolchain. The MITRE ATLAS adversarial AI threat matrix is useful here because it captures how attackers abuse the surrounding system, not just the model weights.

NHIMG’s reporting on LLMjacking shows why this matters operationally: once credentials are exposed, attackers move quickly and use the same orchestration paths agents rely on. That means model risk management alone is not enough when the real hazard is an autonomous workflow with delegated access and unpredictable branching.

Related resources from NHI Mgmt Group

• Why do generative and agentic AI create problems for traditional model risk management?
• Why do AI agents complicate traditional API key and secrets management?
• Why do AI agents complicate financial-services audit and response?
• Why do AI agents create new risk in non-human identity management?