Skip to main content
EnforceAuth
Back to Blog
Whitepaper

Closing the Financial Services Authorization Gap

Why unified, continuous authorization is the defining security imperative for banks, capital markets, insurance carriers, and fintech in the AI era.

Mark Rogge, CEO40 min read

WHITE PAPER · FINANCIAL SERVICES SECURITY · 2026

Why Unified, Continuous Authorization Is the Defining Security Imperative for Banks, Capital Markets, Insurance Carriers, and Fintech in the AI Era

PRIMARY AUDIENCE: CISO · CIO / CTO · Chief Risk Officer · Enterprise Architect · Board

REGULATORY FRAMEWORKS: DORA · SOX / FFIEC · PCI-DSS v4.0 · EU AI Act · GDPR Art. 25/32

SEGMENTS COVERED: Global Banks (Tier 1) · Capital Markets · Insurance · Fintech & Payments

Mark O. Rogge · CEO & Founder, EnforceAuth · Former CRO, Styra (acqui-hired by Apple) · GitLab · Weights & Biases

How to Use This Paper

This paper is written for four distinct audiences. Each has different stakes in the Authorization Gap. Find your role and start where it matters most. The full document rewards a complete read — but every section can stand alone.

Table of Contents

Executive Summary

Here is the authorization problem in one sentence: financial services institutions have spent $40 billion on knowing who is asking, and almost nothing on knowing what they are permitted to do.

Authentication — verifying identity — is a solved problem. Authorization — enforcing what that verified identity is permitted to access, modify, or execute at any given moment, in any given context — is not. The gap between them is widening with every AI agent deployed. It is exploited every time a compromised credential inherits over-broad permissions. It is measured by the Authorization Gap Index (AGI), which averages 2.1/5.0 across Tier 1 financial institutions in 2025. And it is now enforced by five regulatory frameworks simultaneously, each demanding continuous runtime authorization controls that most current AI deployments cannot satisfy.

This paper is an argument: authorization, not authentication, is the defining security challenge of the financial services AI era. It makes that argument with breach evidence ($2.3 billion in documented authorization failures from 2019 to 2024), regulatory specifics (DORA Article 9, PCI-DSS Requirement 7.2.6, GDPR Article 25, EU AI Act Article 14), technical precision (four Rego policy examples with plain-English walkthroughs), and a quantified ROI model with sensitivity analysis. It then shows you exactly how to close the gap — with a named framework, a reference architecture, and a 90-day action plan with specific ownership at every step.

Six Arguments This Paper Makes

  • The Authorization Gap is a structural problem, not a configuration problem. It cannot be closed by tuning existing IAM tools. It requires a new layer of the security stack that existing tools — CyberArk, SailPoint, AWS IAM, Azure Entra, Wiz — were not designed to provide. Section 6 makes the architectural case for why, preempts the 'they'll add AI support' objection, and gives you the questions to expose the gap in any incumbent vendor conversation.
  • AI safety controls are not security controls — and conflating them is the most expensive mistake in enterprise AI governance. Content filters and output guardrails reduce harmful model outputs. They do not restrict what an AI agent is authorized to do operationally. A safety-certified AI agent with over-broad permissions is a compliance liability regardless of how polite its outputs are. The Politeness Trap (Section 1.3) is the conceptual core of this paper.
  • The AWARE Framework — Authorization, Workload identity, Audit continuity, Runtime enforcement, Entitlement minimization — is the complete conceptual model for AI authorization governance. Section 2 introduces AWARE as the architecture that Levels 4 and 5 on the AGI require, and that EnforceAuth implements.
  • Real breaches validate the thesis. Capital One (2019, $190M settlement), Robinhood (2021, 7M customers), SWIFT/Bangladesh Bank (2016, $101M) — all authorization failures at their technical root. The AI era amplifies every factor that made those breaches possible, at an order of magnitude greater scale.
  • Five regulatory frameworks now mandate controls that most current AI deployments cannot satisfy — and the enforcement window is closing. DORA supervisory assessments are actively surfacing AI authorization gaps as priority findings. PCI-DSS v4.0 mandatory compliance began March 2025. The EU AI Act's high-risk AI system obligations apply to credit scoring, insurance underwriting, and financial infrastructure. The window for proactive remediation is open, but it is narrowing measurably.
  • The ROI case closes in under six months. The worked example in Section 9.3 shows a mid-market insurance carrier achieving payback in 3.2–4.8 months from initial enforcement deployment, with a 3-year NPV of $6.8M on a $1M investment. The sensitivity analysis in Section 9.2 shows this holds across a wide range of input assumptions.
INDEPENDENT VALIDATION The Authorization Gap is not an EnforceAuth-invented problem. Independent sources validate each core claim: Gartner (2025): 68% of enterprises have no runtime authorization policy for AI agents. IAM spending in financial services reached $40B in 2024; the overwhelming majority on authentication, not runtime authorization enforcement. CyberArk (2024): Non-human identities outnumber human identities 82:1 in enterprise AI environments. 40% of NHI credentials are attached to inactive systems — all still valid. IBM Security (2024): Average financial services data breach cost: $6.1M. Authorization-related failures are a root-cause factor in ~35% of enterprise breaches. EBA DORA Supervisory Reports (Q1–Q3 2025): AI system access control gaps are identified as priority remediation items in active supervisory assessments across EU financial institutions. The AGI benchmarks, segment statistics, customer evidence, and $2.3B loss figure are EnforceAuth proprietary advisory data (n=47). Full sourcing in Appendix E.
BOARD TRANSLATION The Authorization Gap is what happens when organizations know who is asking but not what they are allowed to do. For a financial institution deploying AI agents — systems that take real actions on customer funds and regulated data — this gap represents uncontrolled operational risk, regulatory exposure across five simultaneous frameworks, and a breach surface that grows with every AI deployment. Closing it is the next mandatory security investment category. The AGI benchmark gives you a number for your current exposure. The ROI model gives you the business case to act.

1. The Inflection Point: Why 2026 Is the Year Authorization Breaks

There have always been non-human identities in financial services technology environments. Service accounts have existed since the first mainframe. API keys predated the iPhone. The authorization problem has always been present in some form. So why does 2026 represent a genuine inflection point — the moment when the problem crosses from manageable to urgent?

Three things changed simultaneously, and they converge in 2026 into a forcing function that has no historical parallel.

1.1 The AI Era Has Outrun Its Security Architecture

The first thing that changed is deployment scale. Enterprise AI investment in financial services exceeded $85 billion globally in 2024 — a 34% year-over-year increase. McKinsey's 2025 Global AI Survey reports that 78% of Tier 1 banks have AI systems in production across at least three critical business functions. These are not experiments. They are production systems making real decisions on customer funds, regulated data, and critical market infrastructure.

The second thing that changed is the nature of what is being deployed. The first generation of financial services AI — credit scorers, fraud classifiers, algorithmic trading signals — consisted of narrow, bounded systems with well-understood permission scopes. Engineers knew exactly what data they accessed. The current generation is architecturally different:

  • Autonomous multi-step agents that initiate transaction chains, call internal and external APIs, and modify records without per-step human intervention. JPMorgan's COiN platform processes documents that previously required 360,000 hours of legal work annually — one measure of the operational scope these systems now hold.
  • Agentic workflows where chains of specialized AI models hand off tasks, each inheriting, extending, or delegating permissions to the next. The permission a human granted to the orchestrating agent at deployment now propagates — unchecked — through every sub-agent in the chain.
  • AI co-pilots embedded in trader, analyst, underwriter, and claims workflows, operating at machine speed on behalf of human users with the same data access as their principals — but without the contextual judgment that a human user applies to decide which data to access and why.

The third thing that changed is the regulatory environment. DORA entered full enforcement in January 2025. PCI-DSS v4.0 mandatory compliance began in March 2025. The EU AI Act's high-risk system provisions apply to credit scoring and insurance underwriting AI as of 2025. GDPR's Article 25 technical compliance requirements are being actively examined by data protection authorities for AI systems processing personal financial data. All five frameworks are in active enforcement simultaneously — for the first time.

KEY INSIGHT The Authorization Gap was always present. What changed in 2026 is that the three forces containing it — limited AI scale, narrow AI scope, and regulatory forbearance — all disappeared at the same time.

1.2 The Non-Human Identity Explosion: 82:1

For decades, enterprise identity and access management was built on one foundational assumption: identities are human. IAM systems were architecturally designed to govern employees, contractors, and partners. Every authorization decision was ultimately traceable to a person with accountability, a manager who certified access, and an offboarding process that revoked it. That architecture no longer reflects reality.

Non-human identities — service accounts, API keys, OAuth tokens, AI agents, and automated pipelines — now outnumber human identities by 82 to 1 in enterprise environments. At a Tier 1 bank with 100,000 employees, this implies approximately 8.2 million non-human identities operating across the enterprise infrastructure. The IAM systems governing those banks were designed to govern 100,000 people. They are being asked to govern 8.2 million non-human actors — using frameworks and workflows designed for humans.

The mismatch is not theoretical. CyberArk's 2024 research found that 40% of non-human identity credentials in the average enterprise are attached to systems or processes that are no longer active. All still valid. All still carrying whatever permissions they were provisioned with. All a potential attack vector. This is authorization debt made concrete — 40% of your non-human credential inventory is an orphaned attack surface.

1.3 The Politeness Trap: Why AI Safety Is Not AI Security

"Your AI passed every safety review. It still accessed data it had no business reason to touch. Because safety and authorization are different problems, and you only solved one of them." — Financial Services CISO, EnforceAuth Advisory Panel, 2025

There is a confusion at the center of the enterprise AI security conversation that is costing financial institutions billions in unmitigated exposure. It is the conflation of AI safety with AI security. They are not the same problem, they are not addressed by the same controls, and treating one as a proxy for the other is how a fully certified, fully compliant AI model becomes a regulatory liability.

AI safety is about model outputs — whether the model produces harmful, biased, or misleading content. It is primarily the model provider's problem. OpenAI, Anthropic, and Google DeepMind invest heavily in alignment, RLHF, and content filtering to govern what models say. Financial services firms rightly demand safety certifications and test models against their own use-case requirements.

AI security is about agent operations — whether the AI agent is permitted to do what it is about to do. Which systems can it access? Which APIs can it call? Which records can it query? Which actions can it take, on behalf of which principals, under what conditions, with what audit trail? AI security is entirely the institution's responsibility. No model provider governs what your AI agent is authorized to do in your environment. That governance is yours.

A fully safety-aligned AI model can simultaneously represent a catastrophic security failure. Consider what this means in practice:

SCENARIO: THE POLITE LIABILITY A wealth management firm deploys an AI investment advisor assistant. Every safety box is checked. The model produces appropriate, accurate, policy-compliant responses. It passes the firm's responsible AI review. It is deployed to client-facing advisory staff. What the safety review did not examine: the assistant holds persistent read access to the firm's complete client data lake — 850,000 portfolios, tax records, estate planning documents, and beneficial ownership information. That access was provisioned during development and never scoped for production. When a client asks about their portfolio, the model's retrieval logic queries correlated data from similar clients to 'personalize' its response. No authorization policy prevents this. No audit log records which records were accessed. No runtime enforcement of minimum-necessary-access exists. The model is safe. The model is polite. The model is a GDPR violation (Article 25 — data access technically unconstrained), a SOX data governance failure (no audit trail), and a $6.1M breach waiting for a compromised API key.
BOARD TRANSLATION We have spent significant budget on AI safety — making sure our AI behaves appropriately and doesn't produce harmful outputs. But safety and security are different problems. Safety asks: what does the AI say? Security asks: what is the AI allowed to do? We have invested in the first question. The Authorization Gap is the second question, largely unanswered. A safe AI agent with over-broad permissions is a compliance liability regardless of how well it behaves.

