Six-stage AI governance for financial institutions using autonomous agents

At a glance

What this is: This is a six-stage AI governance framework for financial institutions, and its central finding is that written policy alone cannot govern AI already in use across employee workflows, regulated decisions, and autonomous actions.

Why it matters: It matters because IAM, data governance, and AI security teams need a staged control model that distinguishes simple assistance from systems that can see sensitive data, act in other systems, and create regulated business outcomes.

By the numbers:

• 59% of institutions were already reporting productivity improvements from AI, according to Lloyds as cited by Lumia Security.

Context

Financial institutions are already living with AI before they have finished defining AI strategy, which makes governance a control problem rather than a planning exercise. Employees are using public tools, embedded vendor features, and autonomous systems in workflows that touch customer data, financial decisions, and regulated records.

The governance gap is not just visibility into applications. It is visibility into what data enters prompts, which accounts are used, what agents can touch, and how far a system is allowed to go before AI governance becomes a matter of operational control rather than policy language.

Key questions

Q: What breaks when AI systems are used without a governance tiering model?

A: When AI use is not tiered, low-risk experimentation and high-risk decision support get treated the same way, which slows the right work while leaving the wrong work under-controlled. A tiering model separates productivity use from regulated or customer-impacting use, so review, logging, and human oversight match the actual business exposure instead of applying a single blanket process.

Q: Why do AI agents create different financial risk than conventional AI tools?

A: AI agents can trigger actions across systems, so a bad decision can become a transaction, access change, or data movement event at machine speed. That means the cost of failure expands from inference quality to operational blast radius. Organisations need runtime controls, attribution, and policy enforcement, not just model oversight.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: How should organisations use AI in IAM without weakening governance?

A: Use AI for pattern detection, summarisation, and query generation, but keep access approval, role creation, and policy enforcement under human accountability. AI should accelerate evidence gathering, not replace the judgement needed to decide whether access is appropriate. If the input data is poor, treat the model output as advisory only.

Technical breakdown

How AI governance stages map to operational risk

A staged governance model works because not every AI use creates the same exposure. Low-risk use cases consume public information for productivity, while higher-risk cases reach into regulated decisions or financial activity. The key mechanism is progression: discovery of actual use, impact classification, policy definition, role assignment, runtime enforcement, and continuous monitoring. Each stage adds a stronger control boundary because the system’s authority, not just its model quality, determines the risk. This is especially important when the same platform can behave like a chatbot in one context and an acting system in another. See the AI Risk Assessment Guide.

Practical implication: Map each AI use case to a governance stage before it reaches production, and escalate controls as the system gains access to sensitive data or business actions.

Why AI agent authority must be defined before model selection

A model’s capabilities matter less than the role the institution allows it to play. Inform means the system retrieves or summarizes information. Recommend means it proposes a decision but a human approves it. Prepare means it drafts an action for review. Execute means it acts in another system. That progression matters because authority changes the control set, the audit burden, and the accountability model. An assistant that drafts a response is not the same as an agent that can send it or update a CRM record. Governance fails when teams treat all AI as interchangeable content generation. See the AI Agent Authorisation Guide.

Practical implication: Define whether each AI use case may inform, recommend, prepare, or execute before connecting it to systems that hold customer or financial authority.

Runtime controls and audit trails are the real enforcement layer

Pre-deployment review cannot anticipate every prompt, output, or agent decision, so governance has to continue at runtime. The important control pattern is conditional action enforcement: transaction thresholds, approved-tool restrictions, dual approval, separation of duties, and reversibility for high-risk actions. The audit trail is equally important because it records what data the AI touched, what it did, and whether a human approved the result. In regulated environments, that record is not a convenience feature. It is the evidence needed to explain decisions, reconstruct incidents, and prove that authority stayed bounded.

Practical implication: Treat runtime policy enforcement and immutable audit logging as mandatory controls, not monitoring extras, for any AI system that can touch regulated workflows.

Threat narrative

Attacker objective: The practical attacker objective in this threat pattern is unauthorized access to sensitive information or business action through uncontrolled AI use, not necessarily exploitation of the model itself.

