They often treat AI governance as a model oversight issue instead of an identity problem. In regulated workflows, the decisive control is whether access, delegation, and evidence are tied to the actor that actually performed the action. Without that link, policy statements do not translate into enforceable controls.
Why This Matters for Security Teams
In finance, ai governance fails when it is framed as a model-risk discussion instead of an identity and authorization problem. The practical issue is not just whether a model is accurate or biased, but whether the system can prove who or what initiated a trade, approved a workflow, or accessed sensitive data. Current guidance from the NIST AI Risk Management Framework and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives points to accountable, traceable control ownership, but many IAM programs still stop at user provisioning and periodic review.
That gap matters because financial workflows are evidence-driven. If an AI agent can invoke tools, move data, or generate instructions without a durable identity trail, auditors cannot reconstruct the decision path and security teams cannot enforce least privilege with confidence. The result is policy theater: governance documents exist, but enforcement breaks at runtime. In practice, many security teams encounter unauthorized AI tool use only after a suspicious downstream transaction or data leak has already occurred, rather than through intentional control design.
How It Works in Practice
Effective AI governance in finance starts by treating the agent, service, or workflow as the operative identity and binding every privileged action to that identity. That means moving beyond static RBAC toward runtime authorization that evaluates context, purpose, and risk at the moment of access. For autonomous or semi-autonomous systems, a standing role is usually too broad and too durable. A better pattern is short-lived, task-scoped access with explicit revocation when the action completes.
Practically, teams should align IAM, PAM, and application controls around four questions:
- What workload or agent identity initiated the request?
- What action was requested, and for what business purpose?
- What data, tool, or transaction class is being touched?
- What evidence is recorded for audit and incident review?
That approach is consistent with the NIST Cybersecurity Framework 2.0, especially where identity, logging, and access governance must be operational rather than policy-based. It also matches NHIMG research on the Top 10 NHI Issues, which emphasizes that poor lifecycle control, excessive privileges, and weak visibility are recurring failure modes. In finance, that translates to JIT credentials, short TTLs, and monitored delegation for AI-driven processes that touch payments, client records, or model outputs.
One useful operational rule is to require a cryptographic workload identity before any agent can call a sensitive API, then pair that identity with policy-as-code checks and complete logging. These controls tend to break down in legacy finance environments where batch jobs, shared service accounts, and brittle vendor integrations cannot be mapped cleanly to a single actor.
Common Variations and Edge Cases
Tighter AI identity controls often increase friction for traders, analysts, and operations teams, so organisations have to balance speed against assurance. That tradeoff becomes sharper in finance because some systems are highly regulated while others are latency-sensitive and difficult to modify.
Best practice is evolving for hybrid cases where a human initiates the workflow but an agent completes part of the action. Current guidance suggests preserving both identities in the audit trail: the human approver, the agent executor, and the policy decision that allowed delegation. This is especially important when working with third-party SaaS tools, where visibility into OAuth grants and delegated scopes is often incomplete. The State of Non-Human Identity Security shows how visibility gaps and over-privilege remain common, while the NIST AI 600-1 Generative AI Profile is useful for mapping governance duties to GenAI-specific risk handling.
For highly automated finance environments, static approval workflows can also fail when agents chain tools across systems, because the original approval does not necessarily describe the later action. In those cases, organisations should re-authorize at each sensitive step rather than assuming one upfront approval covers the entire chain.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | N/A | Agentic systems need runtime authorization and traceable delegation. |
| CSA MAESTRO | N/A | Maps control gaps in autonomous workflows and delegated tool use. |
| NIST AI RMF | AI governance must address accountability, traceability, and risk controls. |
Bind each agent action to workload identity, policy checks, and complete audit evidence.