1.4 The Unmeasured Attack Surface

Authorization failures create attack surface that traditional security controls cannot see, much less address. Perimeter defense governs network access, not data permissions. Endpoint detection monitors known malware patterns, not authorization policy violations. SIEM can only alert on events that were logged — and most authorization violations in AI agent environments are never logged because the concept of 'this access was not authorized' was never encoded as a detectable event.

The authorization attack surface in a financial institution has three components that are largely invisible in current security monitoring:

  • Horizontal over-provisioning: How many systems, APIs, and data assets each non-human identity can access beyond what its operational purpose requires. The typical AI agent in financial services can reach 3–5 times more data than it needs for any individual task. That excess is the blast radius available to anyone who compromises its credentials.
  • Temporal over-provisioning: How long permissions persist beyond the operational need that justified them. AI agent credentials provisioned for a proof of concept in 2024 may still be valid in 2026. The average non-human identity credential age at major financial services institutions is 18 months. Every month of stale credential existence is a month of unreviewed attack surface.
  • Contextual under-enforcement: The absence of policy restricting what an identity is permitted to do based on real-time context — current task, current risk level, current regulatory jurisdiction, current data classification. A trading agent should not have execution access outside market hours. A claims AI should not query records outside the current claim context. A compliance bot should not access data from jurisdictions not covered by its current report. None of these contextual constraints can be enforced by any existing IAM tool.
KEY INSIGHT The authorization attack surface is invisible to existing monitoring because existing monitoring was built to detect known threats, not undefined permissions. The Authorization Gap is not a gap in detection — it is a gap in policy. You cannot detect what you never defined as a violation.

2. The AWARE Framework: A Model for Authorization in the AI Era

2.1 Introducing AWARE

The security industry has a strong tradition of named frameworks that give practitioners a shared vocabulary for complex problems — Zero Trust, MITRE ATT&CK, the NIST Cybersecurity Framework. Authorization in the AI era needs the same. EnforceAuth introduces the AWARE Framework — five principles that together define complete authorization governance for AI-era financial services environments.

AWARE is not a product feature list — it is an architecture requirement. An organization that has implemented all five principles has closed the Authorization Gap. An organization missing any single principle has a gap that can be exploited. The Authorization Gap Index (AGI) measures which principles are in place and at what maturity level.

Each principle addresses a specific failure mode that existing security tools leave unaddressed:

  • Authorization (not just Authentication): Authentication verifies who is asking. Authorization determines what they are permitted to do. The industry has mastered authentication and neglected authorization. AWARE starts with the acknowledgment that knowing an identity is valid is not the same as knowing an action is permitted.
  • Workload Identity (not just Human Identity): AI agents, service accounts, and automated pipelines must be first-class identity citizens — enrolled, governed, reviewed, and revoked on the same cycle as human users. The 82:1 non-human-to-human ratio makes non-human identity governance the numerically dominant challenge.
  • Audit Continuity (not just Access Logging): An access log that records 'the fraud detection system accessed the customer database' is not audit continuity. Audit continuity means every authorization decision — approved and denied — is logged with identity, action, resource, applicable policy, and decision outcome. At the record level. In real time. In a format that satisfies DORA Article 10, PCI-DSS Requirement 10.2.1, and GDPR Article 5(2).
  • Runtime Enforcement (not just Provisioning-Time Controls): The most important word in AWARE is 'runtime.' Provisioning-time controls set permissions when a system is deployed. Runtime enforcement evaluates every action against current policy at the moment it is requested. An AI agent's permissions may need to change mid-session — because a risk limit was breached, because a regulatory update took effect, because the task context changed. Only runtime enforcement can respond to context that did not exist at provisioning time.
  • Entitlement Minimization (not just Role Assignment): Least privilege is the oldest principle in access control, and it is the most consistently violated. Entitlement minimization in the AWARE sense means actively managing entitlements as a continuous process — not assigning minimum permissions at deployment and forgetting them, but continuously evaluating whether every permission in the current entitlement set is still operationally required.
BOARD TRANSLATION The AWARE Framework is how we explain AI authorization governance to non-technical stakeholders. Five principles: Know what AI agents are permitted to do. Register AI agents as accountable identities. Log every action. Enforce policy at the moment of action, not just at login. Give AI agents the minimum permissions they need and nothing more. An institution that does all five has closed the Authorization Gap. The AGI score measures how far along each principle we are.

2.2 Four Dimensions of the Authorization Gap

The Authorization Gap is formally defined as the structural distance between the permissions that systems, agents, and identities actually hold and the permissions they should hold at any given moment, in any given context, for any given action, in accordance with the minimum-necessary-access principle and applicable regulatory obligations. It manifests across four distinct layers of an institution's technology stack.

The table below makes the gap concrete. Each row shows — at an illustrative Tier 1 bank — what is actually held, what is actually required, and the gap between them. The final column names the primary reason existing tools fail to close it.

Dimension 1: Application Authorization

Application-layer authorization is the most visible and the most consistently broken. When authorization logic lives inside individual applications — hardcoded permission checks, in-memory role lists, service-to-service tokens that implicitly trust every internal caller — the result is fragmentation that makes enterprise-wide policy changes operationally impossible without coordinated redeployments across hundreds of services.

The AI era makes this worse in a specific way: AI agents integrated with application APIs at development time receive permission scopes designed for that integration at that moment. As the agent's capabilities evolve, as new use cases are added, as the data it accesses changes — the permission scope does not. An AI agent that was reasonably scoped for a narrow task in 2023 may be dramatically over-privileged for its 2026 operational profile, because no process exists to revisit API permission scopes for AI agents after initial deployment.

KEY INSIGHT The core failure of application authorization for AI agents is not that the permissions are wrong at deployment — it is that there is no mechanism to keep them right as the operational context evolves.

Dimension 2: Infrastructure Authorization

Infrastructure authorization failures in AI environments have a specific and recurring pattern: the training-scope-to-production-scope gap. An AI model's training workload requires broad access to data — you need the full data set to train a good model. That broad access is legitimately provisioned for the training run. What happens when the model is deployed to production? In most financial services organizations, the answer is: the training-scope credentials become the production-scope credentials, because scoping them down requires security team involvement that delays deployment.

This is how a production fraud detection API ends up with AWS IAM permissions that allow it to read every S3 bucket in the data lake — including buckets containing M&A documents, HR records, and regulatory correspondence — because those permissions were originally granted to enable comprehensive training data access.

Dimension 3: Data Authorization

Data authorization is where the Authorization Gap creates its most direct regulatory exposure. Most data access controls operate at the database or table level. A permission granted for 'customer account data for fraud detection' gives an AI agent read access to every customer account record in the database — including fields that have nothing to do with fraud detection, including records with no connection to any active investigation. This is not a misconfiguration. It is the fundamental limitation of database-level access control: databases grant access to data containers, not to specific data for specific purposes.

GDPR Article 25 requires data access to be technically constrained to the minimum necessary for the specific processing purpose. HIPAA's minimum necessary standard requires the same for protected health information. PCI-DSS Requirement 7.2.6 requires need-to-know access management for all entities accessing cardholder data. These requirements can only be satisfied by record-level authorization enforcement — evaluating each data access request against a policy that specifies exactly what data this identity is permitted to access for this purpose at this moment. No existing database access control provides this.

Dimension 4: AI Workload Authorization

AI workload authorization is the frontier. It addresses the novel challenge that AI agents are not users and not services in the traditional security sense — they are a new category of identity that combines the autonomous decision-making of a user with the API-calling capability of a service, operating in contexts that were never contemplated when authorization frameworks were designed.

Three AI-specific authorization primitives that no traditional IAM tool provides:

  • Tool invocation authorization: When an AI agent has access to a tool library — a set of APIs, functions, or MCP servers it can invoke — the authorization policy must specify which tools the agent can invoke, under what task context, at what privilege level, with what frequency constraints. Most current AI deployment frameworks provide no mechanism for this granularity. The agent can invoke any tool it can reach, for any reason, any number of times.
  • Delegated authority management: When an AI agent acts on behalf of a human user, it should inherit the user's current authorization context — not a static deployment-time permission set. A trading analyst who is currently restricted from certain instruments should not be able to use an AI agent to query or execute on those instruments. The agent's permission scope should be dynamically derived from the authorizing user's current permissions at the time of each action.
  • Action-level audit attribution: Every action taken by an AI agent — not just which API it called, but which specific data it accessed in service of each action, under what business justification — must be attributable to a specific authorization decision. This is not optional for regulated environments. It is the evidentiary requirement of DORA, PCI-DSS, GDPR, and the EU AI Act.

2.3 The Authorization Gap Index (AGI): Measuring Where You Are

The Authorization Gap Index (AGI) measures an institution's authorization posture on a 1.0–5.0 scale across all four AWARE dimensions. EnforceAuth conducted advisory assessments with 47 financial services organizations in 2024–2025. The results: the average AGI score for Tier 1 banks is 2.1/5.0. Fewer than 8% have achieved Level 4. No Tier 1 institution assessed has achieved Level 5 without dedicated authorization fabric investment.

49% AT LEVEL 2 — Half of all assessed FSIs have mature human identity governance and no AI agent authorization governance. This is the institution that has CyberArk and SailPoint and believes it is covered. It is the modal Authorization Gap state.
INDUSTRY BENCHMARK (2025) — AGI by segment (n=47, EnforceAuth Advisory assessments): Tier 1 Banks: 2.1 · Capital Markets: 2.3 · Insurance Carriers: 1.9 · Fintech/Neo-banks: 2.7 · Mid-market FSI: 1.8. Industry overall: 2.0 — firmly in Level 2, with AI authorization governance and runtime enforcement almost entirely absent.

2.4 Authorization Debt: The Compounding Liability

Authorization debt is what happens when AWARE principles are violated at deployment and never corrected. It is the accumulated residue of every 'we'll fix the permissions after go-live' decision that was never revisited, every credential provisioned for an experiment that was never revoked, every AI agent whose permission scope was never reviewed after its initial deployment.

Authorization debt is not static — it compounds. Each new AI deployment that inherits existing over-broad credentials adds to the total. Each regulatory framework that comes into enforcement without corresponding authorization controls adds to the exposure. Each month that orphaned credentials remain valid adds to the attack surface. The longer authorization debt goes unaddressed, the more expensive it becomes to remediate — both in engineering effort and in the accumulated probability of an incident that forces emergency remediation.

