Zero trust authorization breaks when banking policy fragments

At a glance

What this is: This is an analysis of why embedded authorization logic in banking services weakens Zero Trust, auditability, and policy consistency at scale.

Why it matters: It matters because IAM, PAM, and platform teams need one auditable decision layer for human, NHI, and agent-driven requests, not divergent service-by-service enforcement.

By the numbers:

• Finance accounts for 27% of all data breaches globally, with an average incident cost of $5.9 million.
• 41.8% of those breaches originated through third-party vendors.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected.

👉 Read Cerbos's analysis of authorization drift and Zero Trust in banking

Context

Authorization is the control plane that decides which identity can perform which action on which financial resource under specific conditions. In banking, that decision has to remain consistent across products, services, and channels, or the programme stops behaving like a governed model and starts behaving like a collection of local exceptions.

This article argues that embedding authorization logic inside each service creates drift, weakens Zero Trust, and makes audit evidence hard to prove. The same pattern matters when non-human identities and AI-driven workflows inherit banking permissions, because every additional execution path increases the number of places where policy can diverge.

For teams building on modern banking stacks, the governance problem is not just enforcement. It is proving that the same policy existed, was active, and was evaluated at the right time across every payment, approval, and data-access decision.

Key questions

Q: How should banking teams implement authorization without embedding rules in every service?

A: They should move approval thresholds, access conditions, and resource rules into a shared runtime policy layer. That gives every service the same decision source, reduces drift, and makes it easier to prove that controls were applied consistently across products, channels, and transaction types.

Q: Why does embedded authorization weaken Zero Trust in banking platforms?

A: Zero Trust depends on every request being evaluated against explicit policy at runtime. When each service enforces its own logic, the organisation loses a single decision point and can no longer prove that the same access rule governed each transaction or data-access request.

Q: What breaks when authorization decisions are not versioned and logged?

A: Auditors and regulators cannot easily see what control was active at a specific time, so teams must reconstruct the answer from deployment records and code history. That slows incident response, weakens accountability, and makes control evidence fragile under scrutiny.

Q: Who is accountable when an AI agent or service account executes a banking action?

A: The bank remains accountable for the delegated identity, the policy that allowed the action, and the evidence showing why it was permitted. If the organisation cannot tie the action to a specific policy version and identity, accountability becomes operationally unclear.

Technical breakdown

Why embedded authorization drifts across services

Embedded authorization means each microservice contains its own access rules instead of asking a central policy engine at runtime. That works early on, but it creates logic drift because teams copy thresholds, approval rules, and exception handling in slightly different ways. Once that happens, two services can evaluate the same transaction differently even when they appear to follow the same policy. In regulated banking, that breaks the ability to demonstrate consistent controls. It also creates change-friction, because a policy update becomes a coordinated code release rather than a governed decision change.

Practical implication: move enforcement into a single runtime policy layer so access decisions are evaluated consistently across services.

How policy versioning supports audit evidence

Versioned authorization separates the policy decision from the application code that invokes it. That distinction matters because auditors and regulators need to know what rule was approved, when it became active, and which version governed a specific transaction. If the control is embedded in code, teams must reconstruct the answer from commits and deployments, which is slow and error-prone. A governed permission model records the decision inputs, the policy version, and the evaluated outcome so the organisation can prove control rather than infer it after the fact.

Practical implication: retain policy versions and decision records so every material action can be tied back to a specific control state.

Why Zero Trust depends on runtime authorization for NHI and AI-driven actions

Zero Trust assumes every request is evaluated explicitly at the moment it is made. That model fails when a service, workload, or AI agent inherits broad permissions and reuses them without a fresh contextual decision. As AI-driven execution increases transaction velocity, the real issue is not the number of requests but whether each request is checked against identity, action, resource, and context. If machine identities can chain API calls under delegated authority, the weakest permission in the path becomes the effective ceiling for the whole workflow.

Practical implication: require runtime evaluation for every machine-initiated request, especially where service accounts or agents can chain actions.

Threat narrative

Attacker objective: The objective is to perform unauthorized or poorly governed financial actions while obscuring which control actually allowed them.

1. Entry begins when a service, workflow, or AI-driven process is granted overbroad delegated access inside the banking platform.
2. Credential access or abuse occurs when that identity can reuse the same permission path across multiple services without a central runtime policy check.
3. Escalation follows when inconsistent service-level logic or missing contextual checks allows higher-value actions than were intended.
4. Impact lands in the form of inconsistent approvals, weak auditability, and increased exposure on payments and customer financial data.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

Policy drift is the real failure mode here, not isolated implementation error. When authorization lives inside each service, the programme no longer has one governable decision layer. The same transfer, approval, or data-access request can be evaluated differently depending on which code path receives it. That creates a control environment where enforcement cannot be demonstrated consistently, which is a governance problem before it is a technical one. Practitioners should treat fragmented authorization as a structural control failure.