1. Entry occurs when employees use public chatbots, personal accounts, or embedded vendor AI features outside procurement and security review, creating ungoverned data flows into AI systems.
2. Credential and access exposure follow when those tools operate under the wrong account or inherit existing application permissions, letting AI reach internal systems without explicit authority design.
3. Impact emerges when an AI system drafts, recommends, or executes regulated actions without the institution being able to prove what data it touched or who approved the outcome.

NHI Mgmt Group analysis

AI governance for financial institutions now starts with actual use, not policy design. Written rules do not stop employees, vendors, or embedded product features from moving sensitive data into AI workflows before governance catches up. The governance problem is therefore discovery and classification first, not committee structure first. Institutions that reverse that order will keep discovering risk after the system is already in production. The practical conclusion is that visibility into real usage is the foundation of every later control.

Agent authority is the defining control boundary, not model sophistication. A system that only summarizes information belongs in a different governance tier from one that can prepare or execute a payment, update a record, or generate a filing. That distinction is central to AI agent authorisation because the same model can create very different risk depending on what it is allowed to do. Institutions should govern the role, not just the tool name.

Financial institutions need a continuous policy boundary, not a one-time approval workflow. AI systems change through model updates, new connectors, altered prompts, and vendor-side changes that can expand scope without a visible product change. That means governance debt accumulates when review is point-in-time instead of continuous. The field should treat change detection, reclassification, and runtime logging as core governance mechanics, not afterthoughts.

AI governance is becoming an access-control discipline as much as a risk-governance discipline. Once AI can act inside CRM systems, payment workflows, or account platforms, the real question is who or what is authorised to do what on whose behalf. That puts identity, privilege, and separation of duties at the center of AI governance programmes. The practitioner takeaway is to align AI governance with enterprise identity controls, not to run it as a separate policy island.

From our research library:

• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

AI governance debt: the longer institutions let shadow AI and embedded AI features spread before classification, the harder it becomes to align authority, logging, and human review to actual risk. That is why continuous discovery matters as much as policy design, especially when tools can arrive through ordinary product updates.

The stronger control model is to attach governance to the way AI behaves in production, not to the label on the application. When a system can prepare or execute actions, the institution needs identity-aware controls, approval boundaries, and audit evidence that can stand up in a regulatory review.

Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. That gap suggests most programmes still understand the risk before they have operationalised the control model.

For practitioners

• Define AI use-case tiers before deployment Classify every AI workflow as low, moderate, or high impact based on data sensitivity, customer impact, financial exposure, and reversibility. Use that tier to determine review depth, logging, and human oversight.
• Inventory actual AI usage across accounts and tools Discover public chatbots, embedded AI features, personal-account use, connected agents, and subprocessors that are already handling institutional data. Treat visibility as a recurring control, not a one-time survey.
• Restrict agent authority by role and action Separate inform, recommend, prepare, and execute permissions so agents can support work without inheriting authority to approve or submit regulated actions.
• Enforce runtime controls on high-risk actions Use thresholds, dual approval, separation of duties, and blocking rules for payment, account, and customer-impacting actions. Block any action that exceeds the role assigned to the AI system.
• Monitor audit trails for scope drift Review logs for unusual access patterns, actions without corresponding approval, unexpected accounts, and changes in output quality or override rates. Reclassify the use case if behavior expands beyond the original approval.

Key takeaways

• The core governance failure is not AI adoption itself but uncontrolled access to data, systems, and decisions before the institution has defined boundaries.
• The article’s staged model ties stronger controls to higher-risk AI behaviour, especially where agents can move from summarising information to executing actions.
• Financial institutions should treat discovery, classification, runtime enforcement, and audit logging as one continuous governance chain rather than isolated tasks.

Related NHI Mgmt Group resources: AI Governance Guide · AI Risk Assessment Guide · AI Agent Authorisation Guide · AI Security Maturity Model

Key terms

• AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• Agent Authority: The permission an AI agent receives to act on behalf of a verified person. In this model, authority is inherited rather than original, so governance must trace the agent back to the human intent, device context, and current trust state that authorised it.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, helps practitioners connect identity governance, machine identity security, and agentic AI control into one operating model. It is useful for teams that need to turn policy intent into enforceable identity and access decisions across modern environments.