Financial cybersecurity has traditionally been designed around a simple question: should this user, device or application be allowed to access this resource? Autonomous software agents make that question harder. A machine may now authenticate itself, call another service, create a sub-agent, request a new credential, initiate a payment workflow or approve a downstream action without a person present at every step.
That changes the security problem from machine authentication to machine authority. The danger is not merely that an agent could be impersonated. It is that a legitimate agent could acquire, delegate or exercise permissions in ways that exceed the purpose for which it was created. In a financial institution, where software can touch customer data, payment rails, trading systems, treasury processes and compliance controls, that distinction is material.
The next generation of cybersecurity therefore needs to answer four questions continuously: which machine is acting, what authority was delegated to it, what conditions constrain that authority, and which system independently decides whether the requested action is permitted.
Cybersecurity is moving from identity to authority
Zero-trust architecture already provides part of the answer. NIST SP 800-207 rejects implicit trust based on network location and requires authentication and authorization before access to enterprise resources is established. Its cloud-native extension, NIST SP 800-207A, goes further by emphasizing application and service identities rather than relying only on user identities and network parameters.
Autonomous agents introduce an additional layer. A service identity can tell a bank what software component is making a request. It does not automatically tell the bank whether that component is acting for the right customer, under the right mandate, for the right business purpose, within the correct risk limit and during the correct time window. Authority becomes contextual, temporary and potentially transferable.
A useful analogy is corporate signing authority. Knowing that an employee is genuine does not mean the employee can sign every contract or move any amount of money. The same principle should apply to machine actors. Authentication proves identity; authorization should prove that the proposed action falls inside a specific mandate.
Delegation creates a new attack surface
In January 2026, NIST's Center for AI Standards and Innovation opened a request for information specifically on securing AI agent systems. NIST noted that these systems can plan and take autonomous actions that affect real-world systems and that combining model outputs with software functionality creates distinct security risks.
One of those risks is delegated execution. An agent may be authorized to research an account and prepare a transaction, then call another agent or service to complete part of the task. If the second component receives a broad credential instead of a narrowly scoped capability, authority can expand as the workflow progresses. What began as a read-only task can become a write action, a payment instruction or a change to a customer record.
This matters because agentic workflows are not always static. The sequence of tools used may change according to context, model output or intermediate results. Traditional access models built around long-lived roles can struggle when permissions need to be created, narrowed and revoked in seconds.
The dangerous combination: machine speed and permission inheritance
Human authorization processes are usually slowed by friction: authentication prompts, approval queues, segregation of duties and review. Machine-to-machine workflows can remove that friction. That is their commercial appeal, but it also means a permission error can propagate faster than a human team can notice it.
Consider an autonomous treasury agent that monitors liquidity and is permitted to recommend transfers between internal accounts. If it can delegate execution to a payment agent, and that payment agent can request credentials from an identity service, the control question is no longer confined to one application. The bank must preserve the original mandate across the entire chain. The downstream system should know the amount ceiling, approved accounts, purpose, customer or entity context, expiry time and whether human confirmation is required.
Without that continuity, authorization can become a game of broken telephone: each machine sees only the permission handed to it, while the original business intent disappears.
Policy engines need to sit outside the agents
NIST's practical zero-trust architecture work separates the decision to grant access from the component requesting it. Its zero-trust implementation guidance describes policy engines, policy administrators and policy enforcement points that evaluate and enforce access independently. That separation is particularly useful for agentic systems.
A bank should not rely on an AI agent to decide the limits of its own authority. The model may decide what action appears useful; a separate deterministic control layer should decide whether that action is allowed. This reduces the risk that prompt injection, model error or compromised context turns a recommendation into an unauthorized transaction.
The control layer can enforce conditions the model cannot override: maximum transaction values, approved counterparties, permitted data domains, geographic restrictions, trading limits, prohibited tools, rate limits, dual approval requirements and mandatory escalation thresholds. In effect, the model proposes; the policy layer disposes.
| Control question | What the bank needs to establish |
| Identity | Which agent, workload or service is making the request? |
| Delegation | Who or what granted the authority, and can it be re-delegated? |
| Scope | Which resources, actions, accounts and tools are permitted? |
| Context | For which customer, legal entity, purpose and transaction is the authority valid? |
| Duration | When does the permission expire or require re-evaluation? |
| Accountability | Can the full chain of decisions, credentials and actions be reconstructed? |
Short-lived authority becomes more important than permanent privilege
Traditional service accounts often accumulate durable privileges because they are difficult to rotate without disrupting applications. Agentic systems make that model increasingly risky. An autonomous agent may exist for minutes, perform one task and disappear. Its authority should be designed the same way.
Short-lived credentials, just-in-time access and task-specific tokens can reduce the blast radius of compromise. Permissions can be bound to a particular transaction, destination or API method rather than granting broad account-level access. A token used to retrieve a balance should not automatically be reusable to move funds, and a credential issued for one customer workflow should not silently cross into another.
This approach is consistent with NIST's zero-trust implementation model, which emphasizes least privilege, just-enough and just-in-time access, along with continuous evaluation rather than one-time trust decisions.
Financial regulation already points toward stronger machine accountability
European financial regulation does not yet provide a dedicated rulebook for autonomous agent authorization, but existing ICT requirements already establish relevant principles. Under DORA, financial entities must maintain a sound ICT risk management framework, limit logical access to legitimate and approved functions, use strong authentication and continuously monitor the security and functioning of ICT systems.
The associated DORA technical standard on ICT risk management requires access rights to be managed on need-to-know, need-to-use and least-privilege principles, calls for user accountability, and requires privileged access to be granted on a need-to-use or ad-hoc basis and logged. Those requirements were written for ICT environments generally, but they map closely to the control problems created by non-human actors.
The practical implication is that agent identity cannot be treated as an engineering detail. If an agent can affect critical or important functions, its permissions, credential lifecycle, logging and accountability should form part of the institution's operational-risk framework.
Supervisors are widening the AI discussion from model risk to ICT risk
On 31 July 2026, the European Banking Authority, EIOPA and ESMA called for enhanced governance and consistent supervision of ICT risks from frontier AI models. The authorities emphasized prevention, detection, risk management and operational resilience, and linked the issue to ongoing DORA oversight of critical ICT third-party providers.
The ECB has made a similar argument. In its June 2026 speech on operational resilience in the age of AI, it reported that more than 85% of significant banks under European banking supervision use AI and warned that frontier models are changing the economics of cyber risk by increasing the speed and accessibility of advanced attack capabilities.
Machine-to-machine authorization sits directly inside this broader resilience challenge. A bank can deploy strong models and still be vulnerable if software actors are over-privileged, difficult to attribute or able to chain actions without independent enforcement.
Prompt injection becomes more dangerous when the victim can grant authority
Agentic AI also changes the consequences of prompt injection. OWASP's 2026 agentic red-teaming landscape highlights prompt injection, agent privilege escalation, model misuse and emergent behaviours among the risks that require lifecycle-wide testing and defensive validation.
If a manipulated agent can only draft text, the damage may be informational. If it can request privileges from another machine, create a downstream task or trigger a payment API, the same manipulation can become an authorization incident. Banks therefore need to treat untrusted model input as incapable of expanding privilege. Content can influence reasoning, but it should not be able to rewrite the security policy that defines what the agent is allowed to do.
This is why permission boundaries should be enforced outside the model and why high-risk functions should use deterministic checks. The agent should not be able to persuade the policy layer that it deserves more authority.
Machine authorization needs an audit trail that preserves causality
Ordinary application logs may show that Service B called API C. That is no longer enough. A bank investigating an agentic workflow may need to reconstruct the full causal chain: the human or system that initiated the task, the original objective, the agent identity, the model and version used, the data retrieved, the tools called, every permission decision, any sub-agents created, the resulting transaction and the policy that approved or denied each step.
This matters for incident response, internal audit, dispute resolution and regulatory review. If two autonomous systems interact and one authorizes the other, accountability cannot end at the final API call. The institution needs evidence of why that authorization existed in the first place.
The Basel Committee's June 2026 report on ICT risk management reinforces the broader prudential importance of operational resilience and effective ICT risk management as banks become increasingly digital and interconnected.
Third-party agents make the trust chain longer
Many financial institutions will use agents assembled from external models, cloud services, orchestration platforms, data providers and specialist tools. That creates a supply-chain problem. A bank may trust its own agent but not have equivalent visibility into every service identity or delegated token used downstream.
The security model therefore needs explicit trust boundaries. External agents should not automatically inherit internal privileges. Third-party tool calls may require separate credentials, narrower scopes and stronger monitoring. The bank also needs a way to revoke authority quickly if a provider, model or integration is compromised.
This extends existing third-party risk management rather than replacing it. The difference is speed: an agent can dynamically select tools and providers during execution, so the institution may need machine-readable policies that evaluate third-party access in real time rather than relying only on periodic due diligence.
Segregation of duties needs a machine-readable form
Financial institutions have long separated high-risk activities between people: one employee prepares a payment, another approves it; one trader executes, another function monitors limits; one administrator requests privileged access, another authorizes it. Autonomous systems should not erase that design principle.
Instead, segregation of duties can be encoded into the control plane. One agent may generate a recommendation, a second deterministic service may validate policy, and a separate execution service may complete the transaction only after the required conditions are satisfied. For the highest-risk actions, a human or independent system can remain the final approver.
The goal is not to recreate bureaucracy in software. It is to prevent a single compromised model or identity from controlling the full chain from intent to authorization to execution.
The future control model will probably be continuous, not binary
Machine authorization is unlikely to remain a simple allow-or-deny event. A more mature design will continuously reassess authority as context changes. The same agent might be allowed to retrieve information, conditionally allowed to prepare an instruction, and prohibited from executing it unless transaction size, counterparty risk, time, device posture and other signals remain inside policy.
Risk-based controls can also reduce unnecessary friction. Low-risk, reversible actions may be automated within narrow boundaries. Irreversible, customer-impacting or high-value actions can trigger additional checks. This creates graded autonomy rather than a false choice between complete automation and constant manual approval.
What changes for security architecture
For banks, the architectural shift can be summarized as a move from identity management toward authority management. Identity remains foundational, but it has to be connected to purpose, provenance, scope, time, risk and transaction context.
The emerging stack is likely to combine workload identity, short-lived credentials, capability-based permissions, policy engines, transaction controls, immutable or tamper-resistant audit records, behavioural monitoring, agent registries and rapid revocation. Crucially, these controls should be able to operate independently of the model that is requesting the action.
That separation is what makes autonomy governable. It allows institutions to benefit from machine speed without allowing machine reasoning to become the sole source of permission.
Conclusion
The next cybersecurity problem in financial services is not simply that machines will talk to machines. They already do. The more consequential shift is that machines will increasingly ask other machines for permission, delegate tasks to them and rely on them to execute actions with financial consequences.
That makes authorization a dynamic chain rather than a static role assignment. Banks will need to know not only whether a machine is genuine, but whether its authority is legitimate, sufficiently narrow, still current and traceable back to an approved purpose.
Institutions that solve this early may be able to deploy autonomous agents more confidently. Those that do not may discover that the fastest-growing security perimeter in the bank is no longer the network edge. It is the invisible web of permissions connecting one machine to another.
References
1. NIST – CAISI Issues Request for Information About Securing AI Agent Systems, 12 January 2026
2. NIST – SP 800-207: Zero Trust Architecture
3. NIST – SP 800-207A: Zero Trust Architecture Model for Access Control in Cloud-Native Applications
4. NIST – SP 1800-35: Implementing a Zero Trust Architecture, June 2025
5. NIST – Zero Trust Architecture Project: Policy Engine, Administrator and Enforcement Point
6. European Union – Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA)
7. European Union – Delegated Regulation (EU) 2024/1774: ICT Risk Management and Access Control
8. EBA, EIOPA and ESMA – Statement on ICT Risks from Frontier AI Models, 31 July 2026
9. European Central Bank – Strengthening Operational Resilience for the Age of AI, 3 June 2026
10. Basel Committee on Banking Supervision – Report on ICT Risk Management, 2 June 2026
11. OWASP GenAI Security Project – AI and Agentic Red Teaming Security Landscape, Q2 2026