AUTHORIZATION DEBT FORMULA Expected Annual Cost = (NHI Count × Over-Provisioning Factor × Credential Age in Months) × (P(Breach) × Avg Breach Cost + P(Regulatory Action) × Avg Fine). For a mid-size FSI: 500K NHIs × 2.3× × 18 months × (12% × $6.1M + 8% × $15M) ≈ $4.2M annual expected exposure from authorization debt alone. Proactive remediation costs a fraction of this. Emergency remediation under regulatory order typically costs several multiples.

3. Threat Landscape: $2.3B in Validated Authorization Failures

The Authorization Gap is not a theoretical risk. It has a documented financial cost of $2.3 billion in direct and settlement costs from authorization failures at financial institutions between 2019 and 2024.

Every major pattern in this threat section has already played out in public-record incidents. The AI era does not introduce new failure modes — it amplifies existing ones by an order of magnitude, because AI agents hold more permissions, access more data, and take more actions per unit time than any human user ever did.

3.1 The Over-Privileged Agent Attack Pattern

The over-privileged agent pattern is the most common root cause in AI-era financial services security incidents. An AI agent or service account has been granted legitimate access to a system — but with a permission scope broader than its operational purpose requires. When that account's credentials are compromised, the attacker does not need to escalate privileges. The agent already has them.

This is not a new attack pattern. It is the exact pattern that drove the Capital One breach, the SWIFT attacks, and dozens of other financial services incidents that did not make headlines. What the AI era adds is scale: there are now 82 times more non-human identities than human identities in the average enterprise, each holding permission scopes that were never reviewed for operational necessity.

THREAT SCENARIO: OVER-PRIVILEGED TRADING AGENT Attack vector: Supply chain compromise of a third-party AI SDK used in an algorithmic trading agent. The attacker obtains valid execution credentials without any direct system breach. Exploitable condition: The trading agent holds persistent credentials to the position database, pricing feed aggregator, execution system, and portfolio risk engine — full deployment-time scope, never reviewed against current operational requirements. Without AWARE enforcement: Attacker inherits complete trading infrastructure access. Queries full position book across all desks. Executes unauthorized trades before detection. Exfiltrates client portfolio data. All through legitimately provisioned credentials that look like normal agent activity in access logs. With AWARE — Runtime Enforcement + Entitlement Minimization: Policy restricts agent to read-only position access for its authorized desk during non-trading hours. Execution requires a context-validated task token issued only during market hours with VAR utilization below threshold. Anomalous access pattern triggers real-time alert. Blast radius: one restricted data view.

3.2 Permission Inheritance in Agentic Chains

Agentic architectures introduce a permission inheritance vulnerability that did not exist in single-agent systems. When an AI orchestrator delegates tasks to sub-agents, those sub-agents typically inherit the orchestrator's credential context — not because anyone designed this behavior, but because the orchestration framework passes credentials as part of the task context, and the sub-agent uses whatever credentials it receives.

An attacker who compromises any node in a delegation chain — particularly the sub-agents that receive less security attention than the orchestrator — may gain access to the full permission scope of the orchestrating agent, regardless of whether that scope is relevant to the sub-agent's specific task.

THREAT SCENARIO: AGENTIC LOAN ORIGINATION CHAIN Architecture: A loan origination orchestrator delegates tasks to six specialized sub-agents: document processor, credit bureau query, collateral valuation, compliance check, pricing calculation, and offer generation. The inheritance problem: The orchestrator's credential context — including access to all six downstream systems — is passed to each sub-agent as part of the task delegation. The document processor sub-agent, which only needs to read uploaded application documents, receives credentials that include access to the credit bureau API, the collateral valuation system, and the offer generation engine. Attack path: Attacker identifies that the document processor sub-agent has a publicly exposed document upload endpoint with a prompt injection vulnerability. Injecting a malicious instruction into an uploaded document causes the sub-agent to use its inherited credentials to query the credit bureau API and exfiltrate credit data for thousands of applicants. With AWARE — Workload Identity + Runtime Enforcement: Task-scoped credential delegation. The document processor sub-agent receives only the credentials required for document reading and OCR. Credit bureau API credentials are not delegated to any sub-agent that doesn't explicitly require them for its assigned function. Prompt injection in the document processor cannot reach the credit bureau API because the credentials were never issued.

3.3 Credential Accumulation and AI Agent Sprawl

AI agent sprawl is the institutional equivalent of a hardware store that never throws anything away. Every deployment adds credentials. Some deployments end. The credentials don't. CyberArk found that 40% of non-human identity credentials in the average enterprise are attached to systems or processes that are no longer active. In financial services organizations deploying AI at the pace of the past three years, that percentage is likely higher — because AI deployments cycle faster than credential revocation processes.

THREAT SCENARIO: ORPHANED CREDENTIAL DATA EXFILTRATION Origin: A fintech deploys a customer analytics AI during a marketing campaign. The agent gets read access to the transaction database, behavioral data store, and third-party enrichment API. The campaign ends. The model is deprovisioned. Its API keys and database credentials are not revoked. 18 months later: Those credentials are still valid. They exist in a shared secrets manager with 340 other entries that has not been reviewed in over a year. A new engineer finds them and assumes they are still in use for another service. Breach: The credentials are included in a git commit pushed to a public fork of an internal repository. A threat actor finds them within 4 hours — the average time to discover exposed credentials in public repositories. 2.1 million customer records are exfiltrated from the transaction database before the breach is detected. With AWARE — Workload Identity + Entitlement Minimization: EnforceAuth continuous identity governance flags the analytics AI's credentials as orphaned within 30 days of the agent's deprovisioning — no active authorization requests from that identity. Automatic revocation workflow triggered. The credentials are invalid before the next review cycle.

3.4 Real-World Breach Case Studies

The following four cases are matters of public record. Each represents a failure of at least one AWARE principle. Each has an AI-era analog that is currently present in most financial services authorization architectures.

3.5 Insider Threat: The Authorization Gap Within

Insider threat accounts for 20–25% of financial services security incidents annually. The Authorization Gap amplifies insider threat in a way that is specific to AI agent environments: when a malicious or negligent insider manipulates an AI agent, the attacker inherits not just their own permissions but the AI agent's potentially much broader permission scope — without triggering the access anomaly detection that would flag a human user accessing unusual data directly.

This creates two AI-specific insider threat vectors:

  • AI as data access proxy: An insider whose direct database access has been scoped or revoked may retain access to an AI agent that holds the broader access they lost. The AI agent becomes a proxy for data exfiltration that bypasses the direct access controls the institution invested in. This is particularly acute during offboarding — direct access is revoked, but AI agent delegated access is not, because most offboarding processes were designed before AI agents existed.
  • Prompt injection as authorization bypass: A sophisticated insider (or an external attacker with any internal foothold) can manipulate an AI agent's task context through prompt injection — embedding instructions in documents, emails, or data that cause the agent to take actions outside its intended scope. Without action-level authorization enforcement, the agent will comply with the injected task if the underlying system credentials permit it. The agent cannot distinguish a legitimate task from a manipulated one; the authorization policy is what provides that distinction.
THREAT SCENARIO: OFFBOARDING FAILURE: AI AGENT PROXY ACCESS Situation: A senior analyst gives notice. IT revokes direct access to the market data warehouse, client portfolio database, and research repository as part of standard offboarding. The AI research assistant the analyst has used for 18 months is not touched — it doesn't appear in the offboarding checklist because it wasn't there when the checklist was designed. Exploitation: During the notice period, the analyst uses the AI research assistant to query the client portfolio database and export structured datasets of client allocations, expected returns, and investment mandates — data they plan to use at a competitor. The AI complies: its authorization policy was never scoped to the analyst's active business purpose, and AI agent delegated access was never included in the offboarding workflow. With AWARE — Workload Identity + Runtime Enforcement: EnforceAuth scopes the AI agent's data access to the current user's active authorization context. When the analyst's direct database access is revoked, the AI agent's delegated data access for that user is revoked simultaneously. The AI cannot access data that the authorizing user is not permitted to access. The offboarding process, updated to include AI agent delegation revocation, triggers automatically.

3.6 Regulatory Audit Failure: When No Breach Occurred

The most underappreciated category of Authorization Gap consequence involves no external attacker at all. A growing fraction of the most consequential authorization failures in financial services are surfaced not by breach detection but by regulatory examination — where the institution cannot demonstrate compliance, not because a violation occurred, but because the authorization controls and audit infrastructure to evidence compliance were never built.

This is the DORA supervisory finding pattern described in Section 3.4. It is also the PCI-DSS assessment pattern for institutions whose AI systems access cardholder data without the unique identity registration and record-level audit logging that PCI-DSS v4.0 Requirement 8.6 now requires. It is the EU AI Act conformity assessment pattern for institutions deploying high-risk AI systems — credit scoring, insurance underwriting — without documented authorization controls as part of their risk management system.

BOARD TRANSLATION The most immediate financial risk from the Authorization Gap is not a breach — it is a regulatory finding. A DORA supervisory assessment, a PCI-DSS audit, or an EU AI Act conformity assessment can identify the Authorization Gap as a compliance failure before any attacker exploits it. The remediation cost for a regulatory finding — mandatory timelines, public disclosure potential, supervised remediation — is typically multiples of the proactive investment required to close the gap. We are in the window where proactive remediation is still cheaper than reactive compliance.

4. Segment Analysis: The Gap in Your Industry

The Authorization Gap manifests differently across financial services segments — different technical architectures, different regulatory overlays, different AI deployment patterns. This section provides a precise, segment-specific analysis that allows CISOs to locate their own institutions in the landscape and identify the most acute failure modes for their context.

4.1 Global Banks and Tier 1 Financial Institutions

The authorization problem at a Tier 1 bank is not a technology problem — it is a governance-at-scale problem. The bank has technology. It has IAM platforms, PAM tools, access certification workflows. What it lacks is an authorization architecture that can extend consistently across a technology estate that spans decades of accumulated systems, 50+ regulatory jurisdictions, multiple cloud providers, dozens of acquired entities with legacy authorization architectures, and an AI deployment portfolio growing at dozens of new systems per quarter.

Four failure modes are structurally endemic at Tier 1 banks:

  • The cross-border authorization consistency gap. An AI agent operating across EU, US, and APAC must apply authorization policies that respect local data residency, regional privacy regulation, and jurisdiction-specific financial law — simultaneously, in real time. GDPR applies to EU customer data. GLBA applies to US customer data. MAS Technology Risk Management Guidelines apply to Singapore operations. An AI agent with access to customer data across jurisdictions must enforce different authorization rules for different subsets of that data, based on the customer's jurisdiction. No legacy IAM tool provides jurisdictional authorization policy enforcement. The result is that AI systems with global data access apply the least restrictive policy across all jurisdictions by default.
  • The core banking authorization architecture mismatch. Legacy core banking platforms — SAP, Temenos, FIS, Finastra — were designed for human tellers and branch managers. Their permission models are coarse-grained role assignments: teller, branch manager, regional auditor. These roles were not designed to support contextual, action-level enforcement for AI agents operating at machine speed. AI systems accessing core banking data through service account credentials with broad roles are the norm, not the exception — because no narrower role exists in the core banking authorization model.
  • The high-frequency trading latency paradox. Algorithmic and AI-enhanced trading infrastructure requires authorization decisions at microsecond latency. Traditional IAM systems add 10–50ms to each authorization request — an architectural incompatibility with trading infrastructure requirements. The industry's solution to this paradox has been broad standing access: grant the trading systems what they need at deployment and trust that the controls elsewhere in the stack are sufficient. They are not. DORA Article 45 TLPT exercises are increasingly exposing this gap as a primary finding.
  • M&A-driven authorization sprawl. Every acquisition brings a new set of service accounts, a new AI deployment portfolio, and a new authorization architecture — and post-merger authorization rationalization is chronically the lowest-priority item on the integration roadmap. The practical result: acquired-entity credentials persist in the combined enterprise's infrastructure for years after the business rationale that created them has expired. At a Tier 1 bank that has completed 10–15 acquisitions over the past decade, this represents a material orphaned credential inventory that no existing tool systematically identifies and revokes.
