Authorization sits at the center of every payment, approval, and access to customer financial data. In a new digital banking platform built by multiple teams shipping services in parallel, these rules will be implemented across dozens of services. If authorization logic is embedded directly inside each service, enforcement will begin to diverge as the platform grows.

That approach works at first. Over time, similar transactions are evaluated differently depending on which service handles them. Access control changes require coordinated releases across teams. When regulators ask how access is enforced consistently across the platform, there is no single policy layer that demonstrates it.

This is where Zero Trust breaks apart. Zero Trust requires consistent runtime evaluation of every request against explicit policy. If enforcement varies by service, that guarantee no longer holds. Under scale and AI-driven execution, the gap becomes systemic risk rather than an isolated defect.

Here is how those risks play out in practice:

Note: Permission management in banking means defining which identity can perform which action on which financial resource under specific conditions. I use authorization, permission management, and access control as synonyms. They describe system-level enforcement logic, not payment approval.

Inconsistent enforcement of approvals and limits

One thing we’ve heard directly from fintech teams is how messy authorization enforcement becomes over time. A team builds a transfer service and adds dual approval above a certain amount. Another team builds a related workflow and reimplements the same logic in its own way. Months later, both flows handle similar transactions but enforce thresholds differently. The product team believes the access control is consistent, but the actual implementation is not.

PCI DSS 4.0, updated in 2024, requires consistent authorization enforcement and detailed logging across payment systems, and fragmented implementation makes that harder to demonstrate. Fragmented enforcement also weakens Zero Trust posture because access policy evaluation depends on which service receives the request rather than a single runtime model.

Impact on product rollout and change velocity:
Changing a limit or launching a new payment flow requires code changes in multiple services. What should be a policy update becomes a coordinated engineering release. This reduces the speed of your product releases and time-to-market.

Inability to prove which control was active

The next issue surfaces during audit preparation. A transaction limit changes during a release cycle, but the logic is embedded directly in the banking application code. There is no separately versioned permission management policy that shows:

• what was formally approved,
• when it was approved,
• and which version was active in production at a given date.

When an auditor asks which control governed a specific high-value transfer 6 months ago, engineers rely on commit history and deployment records to reconstruct the answer. The European Central Bank's 2025 supervisory priorities require a clear, documented link between approved controls and their effective implementation. Without a versioned authorization policy tied to production, that linkage is difficult to demonstrate.

Impact on regulatory response timelines:
When a regulator asks which control configuration was active at a specific date, the bank cannot retrieve a governed access policy version directly. Engineering & IAM teams spend time confirming what was live at that moment, which slows formal supervisory communication.

Slow answers during incidents and audits

The issue becomes more visible during a live incident. A suspicious payment is flagged, or a customer disputes a high-value transfer. Security and compliance need to explain why the system allowed that action at that moment. If authorization decisions are not logged with identity, action, resource, and policy version, the reasoning behind the decision is not directly visible. Teams gather logs from multiple services to reconstruct what happened.

When decision traceability is weak, incident response shifts from containment to investigation. Time is spent determining whether the system behaved as designed instead of immediately assessing impact.

Impact on incident response and regulator turnaround time:
During a suspected unauthorized transfer, engineers must rebuild the decision path before they can confirm scope. The same work is required when auditors ask why a transaction was allowed. Containment and reporting slow down because the authorization evaluation was not recorded as a single auditable event.

These risks are already material in traditional banking systems. They affect product velocity, supervisory communication, and incident response. The risk profile changes when transaction volume and decision velocity increase, as is now happening with AI driven systems.

AI-driven actions increase financial and compliance exposure in banks

In 2026, AI agents are increasingly embedded inside core banking systems. If you are responsible for a digital banking platform or a neo bank product, AI agents are likely already operating within your infrastructure. They initiate payment instructions and access customer data through internal workflows. Execution happens through internal APIs and service accounts, often under delegated authority from bank employees or customer-initiated actions.

Agentic AI does not introduce a new control category. It accelerates and scales the permission management weaknesses already present in core banking systems.

Let’s talk about key risk areas you should consider now:

Agent-initiated transactions

When an AI agent initiates a funds transfer, it does so through the same core banking services used by applications and staff. That creates the possibility of transactions exceeding approved thresholds or bypassing required approval hierarchies. In a banking environment, this directly affects financial exposure.

The weakness is architectural rather than behavioral. Once an agent can orchestrate multiple API calls in sequence, it inherits the least restrictive control in that path. A single overbroad permission can expand impact across payments, account balances, and customer financial records.

Expanded non-human access

Core banking platforms already rely on service accounts for many tasks, such as batch processing, reconciliation jobs, fraud engines, or external integrations. The introduction of agentic AI increases the number of non-human identities interacting with transaction systems and customer data.

Each identity becomes another entry point into flows subject to AML controls, KYC enforcement, and transaction monitoring. The attack surface grows because access paths multiply. In that context, Zero Trust does not differentiate between human users, service accounts, or AI agents. Each request must be evaluated at runtime against identity, action, resource, and context. If machine identities are over-privileged or bypass contextual checks, they become high-probability breach vectors.

In late 2025, a breach involving 700Credit exposed credit card details and personal financial data for more than 5.6 million people after an API integration was left improperly secured. The exposed integration was designed for system-to-system data exchange, not direct human access. Attackers exploited a vulnerability in the API validation layer, and an integration partner had access that was not properly scoped or monitored. Once that machine access path was open, sensitive financial records were retrievable at scale. That is where the real risk sits.

Without fine grained and contextual authorization, machine permissions apply uniformly, regardless of transaction value, risk score, or account sensitivity. That is where huge risk sits.

Accountability under audit

The reconstruction problem described earlier becomes more severe when agents execute thousands of decisions per hour.

Banking regulators require traceability for every material financial action. The FFIEC's Authentication and Access to Financial Institution Services and Systems guidance, alongside the IT Examination Handbook flag missing audit trails and undocumented access controls as material deficiencies during examinations.

With AI agents and NHIs, banking compliance becomes even more complicated. When an AI agent executes a transaction on behalf of a customer or employee, the bank must attribute that action to a specific identity and a specific authorization policy version. Standard API logs are insufficient if they do not capture the policy decision that allowed the action.

• AI systems increase transaction velocity and decision volume inside payment and lending workflows.
• Regulatory expectations around segregation of duties, approval limits, and auditability remain unchanged.

Each payment, limit adjustment, or data access event must be explainable in terms of identity, action, resource, and evaluated policy. If that linkage cannot be reconstructed during an internal or external audit, the bank cannot demonstrate effective control over its permission management model.

If you want a deeper breakdown of compliance requirements for non-human identities and agents, I’ve written a detailed guide on that topic.

How big is the risk, really

These risks are easy to treat as edge cases until you see the numbers. Finance accounts for 27% of all data breaches globally, with an average incident cost of $5.9 million. SecurityScorecard found 41.8% of those breaches originated through third-party vendors. Every AI agent added to a banking platform is another non-human identity, another access path, and another point of exposure that needs to be governed.

In the next chapter, I will move from risks to security strategies. I will break down the four architectural pillars required to make permission management defensible in a regulated banking environment. My following article will apply those architectural pillars to a practical implementation approach using Cerbos.