Permission management in banking only works when the policy state is provable. Regulators do not just want to know that access was restricted. They want evidence of what rule was active, when it changed, and how the decision was made. If engineers must reconstruct that answer from deployment history, the control is too dispersed to be defensible. The implication is that auditability must be designed into the authorization model, not recovered from application logs after the fact.

Runtime authorisation for banking services is now an NHI governance issue as much as an application design issue. Service accounts and AI-driven workflows inherit the same weaknesses when permissions are overbroad or when contextual checks are bypassed. As transaction velocity rises, the number of decisions multiplies faster than manual governance can keep up. Practitioners should therefore reframe access control as non-human identity governance across every request path, not as a local code concern.

Consistent Zero Trust enforcement depends on a single evaluated policy, not shared assumptions across teams. Zero Trust breaks down when each team encodes its own interpretation of thresholds, approvals, and exceptions. That means the organisation has no reliable way to prove the same control was applied everywhere. For banking platforms, the practical conclusion is that policy consistency is the control, and service-level duplication is the risk.

Identity blast radius expands when one overbroad permission can chain across payments, balances, and customer records. Once a workflow can orchestrate multiple API calls under a delegated identity, the real perimeter is the policy boundary around that identity, not the service boundary around the application. That is why least privilege in banking must be defined by action, resource, and context, or the effective blast radius remains too large to govern.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities - 46% confirmed, 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a broader lifecycle view, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding change the control model.

What this signals

Policy fragmentation is a governance smell that will surface faster as transaction velocity rises. Teams should expect more pressure on runtime authorisation, decision logging, and evidence preservation as banks add automation to core payment and approval flows. The more services encode their own interpretation of access, the harder it becomes to prove the control state that was actually live.

Runtime policy will become the organising layer for mixed human, NHI, and agent traffic. The practical shift is away from app-local authorization and toward one decision model that can answer who or what may act, on which resource, and under which context. That model lines up with the NIST Cybersecurity Framework 2.0 and Zero Trust thinking because it turns control consistency into an auditable programme objective.

Identity blast radius will matter more than service ownership. As machine identities accumulate in financial workflows, the question is no longer which team owns the code path, but which identity can trigger the widest downstream effect. For reader programmes, that means mapping delegated permissions to business risk, not just infrastructure boundaries.

For practitioners

• Centralise authorization into a runtime policy layer Move permission decisions out of individual services so approvals, thresholds, and resource checks are evaluated consistently at request time.
• Version every policy change and retain decision traces Store the approved policy version, the identity, the action, the resource, and the evaluation outcome so auditors can reconstruct control state without relying on commit history.
• Treat service accounts as governed identities Inventory machine identities that can initiate payments, read customer records, or call downstream APIs, then scope each one to the minimum action set and context needed.
• Test for service-by-service authorization drift Run comparative checks across similar workflows to find where duplicate thresholds, approvals, or exception paths have diverged from the intended control model.
• Require contextual checks for AI-driven requests If agents or automated workflows can initiate banking actions, force each request through identity, action, resource, and context evaluation before it reaches execution.

Key takeaways

• Authorization drift is the core risk because service-level rule duplication makes banking controls diverge over time.
• The scale of exposure is real, with finance representing 27% of global breaches and an average incident cost of $5.9 million.
• A central runtime policy layer with versioned evidence is the control model that most directly reduces inconsistency, audit friction, and Zero Trust breakage.

Key terms

• Runtime Policy Layer: A runtime policy layer is a central control plane that evaluates each access request at the moment it happens. It separates decision logic from application code so teams can change policy without rewriting every service, and auditors can trace the control state that governed a transaction.
• Authorization Drift: Authorization drift is the gradual divergence of access rules across services, teams, or workflows that were meant to behave the same way. It usually appears when local code copies of permission logic evolve independently, creating inconsistent decisions and weakening the ability to prove a single control model.
• Policy Versioning: Policy versioning records which access rule was approved, when it became active, and what evaluation logic was in force at a given time. In regulated environments, it turns authorization from an inference problem into an evidence problem with a clear audit trail.
• Identity Blast Radius: Identity blast radius is the amount of damage or access expansion possible when one identity has excessive permissions. In banking, it is shaped by the actions, resources, and context that a service account, workload, or agent can chain together before detection or review.

Deepen your knowledge

Authorization drift, runtime policy consistency, and audit evidence are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your banking platform is moving toward service-based or AI-driven execution, it is worth exploring.

This post draws on content published by Cerbos: authorization drift, Zero Trust, and permission management in banking. Read the original.