Autonomous software agents are moving from demonstration environments into workflows that can search systems, generate decisions, call APIs and trigger actions. For banks, that changes the security problem fundamentally. Traditional controls were built around humans, devices and relatively predictable applications. An AI agent can instead make a chain of decisions at machine speed, interact with several systems in one task and alter its next action based on what it discovers. The result is not simply another application to secure. It is a new class of digital actor.
That distinction matters because banking systems are permission-rich environments. An agent that can query customer information, prepare a payment, change an account record or interact with a fraud platform may cross several control boundaries in seconds. As autonomy rises, security therefore has to move from “is this user authenticated?” toward “what is this agent allowed to do, on whose authority, under what conditions, with what evidence, and how quickly can it be stopped?”
The security perimeter is becoming an authority perimeter
The conventional enterprise perimeter has already weakened under cloud computing, APIs and distributed services. Zero-trust architecture responds by removing implicit trust based on network location and by requiring authentication and authorization around users, devices, services and resources. NIST’s cloud-native zero-trust guidance goes further by emphasizing application and service identities as a basis for granular policy enforcement. That principle becomes especially important when software agents are able to act on behalf of people or systems. NIST SP 800-207A
An autonomous agent may be created for a specific task, exist only briefly, invoke other agents and then disappear. It may also inherit authority from a human user while operating through machine credentials. That creates a security model based less on static identity and more on delegated authority: who created the agent, what task was approved, which resources it can reach, what actions are prohibited, and when its permissions expire.
Why ordinary IAM can become insufficient
Traditional identity and access management is strong at authenticating employees and assigning roles. It is less naturally suited to software actors whose privileges may need to change within a workflow. An employee in treasury might have broad access because their responsibilities are stable. An AI agent launched to reconcile one payment batch should probably receive a much narrower, time-limited permission set. It may need read access to one ledger, write access to one queue and no authority to initiate external payments.
This is the logic behind workload and service identity in zero-trust systems. The challenge with agentic AI is that the identity must also carry context. A bank may need to know not only which agent is calling an API but the human or process that delegated the task, the model and toolchain being used, the approved objective, the sensitivity of the data involved and the monetary or operational limits attached to the session. The Cloud Security Alliance has argued that agentic systems require identity models that account for autonomy, ephemerality and delegation rather than assuming static application identities. Cloud Security Alliance: Agentic AI IAM
The problem is not only access. It is action.
A chatbot that produces a wrong answer creates an information risk. An agent that can execute a wrong action creates an operational risk. This difference is central to financial services. If an AI system is allowed to submit a trade instruction, move data between systems, create a customer case or request a payment, the bank has to control both the reasoning path and the action path.
That means sensitive actions may need explicit policy gates independent of the model. A model can recommend an action, but a separate control layer can decide whether the action is permitted. High-value transfers may require human approval; unusual changes to customer data may need step-up authentication; access to sensitive datasets may be limited by purpose and geography; and some tools may be available only in read-only mode. The security architecture must assume that a model can make a plausible but unsafe choice, and prevent that choice from automatically becoming an irreversible transaction.
Banks need controls that operate at machine speed
The volume and speed of agent activity make manual oversight alone unrealistic. An autonomous workflow can generate many API calls, create sub-tasks and retrieve information across multiple systems before a human operator could review the first step. Banks therefore need runtime controls capable of evaluating policy continuously, not only at login.
Useful controls include short-lived credentials, least-privilege tokens, transaction limits, tool allow-lists, contextual authorization, rate limits, anomaly detection, immutable activity logs and an immediate kill mechanism. In practice, the agent should be treated more like a privileged workload than a digital employee. It should receive only the authority required for the current objective, and that authority should be revoked automatically when the task ends.
Prompt injection becomes a control-system problem
Agentic systems also expand the consequences of prompt injection and untrusted content. A conventional generative model may be manipulated into producing misleading text. An agent that consumes email, documents or web content may be manipulated into calling a tool, disclosing information or altering a workflow. The attack path can therefore cross from content into execution.
OWASP’s Agentic Security Initiative focuses specifically on risks in autonomous, multi-step AI workflows. For banks, the practical lesson is that content should never be allowed to redefine authority. An instruction discovered in a document should not grant new permissions. Tool access, transaction rights and data privileges should be enforced outside the language model through deterministic policy and security controls. OWASP Agentic AI Security Initiative
Supervisors are already treating AI as an operational-resilience issue
This architectural debate is becoming a supervisory one. The European Banking Authority’s June 2026 risk assessment says digitalisation and rapidly increasing AI capabilities are major drivers of operational risk, alongside cyber risk, data security and dependence on third-party ICT providers. The EBA also says banks should integrate AI tools into their DORA compliance frameworks and use enhanced governance, cybersecurity and regular penetration testing. EBA Risk Assessment Report, June 2026
On 31 July 2026, the EBA, EIOPA and ESMA called for stronger governance and a consistent risk-based supervisory approach to ICT risks from frontier AI models. Their emphasis on prevention, detection, management and operational resilience is directly relevant to autonomous agents because more capable models increase both defensive opportunities and the speed at which errors or malicious actions can propagate. European Supervisory Authorities statement on frontier AI
The ECB has made the same point from a cyber perspective. In June 2026, it warned that advanced AI models are increasing the speed, scale and accessibility of sophisticated cyber capabilities and reducing the time available for defenders to respond. That environment strengthens the case for automated containment controls, clear management ownership and agent-level observability. ECB, June 2026 cybersecurity remarks
Third-party agents create a supply-chain problem
Many banks will not build every agent, model or orchestration layer themselves. Agents may depend on cloud platforms, external models, specialist data providers and third-party tools. Each dependency creates another point where permissions, data and execution can cross institutional boundaries.
DORA already gives financial institutions a framework for ICT third-party risk. Its technical standards require firms to retain control over operational risk, information security and business continuity across critical ICT arrangements, including subcontracting chains. Agentic systems make this requirement more demanding because the effective supply chain may be assembled dynamically at runtime. Banks may need to know which model, tool, API and data source participated in a decision after the event, not simply which vendor held the master contract. EBA DORA RTS on ICT third-party services
Observability becomes as important as authentication
A secure agent environment must make actions reconstructable. Banks need to answer basic forensic questions: which agent acted, what objective it was given, what data it accessed, which tools it called, what permissions were in force, what output was produced, what transaction followed and which human or system ultimately owned the decision.
That implies more than a conventional application log. Agent telemetry may need to connect identity events, model calls, tool invocations, policy decisions and business transactions into one trace. Where possible, security teams should distinguish between model-generated intent and externally enforced execution. This creates evidence for incident response, internal audit, model-risk review and regulatory scrutiny.
The new model should separate intelligence from authority
A useful design principle is to assume that intelligence and authority should not live in the same component. The AI model may decide what it wants to do, but a separate control layer should decide what it is allowed to do. This preserves a security boundary even when model behaviour is probabilistic or unexpectedly adaptive.
NIST’s AI Risk Management Framework and its generative-AI profile emphasize lifecycle risk management, testing, evaluation and governance. In April 2026, NIST also began work on a critical-infrastructure AI profile intended to provide more confidence for deploying AI agents and tools in high-stakes environments. Financial services are not identical to critical infrastructure in every jurisdiction, but the architectural lesson is highly transferable: more capable agents require stronger, repeatable controls across development, deployment and operation. NIST AI Risk Management Framework NIST Critical Infrastructure AI Profile concept note
Human oversight still matters, but it must be placed carefully
It is tempting to solve agent risk by requiring a person to approve everything. That can work for a small number of high-impact decisions, but it defeats the purpose of autonomy if every ordinary step requires manual intervention. It can also create automation bias, where reviewers routinely approve machine recommendations because the volume is too high to investigate.
A more practical model is risk-tiered autonomy. Low-risk, reversible actions can be automated within narrow permissions. Higher-risk actions can trigger stronger authentication, additional controls or human approval. The highest-risk activities may remain outside the agent boundary entirely. Banks already use this logic in fraud controls, payment authorization and privileged-access management; agentic AI requires extending it to machine decision-makers.
Why this becomes a board-level issue
Autonomous agents change accountability as much as cybersecurity. When a system can take action, institutions need clear ownership for its mandate, its permissions and its failures. Security teams cannot define those boundaries alone. Business owners must decide what authority is appropriate, risk teams must define tolerances, compliance teams must interpret regulatory obligations, technology teams must enforce the controls and internal audit must be able to test whether the design works in practice.
The first annual DORA overview of major ICT incidents, published in June 2026, described ICT risks as increasingly borderless and interconnected and highlighted the need to strengthen cyber resilience as highly capable AI tools evolve. Autonomous agents fit directly into that picture because a poorly governed agent can connect multiple systems and dependencies that were previously evaluated separately. ESAs first DORA major-incident report
A new security model is likely to look less like a firewall and more like a control plane
The emerging model for agent security is likely to combine machine identity, zero trust, policy enforcement, transaction controls, model governance and continuous monitoring. It will need to verify not only who or what is acting but why, under whose authority and within which limits. Credentials should be short-lived. Permissions should be purpose-specific. Sensitive actions should be independently gated. Every significant step should be traceable. And the institution should be able to revoke an agent’s authority immediately without waiting for the model to cooperate.
This does not mean autonomous agents are inherently unsafe. In some cases they may ultimately improve security by applying controls more consistently than humans and by detecting anomalous activity faster. But the benefits depend on architecture. Giving a probabilistic system broad, persistent access and then relying on post-event monitoring would reproduce many of the weaknesses banks have spent years trying to remove from privileged human accounts.
Conclusion
The security challenge created by autonomous software agents is not that machines are becoming more intelligent. It is that they are becoming more capable of acting. Banking cybersecurity has historically concentrated on protecting accounts, endpoints, networks and applications. Agentic AI adds another object to secure: delegated machine authority.
Banks that treat agents as ordinary applications may discover that existing controls do not capture the speed, context switching and dynamic delegation involved. Banks that treat them as privileged, observable and tightly governed digital actors will be better positioned to use autonomy without surrendering control. The next generation of financial security architecture may therefore be defined less by where systems sit and more by how precisely institutions can govern what every machine is permitted to do.
References
1. NIST – SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications
2. NIST – AI Risk Management Framework
3. NIST – Concept Note: AI RMF Profile on Trustworthy AI in Critical Infrastructure
4. European Banking Authority – Risk Assessment Report, June 2026
5. EBA, EIOPA and ESMA – Statement on ICT Risks from Frontier AI Models, 31 July 2026
6. European Supervisory Authorities – First Report on DORA Major ICT-Related Incidents, 3 June 2026
7. European Banking Authority – DORA RTS on ICT Services Supporting Critical or Important Functions
8. European Central Bank – Fireside Chat on Frontier AI and Cyber Resilience, 19 June 2026
9. OWASP – Agentic AI Security Initiative
10. Cloud Security Alliance – Agentic AI Identity and Access Management: A New Approach