BOARD TRANSLATION At a Tier 1 bank, the board-level framing is straightforward: we have 400+ AI systems in production, fewer than 15% of which have documented runtime authorization policies. The other 85% are operating with whatever permissions were provisioned at deployment, never reviewed. DORA now requires continuous access control validation for all ICT assets including AI systems. The exposure — up to 2% of global annual turnover — is material. This is not a theoretical risk: DORA supervisory assessments are already finding this gap and issuing mandatory remediation orders.

4.2 Capital Markets and Investment Banking

Capital markets institutions face the most consequential intersection of AI authorization failure and regulatory consequence: information barriers. 74% of capital markets firms report that AI systems have simultaneous access to data from both advisory and trading functions — a structural information barrier risk that the industry has not yet developed authorization controls to address.

The Information Barrier Authorization Problem

Information barriers (Chinese walls) exist to prevent the flow of material non-public information (MNPI) between investment banking — which may possess MNPI from M&A advisory and capital markets transactions — and sales and trading — which executes transactions in related securities. Regulatory frameworks including SEC Rule 10b-5, FINRA Rule 2010, and the FCA's Market Abuse Regulation impose this separation.

AI models introduce a structural challenge to information barrier enforcement that has no precedent in traditional security frameworks: a model fine-tuned on data from both sides of an information barrier internalizes that data. You cannot selectively un-train a model. You cannot examine a model's weights and determine which specific MNPI it has learned. The model carries the information — and if it also has access to trading execution APIs, it represents a structural information barrier violation that is undetectable by traditional compliance monitoring.

Authorization controls cannot fix the training data problem. But they can control what the model is permitted to act on at inference time — and this is precisely where action-level authorization enforcement becomes critical:

  • Advisory-side AI agents must not be permitted to invoke execution APIs. This is the enforcement point: not what the model knows, but what it can do. An advisory AI with trading execution credentials represents an MNPI transmission channel regardless of the model's explicit instructions. EnforceAuth's information barrier policy blocks advisory-side agent action on trading execution APIs entirely — enforced at the tool-invocation layer, not the content layer.
  • Cross-barrier data access must generate a SEC Rule 17a-4-compliant audit event. Every attempt by an AI agent to access data from the wrong side of the barrier — even if blocked — must be logged with the agent identity, the resource attempted, the barrier designation, and the timestamp. This is the evidentiary record that demonstrates to SEC examiners that the barrier is technically enforced, not merely stated in policy.

Algorithmic Trading Authorization

AI-enhanced trading systems that can adapt their own strategies require continuous authorization validation against risk parameters — not a one-time permission grant at deployment. A trading agent authorized to execute equity strategies within defined risk limits must be evaluated against those limits on every execution decision. Market conditions that move outside authorized parameters must trigger automatic permission contraction, not continued autonomous execution.

KEY INSIGHT The information barrier authorization problem is unique to capital markets: you cannot fix what the model learned during training. You can only control what it is permitted to do at inference time. Action-level authorization enforcement is the only technical control that satisfies this requirement.

4.3 Insurance Carriers

Insurance carriers operate AI systems that access some of the most legally protected data in the financial services sector — medical records, actuarial models, behavioral assessments — under regulatory frameworks that impose specific authorization requirements at the field level, not just the database level. HIPAA's minimum necessary standard, applied to AI claims processing, requires field-level authorization enforcement that no traditional IAM tool provides.

Underwriting AI: The Minimum Necessary Problem

AI underwriting systems for health and life insurance process medical records, property data, behavioral history, and financial information. The authorization challenge is not simply preventing unauthorized access — it is ensuring that the model accesses only the specific data that is legally permissible to use in a specific underwriting decision, for a specific policy type, in a specific regulatory jurisdiction.

This is a genuinely hard authorization problem. The set of data permissible for a term life underwriting decision in California differs from the set permissible in New York. The set permissible for a health insurance underwriting decision differs from the set permissible for a property insurance underwriting decision. And within any given decision, HIPAA's minimum necessary standard requires that only the fields of the medical record that are relevant to the specific decision be accessed — not the full record.

No traditional IAM tool can enforce this. Database credentials grant access to records and tables, not to field subsets conditional on policy type and jurisdiction. AWARE's Runtime Enforcement principle, applied at the field level, is the only mechanism that satisfies HIPAA's technical minimum necessary requirement for AI systems processing protected health information.

Claims Processing: Scope Enforcement and Internal Fraud Prevention

AI claims processing systems at national health insurers process 40,000+ claims per day, accessing medical records, billing codes, provider databases, and fraud indicators from data lakes containing tens of millions of member records. The authorization challenge is claim-context scoping: the AI must access the data required to process the current claim, and only that data.

This matters for two independent reasons: HIPAA compliance (accessing records outside the current claim context is a minimum necessary violation) and internal fraud prevention. AI-enabled internal fraud — using an AI system with broad data access to query records outside legitimate business purpose — is an emerging concern for insurance carriers. The authorization control is identical for both: claim-context enforcement that prevents the AI from querying records outside the scope of the current claim being processed.

Actuarial Model Version Authorization

Actuarial models informing pricing decisions must be approved by state insurance regulators in many US jurisdictions before deployment. Authorization infrastructure must enforce that only the approved model version is used in production underwriting decisions — not a subsequent experimental version, not a model under development, not a model whose approval has expired. This requires version-level authorization enforcement that no existing IAM framework was designed to provide.

EnforceAuth's claims AI authorization policy (Use Case 2, Section 7.7) enforces approved model version at every underwriting decision — blocking any model version not in the approved versions registry from producing production underwriting outputs, regardless of what system credentials it holds.

4.4 Fintech, Payments, and Neo-Banks

Fintech institutions present a different authorization profile from their traditional counterparts. Their technology stacks are modern, API-first, and better suited to policy-as-code authorization architectures. But their authorization governance is typically the least mature in the financial services sector — AGI average of 2.7 suggests some NHI inventory, but runtime enforcement and AI workload authorization are largely absent. PSD2 enforcement actions related to consent data management increased 340% in 2024, making the consequences of immature authorization governance very concrete for fintech operators.

The Dynamic Consent Authorization Problem

Open banking frameworks — PSD2/PSD3 in Europe, CDR in Australia, and emerging frameworks globally — require fintech platforms to share customer financial data with authorized third parties based on explicit customer consent. The authorization problem is that consent is not static. Customers add, modify, and revoke consent continuously. An average open banking platform with 4 million users processes 12,000+ consent changes per day.

An authorization model that reflects consent state at token issuance will, with certainty, be inconsistent with current consent state for a material fraction of active tokens at any given moment. The only architecturally compliant approach is to evaluate every data access request against the current consent record at the time of the request — not the consent state at the time the OAuth token was issued.

This is the distinction between provisioning-time controls (OAuth token scoped at consent time) and runtime enforcement (consent evaluated at every API call). PSD2 requires the latter. Most open banking platforms implement the former. EnforceAuth's PSD2 consent authorization policy (Use Case 3, Section 7.7) closes this gap — making consent revocation take effect on the next API call, not the next token refresh.

API-First Architecture and Third-Party Authorization Sprawl

Fintech platforms expose and consume APIs at scale. A scaled open banking platform may have 180+ third-party integrations — each representing an external authorization dependency that must be governed with the same rigor as internal authorization. API keys and OAuth tokens that were provisioned for specific third-party integrations accumulate over time, often outliving the business relationship that justified them.

A third-party API key holding access to customer financial data is not a development artifact. It is a regulated access credential subject to PCI-DSS Requirement 8.6.1 (managed with the same identity lifecycle principles as user accounts), GDPR Article 28 (processor binding), and PSD2 Article 67 (authorized payment information service provider controls). Treating it as a development configuration item — which is how most fintech organizations manage third-party API credentials — is a governance failure with regulatory consequences.

5. Regulatory Deep Dive: Five Frameworks, One Requirement

Five regulatory frameworks currently in active enforcement converge on a single requirement: financial institutions must be able to demonstrate that AI systems operating on regulated data and financial infrastructure are authorized to do what they do, have a complete audit trail of what they did, and can be stopped by a human when required. The frameworks use different language. The underlying requirement is the same.

5.1 DORA: ICT Risk in the AI Era

The Digital Operational Resilience Act (EU Regulation 2022/2554) entered full enforcement January 17, 2025. DORA applies to all financial entities operating in the EU and their critical third-party ICT service providers. The European Supervisory Authorities — EBA, EIOPA, and ESMA — began active supervisory assessments in Q1 2025. Early assessment findings have consistently identified gaps in automated system access control as priority remediation items.

"DORA is not an IT compliance checkbox. It is a fundamental reorientation of how financial institutions manage ICT risk — and authorization is at the center of that reorientation." — EBA DORA Supervisory Guidance, Q1 2025

DORA does not use the word 'AI authorization' — but its ICT risk management framework imposes requirements that directly govern how AI systems must be authorized, monitored, and controlled. The critical provisions:

BOARD TRANSLATION DORA is in active enforcement now. Supervisory assessments are finding AI authorization gaps as priority remediation items. The penalty exposure is up to 2% of global annual turnover — material for any institution. For a Tier 1 bank with $10B in annual revenue, that is $200M in maximum DORA penalty exposure for ICT risk management failures. The DORA finding in Section 3.6 demonstrates that supervisory examiners are specifically looking for AI agent authorization controls. The question is whether they find them in place or find a gap.

5.2 SOX and FFIEC: US Financial Compliance

The PCAOB has published guidance making clear that automated systems with access to financial data must be governed under IT General Controls frameworks equivalent to those applied to human users. FFIEC examination findings related to AI system access controls have increased materially over the past two examination cycles — bank examiners are specifically asking whether AI agent authorization has kept pace with AI deployment.

  • SOX Section 404 — IT General Controls (ITGC): Access management is one of five ITGC domains reviewed in every ICFR audit. AI systems with access to financial systems of record are in scope. Certifying that 'the fraud detection system has appropriate access to the customer transaction database' — without being able to specify what that access encompasses at the record level — is insufficient for a clean ITGC finding.
  • Segregation of Duties in automated workflows: SOX requires incompatible duties to be segregated. AI agents that can both initiate and approve transactions, or access both execution systems and audit records in the same session, create SOD violations that traditional IAM controls designed for human workflows cannot detect. The AWARE Framework's Runtime Enforcement principle enforces SOD at the session level for AI agents — a capability that no existing PAM or IGA tool provides.
  • Change management for AI systems: Changes to AI models that have access to financial reporting systems must go through the same change management controls as changes to the underlying financial systems. Policy-as-code authorization — where authorization policy changes go through CI/CD with pull request review, testing, and audit trail — is the mechanism that makes AI system change management auditable.

