Agent IAM in finance exposes the gap between AI speed and compliance

At a glance

What this is: This is a finance-focused analysis of agent IAM that finds AI policy gaps and weak IAM coverage are slowing production adoption.

Why it matters: It matters because financial institutions need identity controls that can govern AI systems, satisfy regulators, and avoid creating unmanaged access paths across NHI, autonomous, and human programmes.

By the numbers:

• 79% of organisations still lack AI policies, according to Ory’s analysis of EMA survey results.
• More than 60% of respondents believe their IAM stacks fall short in many areas, according to Ory’s analysis of EMA survey results.
• AI systems with least-privileged access had a 17% incident rate versus 76% for over-privileged systems, according to Teleport’s 2026 Infrastructure Identity Survey.

👉 Read Ory's analysis of agent IAM and AI identity risk in finance

Context

Agent IAM in the financial sector is the governance problem created when AI systems need access to data, tools, and workflows that were originally designed for people or static service accounts. In practice, that means identity teams have to decide whether an AI system is acting as an NHI, an autonomous actor, or a governed extension of a human workflow.

EMA’s survey suggests the sector is still early in that shift. The article points to a market where adoption pressure is real, but policy maturity, IAM coverage, and compliance readiness are not keeping pace with the operational use cases being considered.

For identity programmes, the key question is not whether AI will be deployed. It is whether existing IAM, governance, and audit controls can describe, approve, and evidence what the AI is allowed to do before regulators or risk teams ask for proof.

Key questions

Q: How should financial institutions govern agent IAM before production rollout?

A: Start by treating the AI as a distinct identity subject with its own owner, approval path, and scope limits. Require documented business purpose, defined data boundaries, logging, and recertification before production. If the organisation cannot evidence who approved the access and what the AI can do, the rollout is premature.

Q: Why do traditional IAM controls struggle with autonomous AI agents?

A: Traditional IAM assumes predictable users or static machine accounts, but AI agents can act independently, interact with multiple systems, and generate new access needs over time. That makes static role assignment and one-time approval insufficient. Security teams need continuous evaluation, not just initial authentication and authorization.

Q: What breaks when AI policies do not exist in regulated environments?

A: Without AI policies, the organisation cannot show who authorised use, what constraints applied, or how exceptions were managed. In regulated environments, that creates audit gaps, unclear accountability, and inconsistent access decisions. The result is a governance failure even when the underlying technology seems to function.

Q: Who should own accountability for AI data access risk?

A: Accountability should sit with the teams that own identity, data governance, and security operations together. If AI can access enterprise data, then ownership must cover entitlement design, monitoring, and incident response across the full workflow. The governance gap is not just technical, because without a named owner, no one can prove who approved or contained the access.

Technical breakdown

Why agent IAM breaks traditional access models

Agent IAM becomes difficult when an AI system needs runtime access to multiple tools, datasets, and actions that do not fit neatly into a human-centric login flow. Traditional IAM assumes a stable principal, known intent, and reviewable entitlements. Agentic behaviour makes those assumptions weaker because access may need to be scoped to a task, a session, or a decision path rather than a person or a long-lived service account.

Practical implication: identity teams need to map AI access to explicit business tasks and evidenceable scopes, not to vague platform permissions.

Compliance gaps in financial-sector AI governance

Financial institutions operate under stronger expectations for accountability, traceability, and access control than most sectors. When AI policies are absent, the problem is not just policy documentation. It is the inability to prove who approved the AI use case, what data it touched, what actions it could take, and how exceptions were handled across the identity lifecycle.

Practical implication: compliance teams should require AI-specific control evidence for approvals, logging, review, and offboarding before production use.

Where IAM stacks fall short for agentic AI

A conventional IAM stack often handles authentication and coarse authorisation well, but agentic AI introduces a second problem: delegated action. The system may authenticate successfully and still act outside the intended governance boundary if tool access, token scope, or runtime approvals are not aligned. That is why agent IAM is not just about login security; it is about governing execution authority.

Practical implication: architecture reviews should test whether the IAM stack can constrain tool use, token scope, and decision authority separately.

Threat narrative

Attacker objective: The objective is to exploit weak AI governance and identity controls to gain unaudited access, overstep authorised actions, or create compliance failure.