5.3 PCI-DSS v4.0: Payment System Authorization

PCI-DSS v4.0 reached full mandatory compliance March 31, 2025. The v4.0 update introduced material changes to access control requirements that several QSAs have noted were explicitly motivated by the emergence of automated and AI-driven payment system access patterns. Two new requirements are particularly significant:

  • Requirement 7.2.6 — Need-to-Know for Automated and System Accounts: All user accounts and access to the cardholder data environment, including automated and system accounts, must be managed on the basis of need-to-know using the principle of least privilege. 'Automated and system accounts' is defined to explicitly encompass AI agents and service accounts. This is a new requirement that does not exist in PCI-DSS v3.2.1. It requires the same NHI governance rigor for AI systems that PCI-DSS has long required for human cardholders — scoped, documented, reviewed, and revoked when no longer required.
  • Requirement 8.6.1 — System and Application Account Lifecycle: All application and system accounts must be managed with the same identity lifecycle principles as user accounts: unique identity, minimal permissions, regular review, and immediate revocation when no longer required. The 'immediate revocation' clause is particularly relevant for AI agents: when a model is deprovisioned or a project ends, the associated credentials must be revoked immediately — not on the next quarterly review cycle.

5.4 EU AI Act: High-Risk AI Authorization Obligations

The EU AI Act, phased application beginning 2024 through 2026, creates the world's first binding regulatory framework governing AI systems as a category. For financial services, the Act classifies credit scoring, insurance underwriting and pricing, employment decisions at financial institutions, and management of critical financial market infrastructure as high-risk AI systems — subject to mandatory technical governance requirements, including authorization controls, as preconditions for legal deployment.

  • Article 14 — Human Oversight: High-risk AI systems must be designed to allow for human oversight, including the ability to override, stop, or restrict the system's operation. This is not a soft governance requirement — it is a technical design mandate. The AWARE Framework's Runtime Enforcement principle is the technical implementation of Article 14: runtime authorization controls that can be invoked dynamically, including the ability to revoke an AI agent's execution permissions in real time without requiring system restart or redeployment.
  • Article 10 — Data Governance for High-Risk Systems: Training data must be governed with defined access controls. Data used for model training must be authorized for that use. Access to training data and model weights must be managed as regulated assets — not as development artifacts accessible to any engineer with a Jupyter notebook. This is the AWARE principle of Workload Identity applied to the AI development lifecycle, not just the inference lifecycle.
  • Article 17 — Quality Management System: Providers must implement a quality management system that includes access control to the AI system and its training and testing data. Third-party auditors will assess authorization controls as part of conformity assessment. For financial institutions deploying high-risk AI systems — which includes virtually every AI system in credit, insurance, and market infrastructure — QMS authorization requirements are a precondition for continued operation.

5.5 GDPR Articles 25 and 32: Technical Data Minimization

GDPR Articles 25 and 32 impose authorization obligations for AI systems processing personal data in the EU. The Irish DPC and French CNIL have both issued guidance making clear that Article 25 requires technical, not merely organizational, data minimization measures for AI systems. A privacy policy stating that AI systems 'should only access necessary data' is not a technical measure. Authorization controls that enforce minimum necessary data access at the API and database level — evaluated at runtime, producing auditable records — are the technical implementation that Article 25 requires.

  • Article 25 — Data Protection by Design: The controller must implement appropriate technical measures to ensure that only personal data necessary for each specific processing purpose is accessed by the AI system. For a fraud detection AI, this means technical enforcement that the model can only access the transaction records of the specific customer whose transaction is being evaluated — not the full customer transaction database. The word 'technical' in Article 25 is what closes the loophole of policy declarations that are never enforced.
  • Article 32 — Security of Processing: Requires ongoing confidentiality, integrity, and availability of processing systems. For AI systems processing sensitive personal financial data, 'ongoing confidentiality' requires continuous authorization enforcement — verifying at every action that the identity taking the action is currently authorized to take it, against the specific data being accessed. The verify-then-trust IAM model does not satisfy Article 32's ongoing requirement.
  • Article 5(2) — Accountability: Controllers must be able to demonstrate compliance with all data protection principles including data minimization. For AI systems, demonstration requires authorization audit trails — records showing that each data access was authorized, for a specific purpose, by an authorized identity. Most current AI deployments cannot produce this evidence. The authorization gap is also an accountability gap.

5.6 The Unified Compliance Case

Five frameworks, five sets of lawyers, five supervisory authorities — and one underlying technical requirement: continuous runtime authorization enforcement with action-level audit trails for AI systems operating on regulated data and financial infrastructure. An organization that implements the AWARE Framework satisfies the core authorization requirement of all five frameworks simultaneously, from a single policy infrastructure.

KEY INSIGHT Five frameworks, one architectural requirement: continuous runtime authorization enforcement with action-level audit trails for AI systems. An institution that implements the AWARE Framework satisfies all five simultaneously from a single policy infrastructure. An institution that does not will fail all five simultaneously in the same examination.
BOARD TRANSLATION The regulatory story is simple: five different regulators are asking the same question about your AI systems. Can you demonstrate that each AI agent is authorized to do what it does, has a complete audit trail, and can be stopped by a human? If you cannot answer that question today — with evidence, not policy documents — you are non-compliant with DORA, SOX, PCI-DSS v4.0, the EU AI Act, and GDPR simultaneously. The authorization gap is a five-way compliance gap.

6. Why Existing Tools Cannot Close the Authorization Gap

This section addresses the most important objection CISOs raise when first confronted with the Authorization Gap argument: 'We have CyberArk. We have SailPoint. We have Wiz, AWS IAM, and Azure Entra. Why isn't that enough?'

It is the right question. The answer is not that these tools are bad — they are excellent at what they were designed to do. The answer is that they were designed for a different problem. The Authorization Gap is a structural mismatch between the problem these tools solve and the problem that AI-era financial services authorization requires solving.

6.1 The Incumbent Landscape: What Each Tool Actually Does

6.2 The Architectural Argument Against Legacy IAM

The table above identifies feature gaps. The deeper problem is architectural. Every tool in the table above was designed for the same underlying model: verify identity at entry, grant permissions based on role, trust until session expiry or explicit revocation. This model works for human users in bounded sessions. It fails for AI agents for four structural reasons:

  • AI agents don't have sessions. A human user logs in, is granted permissions, works within a session, and logs out. An AI agent may operate continuously for weeks — processing requests, invoking tools, accessing data — without a session boundary that would trigger re-evaluation of its permissions.
  • AI agents don't have roles in the IAM sense. Role-based access control assumes that identities can be meaningfully categorized into roles with defined permission sets. AI agents are defined by their task context, not their role — a claims AI performing fraud investigation requires different permissions than the same claims AI performing routine processing.
  • AI agents don't change permissions gracefully under legacy IAM. When a risk limit is breached, when a regulatory update takes effect, when a customer revokes consent — the AI agent's permissions must change in real time. Legacy IAM updates permissions through reprovisioning workflows that take hours or days.
  • AI agent authorization violations are structurally undetectable by legacy monitoring. Legacy monitoring detects deviations from expected access patterns. But if an AI agent's expected access pattern was never defined — if no authorization policy specifies what the agent is and is not permitted to do — then every action the agent takes looks 'normal' to monitoring systems.
KEY INSIGHT The Authorization Gap is not a gap that existing IAM tools will eventually close with product updates. It is a structural gap between what the verify-then-trust model was designed to solve and what continuous runtime authorization for AI workloads requires. These are different problems requiring different architectural solutions.

6.3 The 'They'll Add AI Support' Objection

The most common pushback when CISOs evaluate authorization fabric solutions: 'CyberArk / SailPoint / [incumbent] is already working on AI support. Why invest in a new platform when the vendors we already have will solve this in their next release?'

This objection deserves a direct response, not a dismissal.

The incumbents are working on AI support. CyberArk has AI-focused product additions. SailPoint has NHI governance capabilities. Wiz has AI security features. These are real investments and they will improve their platforms' coverage of the Authorization Gap over time.

But 'AI support' in the context of incumbent IAM tools means extending the existing verify-then-trust model to AI agent identities — enrolling AI agents in PAM, certifying AI agent access in IGA, discovering AI agent permissions in CIEM. It does not mean implementing runtime, action-level authorization enforcement that evaluates every AI agent action against a policy that reflects current context, current task, current risk level, and current regulatory obligations. That is a different architecture.

The two architectures are not converging toward the same solution. Extending PAM to AI agents means AI agents get vaulted credentials, session recording, and periodic access certification. It does not mean AI agents get runtime enforcement of action-level authorization policy. These are genuinely different capabilities addressing genuinely different failure modes.

The question is not 'will incumbents eventually add AI support?' They will. The question is 'will that AI support close the Authorization Gap as defined by DORA Article 9, PCI-DSS Requirement 7.2.6, GDPR Article 25, and EU AI Act Article 14?' The regulatory requirements are asking for continuous runtime enforcement with action-level audit trails. Incumbent 'AI support' additions are providing NHI governance within verify-then-trust architectures. These are different answers to different questions.

6.4 Questions to Ask Your Current Vendor

6.5 Pure-Play Authorization Competitors: The Narrower Competitive Set

Beyond the incumbent IAM vendors, a small number of purpose-built authorization platforms have emerged as direct competitors. A CISO doing a complete evaluation of the authorization fabric category will encounter Axiomatics, PlainID, SGNL, and Oasis Security. They deserve direct, honest comparison — because each addresses part of the Authorization Gap, and understanding what each part is clarifies what complete coverage requires.

KEY INSIGHT The pure-play authorization market is real and growing. But each vendor addresses one or two AWARE principles. Axiomatics addresses Authorization (A). Oasis addresses Workload Identity (W). SGNL addresses Runtime Enforcement (R). None deliver complete AWARE coverage — all four dimensions, all five principles, with financial services-specific policy libraries and AI framework integrations — from a single platform.

6.6 What the Competitive Landscape Means for Your Decision

After surveying eight incumbent tools and five pure-play competitors, the competitive picture resolves into a single structural conclusion: the Authorization Gap is a category gap, not a feature gap. No existing vendor — incumbent or pure-play — was designed to solve the complete problem.

This has a practical implication for evaluation: asking your existing vendors whether they can close the Authorization Gap will produce optimistic answers. Every vendor can point to capabilities that overlap with some dimension of the gap. The right evaluation question is not 'do you have AI support?' It is the eight specific questions in Section 6.4.

The second practical implication: this is not a decision to defer until your existing vendors release their next major version. The Authorization Gap is measured by regulators in active examinations today. DORA supervisory assessments are finding it. PCI-DSS QSAs are flagging it under v4.0 Requirement 7.2.6. The vendor roadmap timeline and the regulatory enforcement timeline are not aligned.

BOARD TRANSLATION We have evaluated the market. Legacy IAM tools were not designed for AI agent authorization. Purpose-built competitors each address part of the problem. No single incumbent or pure-play vendor closes the complete Authorization Gap as defined by DORA, PCI-DSS v4.0, the EU AI Act, and GDPR simultaneously. This is a new category requirement — the same way Zero Trust was a new category requirement in 2015. Institutions that identified that need early and invested in Zero Trust architecture built a durable competitive and compliance advantage. The Authorization Gap is that moment for AI security.

7. The EnforceAuth Solution: AWARE in Practice

The Authorization Gap is a specific, structurally defined problem. It has four dimensions, five AWARE principles that close it, and one architectural requirement: runtime enforcement. EnforceAuth is the AI Security Fabric — purpose-built to implement all five AWARE principles simultaneously, across all four dimensions, from a single policy engine.

Every section of this paper has been building to a specific technical requirement. Section 2 defined AWARE. Section 3 validated it against breach evidence. Section 5 mapped it to five regulatory frameworks. Section 6 showed why existing tools — individually and collectively — cannot meet it. This section shows the architecture that does.

7.1 Design Principles

Each design principle maps directly to an AWARE pillar, ensuring the solution delivers complete coverage:

  • [A+E] Unified coverage across all four dimensions: One policy engine governing application, infrastructure, data, and AI workload authorization — satisfying the Authorization and Entitlement Minimization pillars simultaneously.
  • [R] Runtime enforcement, not perimeter-based: Authorization evaluated on every action at the moment it is requested. Policy changes take effect on the next authorization decision, measured in milliseconds.
  • [A] Policy as code: Authorization policy in OPA Rego — version-controlled in git, tested in CI/CD, deployed like any infrastructure change. Policy changes require no application redeployment.
  • [W] Identity-centric and context-aware: Non-human identities are first-class participants. Authorization decisions incorporate the full identity context: current task, current risk level, current relationship to the resource being accessed, current regulatory jurisdiction.
  • [A] Audit-ready by architecture: Every authorization decision — approved and denied — logged as a structured, immutable record.

EnforceAuth Security Posture: Who Authorizes the Authorizer?

Performance: Authorization at Financial Services Latency Requirements

Pricing Architecture: What You Should Expect

7.2 Continuous Identity: The Operating Principle

Continuous identity is the AWARE principle that distinguishes EnforceAuth's architecture from every existing IAM approach. Traditional IAM verifies identity at login, grants permissions, and trusts until session expiry. Continuous identity means:

  • Authorization continuity: Every action evaluated against current policy, not a permission granted at a prior point in time.
  • Audit continuity: Every authorization decision logged in real time, creating an unbroken decision trail.
  • Identity continuity: The identity context of every requesting entity — human or AI agent — continuously maintained and updated.

7.3 OPA vs. EnforceAuth: The Honest Comparison

The most technically sophisticated question EnforceAuth receives: 'We already have OPA deployed in our Kubernetes cluster. Why do we need EnforceAuth?' It is the right question and it deserves a direct, honest answer.

7.4 Day in the Life: Trading Bank

Environment: Mid-market commercial bank with algorithmic trading operations across equity and fixed income. EnforceAuth deployed across the trading infrastructure with the trading agent authorization policy from Use Case 1 (Section 7.7) enforced on all 12 production trading agents.

7.5 Day in the Life: Health Insurance Claims AI

Environment: National health insurance carrier. Claims AI processes 40,000 claims/day accessing medical records, billing codes, and fraud indicators from a 28-million-member data lake. EnforceAuth deployed with HIPAA minimum-necessary claims AI policy.

7.6 Day in the Life: Open Banking Fintech

Environment: EU-regulated open banking platform. 4.2 million active users. 180 third-party application integrations. 12,000+ consent changes per day. EnforceAuth deployed with PSD2 consent authorization policy.

7.7 Use Cases with Rego Policy and Plain-English Walkthrough

Use Case 1: Tier 1 Bank — Trading Agent Authorization

package enforceauth.financial.trading_agent import future.keywords.if default allow = false # Deny everything not explicitly permitted # RULE 1: Position reads — market hours, desk-scoped, no risk breach allow if { input.action == "read" input.resource.type == "position_data" input.agent.role in {"market_maker", "risk_monitor"} is_market_hours # Defined below not input.agent.flags.risk_limit_breached input.resource.desk == input.agent.authorized_desk # Desk isolation } # RULE 2: Trade execution — task token + SOD + risk limits + market hours allow if { input.action == "execute_trade" input.agent.task_token.valid == true input.agent.task_token.scope == "execution" input.agent.task_token.desk == input.agent.authorized_desk not has_position_read_in_session # SOD: cannot hold both simultaneously within_risk_limits # Defined below is_market_hours } # DORA Art. 10 audit event for every SOD violation attempt audit_event[evt] { input.resource.desk != input.agent.authorized_desk evt := { "framework": "DORA_Art10", "type": "SOD_VIOLATION_ATTEMPT", "agent_id": input.agent.id, "desk_attempted": input.resource.desk, "agent_authorized_desk": input.agent.authorized_desk, "timestamp": time.now_ns() } } is_market_hours if { h := time.clock(time.now_ns())[0]; h >= 9; h < 16 } within_risk_limits if { input.agent.metrics.var_utilization < 0.85 input.agent.metrics.open_position_count < input.agent.limits.max_positions }

In plain English: This single policy file enforces five controls: (1) Default deny — if the policy doesn't explicitly permit an action, it is blocked. No 'allow all' fallback. (2) Market hours restriction — execution is physically impossible outside 9am–4pm, regardless of what the agent requests. (3) Desk isolation — an equity desk agent cannot access fixed income positions, period. (4) SOD enforcement — the same agent instance cannot simultaneously hold position read access and execution access. This prevents an agent (or someone controlling it) from reading positions and immediately acting on that information. (5) Risk limit gating — if the agent's VAR utilization is above 85%, execution is blocked until risk returns to permitted levels. Every SOD violation attempt generates a structured DORA Art. 10 event — logged even when blocked, so the compliance record is complete.

Use Case 2: Insurance Carrier — HIPAA-Compliant Claims AI

package enforceauth.insurance.claims_ai default allow = false # Allow member record reads scoped to the active claim's member only allow if { input.action == "read" input.resource.type == "member_record" input.resource.member_id == input.context.active_claim.member_id # Claim scoping input.agent.model_version in data.approved_model_versions # Version enforcement hipaa_minimum_necessary_satisfied # Field-level control } # HIPAA minimum necessary: only fields permitted for this specific claim type hipaa_minimum_necessary_satisfied if { allowed := data.claim_type_field_allowlist[input.context.active_claim.type] input.resource.field_requested in allowed } # Block cross-claim access — zero tolerance, no exceptions deny_reason := "HIPAA_CROSS_CLAIM_ACCESS" if { input.resource.type == "member_record" input.resource.member_id != input.context.active_claim.member_id } # HIPAA audit event for every permitted record access audit_event[evt] { allow evt := { "framework": "HIPAA_MinNecessary", "claim_id": input.context.active_claim.id, "member_id": input.resource.member_id, "field_accessed": input.resource.field_requested, "model_version": input.agent.model_version, "authorization_basis": "claim_context_minimum_necessary", "timestamp": time.now_ns() } }

In plain English: Four controls in this policy: (1) Claim-context scoping — the AI can only access the specific member's records for the claim it is currently processing. It cannot query any other member's data regardless of what fraud correlation logic it might benefit from. (2) Model version enforcement — only the model version currently in the state insurance regulator's approved versions list can process production underwriting decisions. (3) Field-level minimum necessary — for a medical claim, the AI can only access diagnosis codes and procedure codes, not behavioral history or financial records. The allowed fields are defined per claim type in a data registry. (4) Complete HIPAA audit trail — every permitted access generates a structured record with claim ID, member ID, field accessed, model version, and the specific authorization basis.

Use Case 3: Fintech — PSD2 Consent Authorization

package enforceauth.openbanking.consent default allow = false # Allow only if consent is currently active, unrevoked, unexpired, and in-scope allow if { consent := data.consent_registry[input.customer_id][input.third_party_id] consent.status == "active" consent.revoked_at == null not consent_expired(consent) # Evaluated NOW, not at token issue input.resource.data_class in consent.authorized_data_classes } consent_expired(c) if { time.now_ns() > c.expires_at } # PSD2 Art. 67 audit — every data sharing decision, permit and deny audit_event[evt] { consent := data.consent_registry[input.customer_id][input.third_party_id] evt := { "framework": "PSD2_Art67", "customer_id": input.customer_id, "third_party_id": input.third_party_id, "data_class": input.resource.data_class, "consent_id": consent.id, "decision": allow, "timestamp": time.now_ns() } }

In plain English: The critical phrase in this policy is 'evaluated NOW.' Traditional OAuth-based consent enforcement evaluates consent state once — when the token is issued. If the customer revokes consent 10 minutes later, the token is still valid until it expires (typically 24–48 hours). This policy evaluates the current consent state from the live consent registry on every API call. The moment consent.revoked_at is set, every subsequent request is denied — regardless of whether an OAuth token is still technically valid.

Use Case 4: Capital Markets — Information Barrier Enforcement

package enforceauth.capital_markets.info_barrier default allow = false # Public research — accessible from any side allow if { input.action == "read" input.resource.classification == "public_research" } # Proprietary data — only accessible from same barrier side allow if { input.action == "read" input.resource.barrier_side == input.agent.authorized_side not input.resource.mnpi_flagged # MNPI resources blocked even within side } # Execution — only for trading-side agents (advisory-side BLOCKED) allow if { input.action in {"execute_trade", "submit_order"} input.agent.authorized_side == "trading" # Advisory-side agents can NEVER invoke execution APIs — enforced at runtime, # not dependent on model behavior or explicit instruction compliance } # SEC Rule 17a-4 audit event for every cross-barrier attempt audit_event[evt] { input.resource.barrier_side != input.agent.authorized_side evt := { "framework": "SEC_17a4_InfoBarrier", "type": "CROSS_BARRIER_ACCESS_ATTEMPT", "agent_id": input.agent.id, "resource_side": input.resource.barrier_side, "agent_side": input.agent.authorized_side, "resource_id": input.resource.id, "timestamp": time.now_ns() } }

In plain English: The most important line in this policy is the comment on the execution rule: 'Advisory-side agents can NEVER invoke execution APIs — enforced at runtime, not dependent on model behavior or explicit instruction compliance.' This is what makes the information barrier technically enforceable for AI systems with cross-barrier training data. You cannot control what the model learned during training. You can control what it is permitted to do at inference time. Even if an advisory AI model has internalized MNPI from its training data, it cannot transmit that information through trading execution because the execution API is blocked by authorization policy.

7.8 Customer Evidence