1. Entry occurs when an AI system is granted access to tools or datasets through existing identity mechanisms that were not designed for agentic runtime decisions.
2. Escalation follows when the system can combine those permissions across workflows, creating action scope that exceeds the original approval boundary.
3. Impact appears when the organisation cannot explain, evidence, or constrain what the AI was authorised to do, creating compliance exposure and potential data misuse.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI policy absence is now an identity governance failure, not a side issue. When 79% of organisations still lack AI policies, the gap is no longer about drafting statements of intent. It is about the inability to define who can authorise AI access, what the AI may touch, and which reviews apply when the actor is neither a person nor a static workload. Financial-sector IAM programmes should treat AI policy as part of identity governance, not as a separate AI document.

Agent IAM exposes the limits of human-centred IAM assumptions. Traditional IAM was built around user accounts, role assignment, and review cycles that assume stable identity behaviour. Agentic AI introduces runtime decision-making that can change which tools are used and when actions are taken, which means the control point shifts from login to execution authority. The discipline now has to govern delegated action, not just authenticated access.

Identity governance for AI must be evidentiary, not aspirational. The most persistent failure mode in financial services is not that teams say they care about AI risk, but that they cannot prove the control chain end to end. That is a lifecycle problem across approval, entitlements, monitoring, recertification, and offboarding. If the evidence does not exist at each stage, the control does not exist in practice.

Ephemeral AI access becomes a governance concept, not just a security pattern. The useful concept here is access scope compression: reducing the AI’s authority to the smallest verifiable window that satisfies the task. This matters because the same identity stack may be used for humans, service accounts, and AI systems, but only the AI layer may need explicit runtime guardrails around tools, data, and session length. Practitioners should design for evidenceable boundaries, not broad trust.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI, which shows the governance gap is already broader than policy alone.
• OWASP Agentic AI Top 10 is the right forward step if you need a control vocabulary for runtime AI risk, tool misuse, and identity abuse.

What this signals

Access scope compression: financial institutions should narrow AI authority to the smallest verifiable task boundary that satisfies the use case. That shift becomes more urgent as platform teams inherit AI decision-making power and legacy IAM review cycles prove too slow for runtime governance.

The next governance failure will not be a lack of interest in AI. It will be organisations proving they can authenticate the model but not evidence the actions it is allowed to take, which is where audit, compliance, and identity ownership converge.

Teams that already manage NHI sprawl should treat AI systems as the next control expansion point, with the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs providing the governance baseline and the NIST AI Risk Management Framework providing the AI-specific risk lens.

For practitioners

• Classify AI systems by actor type before production approval Decide whether each AI use case is governed as NHI, autonomous, or human-adjacent workflow, then assign identity ownership, review cadence, and approval authority accordingly.
• Require AI-specific policy evidence before expansion Do not move from pilot to production until the organisation can show an approved AI policy, a named owner, logging requirements, and exception handling for the relevant access paths.
• Separate authentication from delegated action control Test whether successful authentication still allows the AI to overreach through tool access, token scope, or workflow chaining. If so, add execution controls beyond sign-in and role assignment.
• Embed lifecycle review into AI governance Tie recertification, change approval, and offboarding to the AI’s actual access scope so that dormant or abandoned AI permissions do not persist after model, workflow, or vendor changes.

Key takeaways

• Agent IAM in finance is primarily a governance problem because existing identity stacks were not built to prove runtime AI accountability.
• The survey findings show a large policy and readiness gap, which means production AI risk is already outpacing many organisations' control maturity.
• Practical response starts with identity classification, delegated-action controls, and lifecycle evidence rather than with broader AI experimentation.

Key terms

• Access-Centric IAM: Access-centric IAM treats access as a lifecycle process rather than a static entitlement. It links issuance, renewal, usage, and removal so security teams can govern human and non-human identities with the same operating logic across hybrid environments.
• Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.
• Access Scope Compression: Access scope compression is the practice of shrinking an identity’s usable authority to the smallest verifiable window needed for the task. For AI systems, it reduces the chance that broad, persistent access becomes an unreviewed control gap across tools, data, and sessions.
• AI Policy Evidence: AI policy evidence is the documented record that an organisation has defined ownership, approval, control boundaries, and exception handling for AI use. In regulated environments, policy without evidence is not enough because auditors and risk teams need proof that governance was operating, not just intended.

What's in the full report

Ory's full analysis covers the operational detail this post intentionally leaves for the source:

• Survey methodology and respondent breakdown for financial-sector IAM and AI readiness
• Additional breakdown of where IAM stacks are failing across compliance, access control, and governance
• Practical discussion of how agent IAM affects regulated deployment decisions
• The article's full framing of AI policy maturity versus production readiness

👉 Ory's full article covers the survey detail, compliance context, and IAM gaps behind the headline findings.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.