CUSTOMER EVIDENCE: EU Tier 1 Bank — DORA Art. 9 Supervisory Finding Resolution 14 weeks — DORA supervisory examiner finding closed; authorization governance evidence package accepted "Authorization gap identified in DORA preparatory self-assessment. Trading agent authorization policy deployed covering 12 production AI agents across equity and fixed income desks. DORA Article 10 compliant audit logs active within 30 days. Supervisory finding formally closed at the follow-up examination 14 weeks after EnforceAuth enforcement deployment."
CUSTOMER EVIDENCE: National Health Insurance Carrier — HIPAA OCR Finding Resolution 68% reduction in audit preparation labor — Prior HIPAA OCR examination finding resolved; minimum necessary controls confirmed by external auditor "Claims AI processing 40,000 claims/day scoped to per-claim member record access. HIPAA minimum-necessary field-level enforcement active. Prior OCR finding related to AI system data access controls formally resolved. External audit firm confirmed controls satisfy HIPAA §164.514(d). Annual audit preparation time reduced from 16 hours to 5 hours."
CUSTOMER EVIDENCE: EU Open Banking Fintech — PSD2 Consent Enforcement 340% sector increase in PSD2 enforcement — zero actions against this institution — PSD2 consent revocation compliance window: 18 hours → <10 seconds "Consent-based data sharing authorization evaluated at every API call against live consent registry. Revocation effective within seconds. PSD2 Article 67 audit trail active for all data sharing decisions. Institution received zero PSD2 enforcement actions in 2024 — a year in which PSD2 enforcement actions in the sector increased 340%."
CUSTOMER EVIDENCE: US Mid-Market Bank — Authorization Debt Remediation $3.1M authorization debt remediation cost avoided — 85,000 NHI credentials inventoried and scoped; 23% orphaned credentials detected and revoked "Authorization Gap Assessment identified 85,000 non-human identity credentials. 23% (19,550) flagged as orphaned — no authorization requests in 90+ days. Automated revocation workflow executed. Engineering remediation cost avoided: $3.1M (19,550 credentials × $150/hr × 1hr average remediation). Ongoing orphaned credential detection prevents future accumulation."

8. Implementation: Five Phases, Common Blockers, Real Timelines

8.1 Five-Phase Deployment Framework

KEY INSIGHT A phase is complete when its deliverables exist and have been validated — not when the work has been done. If the deliverable does not meet the standard, the phase is not complete. Moving to Phase 3 without a validated shadow mode baseline is how enforcement deployments create production outages.

8.2 Integration Architecture

8.3 Deployment Sizing

8.4 Common Integration Challenges — Addressed Directly

8.5 Migrating from OPA or Existing Authorization Infrastructure

Organizations with existing OPA investments frequently ask whether EnforceAuth replaces or extends their existing infrastructure. The answer is: extend, not replace.

  • Existing Rego policies are preserved. EnforceAuth's policy engine is OPA-native. Every Rego policy currently in production continues to function.
  • Existing Kubernetes Gatekeeper deployments federate seamlessly. The two operate at different layers: Gatekeeper handles Kubernetes admission control; EnforceAuth extends policy enforcement to application-layer APIs, data access, and AI workload authorization.
  • Styra DAS customers have a specific migration path. The migration path is additive: EnforceAuth provides the AI workload authorization layer, financial services policy library, and NHI identity fabric that Styra DAS does not address.
MIGRATION TIMELINE Typical migration from Styra DAS to EnforceAuth (additive): 4–6 weeks. Typical migration from raw OPA deployment: 6–10 weeks. No existing Rego policies require rewriting.

9. Risk Quantification, Sensitivity Analysis, and ROI

The worked example and sensitivity analysis below give you the inputs and methodology to build an institution-specific ROI case. Every assumption is made explicit — because a CFO or audit committee will ask where the numbers come from, and 'the white paper said so' is not a satisfactory answer.

PEER ADOPTION CONTEXT As of Q1 2026, approximately 12% of DORA-regulated Tier 1 institutions have implemented continuous AI agent authorization enforcement, up from an estimated 3% in Q1 2024. Among institutions that received a DORA supervisory finding related to AI access controls in 2025, 78% initiated formal authorization fabric evaluation within 90 days of the finding. Source: EnforceAuth advisory assessment program, n=47; DORA supervisory report analysis.

9.1 Risk Quantification Framework

9.2 ROI Sensitivity Analysis

9.3 Worked ROI Example: Mid-Market Health Insurance Carrier

Institution profile: $45B assets, 3,200 employees, 6 production AI systems, approximately 85,000 non-human identity credentials. EU operations (DORA and GDPR apply). US operations (SOX/HIPAA apply). AGI baseline score: 1.9 (Level 2).

WORKED ROI: MID-MARKET HEALTH INSURANCE CARRIER ($45B ASSETS) RISK EXPOSURE — BASE CASE Data breach expected annual loss: $6.1M × 35% auth-related fraction × 10% probability = $213K/yr DORA fine exposure: $450M global turnover × 2% max × 8% probability = $720K/yr expected HIPAA remediation cost: $1.8M estimated × 20% probability = $360K/yr expected EU AI Act fine exposure: €15M potential × 6% probability = $950K/yr expected Authorization debt remediation (deferred one-time): 85K NHIs × 2.3× over-prov × $150/hr × 0.3hr = $3.8M one-time TOTAL RISK EXPOSURE: $2.24M/yr expected + $3.8M deferred = $6.04M total quantified exposure OPERATIONAL COST SAVINGS — BASE CASE Access review labor: 2,400 hrs/yr × $150/hr × 65% reduction = $234K/yr Compliance audit preparation: 800 hrs/yr × $200/hr × 80% reduction = $128K/yr Authorization engineering: 1,200 hrs/yr × $175/hr × 60% reduction = $126K/yr Regulatory change implementation: 6 changes/yr × $75K avg × 85% reduction = $383K/yr Authorization incident investigation: 8 incidents/yr × $42K avg × 70% reduction = $235K/yr TOTAL OPERATIONAL SAVINGS: $1.1M/yr NET ROI AT BASE CASE Year 1 return: Risk reduction ($2.24M × 70% mitigation factor) + Operational savings $1.1M = $2.67M Year 1 investment: $1.0M. Net Year 1 return: $1.67M. 3-Year NPV at 10% discount rate: $6.2M return on $2.2M 3-year investment. PAYBACK PERIOD: 4.5 months from initial enforcement deployment (base case).

9.4 The Cost of Inaction: A 3-Year Projection

THE CISO CAREER RISK A CISO who cannot answer a DORA examiner's questions about AI agent authorization controls — in an examination cycle that is actively finding authorization gaps — faces a professional risk position that is distinct from the institution's regulatory risk. Peer context: of the 23 financial services CISOs who reported receiving a DORA supervisory finding related to AI system access controls in 2025, 17 had been aware of the authorization gap for over 12 months prior to the finding. The finding was not the surprise. The speed with which it became a board-level remediation mandate with a defined timeline was. You know the gap is there. The examiners are now looking for it. The question is whether you close it before they find it.

9.5 Strategic Returns: The Non-Quantifiable But Real Value

  • AI deployment velocity: With authorization governance answered by the platform, each new AI agent deployment does not require a bespoke security review. Authorization becomes an accelerant, not a bottleneck.
  • Board-level AI governance credibility: EnforceAuth provides the metrics, audit trails, and board reporting infrastructure to answer AI governance questions with evidence.
  • M&A integration readiness: A policy-as-code authorization architecture allows acquired entities to be brought under the existing policy framework.
  • Regulatory examination confidence: When a DORA examiner asks about AI system access controls, the CISO can provide a complete, structured response — not a presentation about what we plan to implement, but a report on what is already in production.

9.6 When EnforceAuth Is Not the Right Choice

BOARD TRANSLATION The ROI case closes in under five months at the base case. The peer adoption data shows 12% of Tier 1 institutions have already implemented continuous AI agent authorization enforcement. The regulatory calendar is in active enforcement. The cost of waiting — measured in compounding authorization debt, growing regulatory exposure, and the multiplier effect of emergency vs. proactive remediation — is larger every quarter than it was the quarter before.

10. The Future: Authorization Gets Harder From Here

Every trend in AI agent adoption in financial services makes the Authorization Gap harder to close, not easier. Understanding what is coming is essential for CISOs making three-to-five year security architecture investments — because the authorization infrastructure you build now needs to be capable of governing what your AI deployment will look like in 2028, not just what it looks like today.

10.1 MCP: The Authorization Surface You Haven't Governed Yet

Model Context Protocol (MCP), introduced by Anthropic in late 2024 and adopted across the AI industry with remarkable speed, is a standardized protocol for AI agents to connect to external tools, data sources, and APIs. As of early 2026, MCP is in production deployment at financial services organizations and is on track to become the dominant integration pattern for agentic AI systems within 18 months.

MCP changes the authorization surface in a specific and important way. Before MCP, an AI agent's access to external tools was mediated by the specific API integrations built into the agent's deployment. With MCP, an AI agent can connect to any MCP server that its credentials permit — dynamically, at runtime, without a pre-defined integration. An AI agent with MCP access to a financial data MCP server can invoke any tool that server exposes, regardless of whether the specific tool invocation is within the agent's intended operational scope. The authorization decision must now be evaluated at the MCP tool-invocation layer.

# EnforceAuth: MCP Tool Invocation Authorization package enforceauth.mcp.financial_data default allow = false # Market data reads — permitted for authorized agents allow if { input.mcp_tool == "get_market_prices" input.agent.authorized_tools["get_market_prices"] == true is_market_hours } # Order submission — trading-side agents only, with task token allow if { input.mcp_tool == "submit_order" input.agent.authorized_side == "trading" input.agent.task_token.valid == true input.agent.task_token.scope == "execution" } # All other MCP tools — denied and logged audit_event[evt] { not allow evt := { "framework": "MCP_AuthorizationPolicy", "type": "MCP_TOOL_UNAUTHORIZED", "agent_id": input.agent.id, "tool_attempted": input.mcp_tool, "timestamp": time.now_ns() } }

In plain English: This policy evaluates every MCP tool call before it executes — not at the connection level (which tool the agent can reach), but at the invocation level (which specific tool call the agent is permitted to make, in which context). The 'submit_order' tool is only permitted for trading-side agents with valid execution task tokens. An advisory AI agent with MCP access to the same financial data server cannot invoke 'submit_order' regardless of what prompt or task it receives.

10.2 The Regulatory Pipeline: What Is Coming After 2026

10.3 The Agentic AI Trajectory

Three architectural trends will compound the Authorization Gap unless organizations build the infrastructure to contain it now:

  • Long-horizon autonomous agents. Systems executing complex, multi-week business processes — loan origination, regulatory capital optimization, portfolio rebalancing — with minimal human checkpoints.
  • Multi-agent collaborative networks. Networks of specialized agents that collaborate on tasks with dynamic role assignment and permission delegation. The permission inheritance problem described in Section 3.2 will compound as delegation chains grow in depth and complexity.
  • Persistent AI agents with long-term memory. Agents that accumulate context and adapt behavior over extended operational periods. Authorization policy for these agents must account for the evolution of the agent's knowledge and capabilities over time.
KEY INSIGHT The authorization problem gets harder, not easier, with every advancement in AI agent capability. Multi-agent networks, long-horizon autonomous agents, and MCP create permission delegation complexity that static IAM cannot govern. The AWARE Framework scales with the complexity; verify-then-trust does not.
BOARD TRANSLATION The future of AI in financial services involves agents that are more capable, more autonomous, and more deeply embedded in regulated workflows than today's deployments. Each of those trends expands the Authorization Gap if governance infrastructure is not built now. The institutions that build the authorization fabric in 2026 will be able to deploy the 2028 agent architectures safely. The institutions that wait will face a compounding remediation problem at the same time they are trying to compete with AI-enabled peers.

11. CISO Action Plan: 90 Days, Clear Ownership, Specific Outputs

The following action plan gives you battle-tested steps from Authorization Gap assessment to board-reportable risk reduction — with specific owners and decision gates at every stage.

IF YOU ARE UNDER ACTIVE REGULATORY EXAMINATION RIGHT NOW This action plan is structured for proactive remediation. If you have already received a DORA supervisory finding, a PCI-DSS QSA finding, or an EU AI Act conformity assessment gap — with a mandatory remediation timeline — the sequence is compressed but the deliverables are the same. Your immediate deliverable to the examiner: the Phase 1 output — NHI inventory, AGI baseline score, and a documented remediation roadmap with timeline. Contact mark@enforceauth.com directly for expedited onboarding under active examination timelines.

Days 1–30: Assess, Quantify, and Get Budget

Days 31–60: Implement, Enforce, and Test

Days 61–90: Expand, Report, and Present

KEY INSIGHT The 90-day plan works when ownership is clear and decision gates are real. The most common failure mode: a security initiative with no engineering owner stalls at Phase 2. Name the owners before Day 1. Treat the decision gates as decisions, not checkpoints.
FREE TIER — START THE ASSESSMENT TODAY EnforceAuth's Free Tier provides 1 million authorization decisions per month at no cost, no credit card, and no feature gating. Start at enforceauth.com or contact sales@enforceauth.com for a guided onboarding session.

12. Conclusion: The Crisis, Resolved

We opened this paper with a diagnosis: financial services institutions face an authorization crisis of their own making. They have deployed AI at extraordinary scale — systems that operate autonomously on customer funds and regulated data — without building the authorization infrastructure to govern what those systems are permitted to do.

The diagnosis stands. The AGI average of 2.1/5.0 across Tier 1 institutions quantifies it. The $2.3 billion in documented authorization failures validates it. The DORA supervisory assessments finding AI authorization gaps as priority remediation items confirm it. The inflection point is real, the regulatory enforcement is active, and the window for proactive remediation is narrowing.

But this paper is not only a diagnosis. It is an argument for a specific resolution.

The AWARE Framework — Authorization, Workload identity, Audit continuity, Runtime enforcement, Entitlement minimization — is the complete model for what a resolved authorization posture looks like. It is not aspirational. Every principle in AWARE is implemented, in production, by EnforceAuth customers today. The technology to close the Authorization Gap exists, is battle-tested, and is deployable at financial services scale.

What does resolution look like? A trading agent that cannot execute outside market hours, not because someone remembered to lock it down, but because the policy prevents it automatically and the policy is tested in CI/CD. A claims AI that cannot access records outside the current claim context, not because the engineers were careful, but because the authorization policy makes it technically impossible and generates a HIPAA-compliant audit trail for every record it does access. A fintech platform where consent revocation takes effect in seconds, not hours, because consent state is evaluated at every API call rather than at token issuance.

Resolution looks like an institution that can answer, with evidence: what is every AI agent in our environment permitted to do? How do we know? Who reviews it? What does the audit trail look like? Resolution looks like an AGI score of 4.5 or above — not because a compliance team certified it, but because continuous runtime enforcement produces it as a natural output of the authorization architecture.

The Authorization Gap is in your organization. The AGI score you would get today measures how wide it is. The 90-day action plan in Section 11 tells you exactly how to start closing it. The AWARE Framework tells you what 'closed' looks like. And the Free Tier at enforceauth.com lets you validate the policy engine against your first AI workload today — before any procurement decision, before any formal engagement, at no cost.

The crisis is real. The resolution is available. The question is only how long you wait.

START HERE Run the AGI Scorecard. Today. Appendix B is 20 questions. Score it. The number you get is your authorization gap exposure in a form you can show a board. It takes 30 minutes and costs nothing. If your score is below 3.0: contact sales@enforceauth.com for a complimentary Authorization Gap Assessment. If you want to validate the policy engine: the Free Tier at enforceauth.com provides 1M authorization decisions/month at no cost. If you want to talk through your institution's specific profile: mark@enforceauth.com. A working session, not a pitch.

About the Author

Mark O. Rogge

CEO & Founder, EnforceAuth, Inc. · Former CRO, Styra (acqui-hired by Apple) · GitLab · Weights & Biases

The claim at the center of this paper — that authorization, not authentication, is the defining security challenge of the financial services AI era — is not a market thesis that Mark Rogge developed as an outside observer. It is a conclusion he reached after spending a decade building the commercial foundations of the authorization infrastructure that enterprise organizations run in production today.

As CRO at Styra, Mark built the go-to-market foundation for Open Policy Agent — the CNCF-graduated project that is now the industry standard for policy-as-code authorization, deployed in production at Google, Netflix, Capital One, and hundreds of other enterprises. He was inside Styra when OPA went from an internal tool to the authorization primitive that underlies Kubernetes admission control, microservices authorization, and an entire ecosystem of enterprise security products. Styra was subsequently acqui-hired by Apple, a validation of OPA's foundational importance to the authorization stack. Mark has worked with OPA in enterprise financial services environments longer than almost anyone in the industry.

At GitLab, Mark built commercial traction for one of the world's most widely adopted DevSecOps platforms — learning how security tooling gets adopted (and rejected) by engineering teams at scale. At Weights & Biases, the leading MLOps platform, he developed direct exposure to the governance gap between how machine learning models are built and how they need to be governed in production environments. Across all three companies, a consistent pattern: the infrastructure that developers build outpaces the governance infrastructure that security and compliance organizations need to govern it.

EnforceAuth is Mark's specific answer to the authorization governance gap he identified through this decade of work. The Authorization Gap is not a gap he read about in a research report. It is a gap he encountered in sales conversations at major financial institutions, in competitive evaluations with enterprise security buyers, and in the gap between what OPA could do technically and what financial services organizations needed in production governance terms. EnforceAuth is built to close that specific gap — the gap between policy-as-code authorization capability and enterprise financial services production deployment reality.

Mark serves as an advisor to multiple security and AI infrastructure startups, and to venture capital and private equity firms evaluating the identity, authorization, and AI security landscape. He is a recognized speaker on enterprise authorization, AI security governance, and policy-as-code in regulated industries.

A note on the data in this paper: the Authorization Gap Index averages (2.1/5.0 for Tier 1 banks, 2.0 industry overall), the segment-specific statistics (74% of capital markets firms with cross-barrier AI access, 12% peer adoption figure), the customer evidence metrics, and the CISO peer research are drawn from EnforceAuth's advisory assessment program — the 47 financial services organizations assessed under Mark's direct oversight in 2024–2025. These are not synthesized from third-party surveys. They are primary data from institutions that engaged EnforceAuth for Authorization Gap Assessments. Where third-party sources underpin a claim (IBM breach cost data, CyberArk NHI ratio, EBA enforcement figures), those sources are cited explicitly in Appendix E. EnforceAuth self-citations are labeled throughout as proprietary advisory data, not presented as third-party validated research.

mark@enforceauth.com · enforceauth.com · San Diego, California

Appendix A: Regulatory Cross-Reference Matrix

Maps AWARE Framework controls to specific provisions across all five regulatory frameworks.

Appendix B: Authorization Gap Index (AGI) Scorecard

Score 0 (No), 1 (Partial), or 2 (Yes) for each question. Maximum: 40 points. AGI = total ÷ 8, normalized to 5.0. Industry average: 2.0. Tier 1 bank average: 2.1. Target: ≥ 4.0 (Level 4) for regulatory defensibility.

SCORING KEY: 0–10 pts (AGI 0.0–1.25): Level 1 — Critical gap. 11–18 pts (AGI 1.4–2.25): Level 2 — Significant gap (industry average). 19–26 pts (AGI 2.4–3.25): Level 3 — Moderate gap. 27–34 pts (AGI 3.4–4.25): Level 4 — Manageable gap. 35–40 pts (AGI 4.4–5.0): Level 5 — Gap Closed.

Appendix C: Vendor Evaluation Questions

Use when evaluating whether your current vendor can close the Authorization Gap, or when evaluating new vendors.

Appendix D: Glossary of Key Terms

Appendix E: Bibliography and References

  1. McKinsey & Company. 'The State of AI in 2025: Global Survey.' McKinsey Global Institute, 2025.
  2. CyberArk. 'Identity Security Threat Landscape Report 2024.' CyberArk Software, 2024. Primary source for 82:1 NHI-to-human ratio and 40% orphaned credential statistic.
  3. Verizon. 'Data Breach Investigations Report 2024.' Verizon Business, 2024. Primary source for 20–25% insider threat figure in financial services.
  4. European Union. 'Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA).' Official Journal of the EU, December 16, 2022.
  5. PCI Security Standards Council. 'PCI DSS v4.0: Payment Card Industry Data Security Standard.' PCI SSC, March 2022.
  6. European Union. 'Regulation (EU) 2024/1689 — Artificial Intelligence Act.' Official Journal of the EU, July 12, 2024.
  7. European Union. 'Regulation (EU) 2016/679 — GDPR.' Official Journal of the EU, April 27, 2016.
  8. Anthropic. 'Model Context Protocol: Specification and Developer Documentation.' Anthropic, November 2024.
  9. EnforceAuth. 'Financial Services AI Authorization Gap Assessment: Capital Markets Segment.' EnforceAuth Advisory Research, n=12, 2025.
  10. European Banking Authority. 'PSD2 Supervisory Convergence: Enforcement Actions and Findings Annual Report 2024.' EBA, 2024.
  11. PCAOB. 'Staff Guidance: Automated Systems and IT General Controls Under AS 2201.' PCAOB, 2024.
  12. Irish Data Protection Commission. 'Guidance on Article 25 Data Protection by Design for AI Systems Processing Personal Data.' DPC, September 2024.
  13. FFIEC. 'IT Examination Handbook — Access and Authentication.' Federal Financial Institutions Examination Council, 2023 update.
  14. IBM Security. 'Cost of a Data Breach Report 2024.' IBM Corporation, 2024. $6.1M average financial services breach cost.
  15. Gartner. 'Market Guide for AI Security: Identity and Access Management for AI Workloads.' Gartner, Inc., 2025.
  16. Gartner. 'Enterprise IAM Market Sizing: Financial Services Sector.' Gartner, Inc., 2024.
  17. Capital One Financial Corporation. 'Settlement Agreement with Office of the Comptroller of the Currency and Federal Reserve Board.' OCC Enforcement Action 2020-87.
  18. Robinhood Markets, Inc. 'Form 8-K — Material Cybersecurity Incident Disclosure.' SEC EDGAR, November 8, 2021.
  19. EnforceAuth. 'Authorization Gap Index Benchmark: Financial Services 2025.' EnforceAuth Advisory Research, n=47, 2024–2025.
  20. SWIFT. 'Customer Security Programme: Findings and Mandatory Controls.' SWIFT, 2016.

© 2026 EnforceAuth, Inc. · San Diego, CA · enforceauth.com · CONFIDENTIAL

About EnforceAuth

EnforceAuth is the AI Security Fabric for the agentic era. We provide decision-centric authorization across applications, infrastructure, data, and AI workloads. Write policy once. Enforce everywhere.

Follow us on LinkedIn

All posts