AI agents in banking need runtime controls beyond AppSec

At a glance

What this is: This is an analysis of why banking AI agents outgrow traditional AppSec and what new control patterns are needed to manage agentic workflows safely.

Why it matters: It matters to IAM and security teams because AI agents can act with account-level access, creating governance, authorisation, and audit problems that look more like identity failures than classic application bugs.

By the numbers:

• Over 85% of financial firms are actively applying AI in areas such as fraud detection, IT operations, digital marketing, and advanced risk modeling.
• Over 90% of US banks now use AI for fraud detection, and AI agents are processing customer transactions, underwriting loans, and handling compliance workflows in production.
• ~200ms latency

👉 Read Straikerai's analysis of AI agent security in banking and financial services

Context

Banking teams are moving AI into production faster than their controls are evolving, and the key gap is governance rather than model quality. When an AI agent can query balances, process refunds, or support compliance workflows, the risk is no longer just unsafe output. It is unauthorised action, weak authorisation boundaries, and limited auditability. That makes AI security a control problem with a direct identity dimension, especially where agent permissions overlap with customer accounts and financial workflows.

The article argues that DIY guardrails, open-source filters, and cloud-native safety features are not enough for financial services because they focus on inputs and outputs, not the full agentic trace. For IAM and PAM teams, that matters because the control question shifts from whether a model is accurate to whether an agent is allowed to do anything at all, with which credentials, under what policy, and with what evidence for review.

Key questions

Q: How should security teams govern AI-enabled workflows that can act on their own?

A: Treat them as identity-governed execution paths, not just software features. Assign a named owner, define least-privilege access, log every tool call, and require revocation paths for credentials and tokens. If the workflow can touch production systems or sensitive data, its permissions must be reviewed with the same discipline used for privileged machine identities.

Q: Why do AI agents create new access risk for enterprises?

A: AI agents create access risk because they can operate with delegated authority while processing untrusted inputs. If prompts, tools, or permissions are abused, the agent may expose data or trigger actions faster than a human reviewer can intervene. The risk is not only compromise, but overreach built into the design.

Q: What do banks get wrong about AI guardrails and compliance?

A: They often focus on filtering prompts and outputs while missing the intermediate steps where agents choose tools, fetch data, and act on it. Compliance failures usually happen in that hidden execution path. If you cannot observe and audit the agent trace, you cannot prove the agent stayed within policy or explain what happened after an incident.

Q: How can financial services teams reduce excessive agency in AI agents?

A: Use least privilege for tools, separate approval paths for sensitive actions, and require policy checks before the agent can complete high-impact steps. Excessive agency falls when the system cannot freely turn a user request into a business action without control gates. The goal is bounded autonomy, not unrestricted helpfulness.

Technical breakdown

Why traditional AppSec misses agentic workflows

Traditional AppSec assumes a request comes in, gets validated, and produces a response. AI agents break that model because they can chain tool calls, retrieve data, make intermediate decisions, and act across multiple systems before returning a result. The real security boundary is no longer the prompt or the output alone. It is the full execution path, including reasoning, tool selection, parameter use, and data retrieval. If controls only inspect inputs and outputs, they miss the decision points where policy violations occur.

Practical implication: monitor the complete agent trace, not just prompt and response events.

Tool misuse and excessive agency in AI agents

Tool misuse happens when an agent can perform actions that exceed the business intent of the workflow, such as issuing refunds above the approved amount or accessing records for the wrong user. Excessive agency is broader. It is the tendency for the agent to optimise for the user request while bypassing policy boundaries. In banking, that creates a governance problem because the agent may appear helpful while still violating authorisation scope, separation of duties, or customer-data boundaries.

Practical implication: bind every tool to explicit policy checks and scoped permissions.

Why prompt injection becomes an identity problem

Indirect prompt injection can hide malicious instructions inside documents, messages, or retrieved content, then influence how the agent behaves at runtime. In regulated environments, that becomes an identity and trust issue because the agent may treat untrusted content as if it were authorised instruction. If the agent also has access to accounts or compliance systems, a successful injection can turn a content problem into an access problem. That is why runtime validation and boundary enforcement matter.

Practical implication: separate untrusted content from trusted instructions and validate tool use at runtime.

NHI Mgmt Group analysis

AI agents in banking create an authorisation problem, not just an accuracy problem. The article shows that once agents can move from analysis to action, the security question changes from whether the model is correct to whether it is permitted to act. That is a governance shift that traditional AppSec rarely handles well. Banking teams need policy controls that understand context, task scope, and permissible outcomes, otherwise the agent becomes a privileged workflow actor with weak constraints.

Agentic trace visibility is the named concept this market still underestimates. A control stack that only sees inputs and outputs cannot explain tool choice, intermediate reasoning, or hidden decision paths. That leaves a compliance blind spot when agents touch transactions, refunds, or customer data. For identity and access programmes, the practical lesson is that audit evidence must cover the action chain, not just the final response.

In financial services, excessive agency is a delegated privilege failure disguised as AI behaviour. When an agent acts outside its intended scope, the issue is usually not intelligence, but delegated access without enough policy constraint. That means banking controls should be evaluated the same way teams evaluate privileged workflows: scope, approval, traceability, and revocation. The practitioner takeaway is to govern the agent as a controlled identity with bounded authority.

Cloud-native safety features are necessary but not sufficient because they do not solve cross-environment governance. The article highlights the friction of multi-cloud and hybrid banking estates, where consistent policy and visibility are hard to maintain. That pushes security design toward standardised runtime controls and centralised policy intent. Practitioners should treat agent security as an enterprise control plane problem, not a provider feature checklist.

OWASP-style agentic risk models now fit banking AI better than legacy model-risk assumptions. This is not a statistical model problem alone, because the threats include tool misuse, prompt injection, and data exposure across workflows. Banking and insurance teams should map these risks to runtime controls, logging, and accountability instead of relying only on pre-deployment review. The category is maturing from model assurance to operational authorisation governance.

What this signals

AI agent governance is moving toward runtime control rather than pre-deployment review, because static approvals cannot keep pace with tool-using systems that make decisions in motion. For banking programmes, the near-term signal is that authorisation, observability, and auditability need to be designed together, not bolted on after model rollout. The most useful control question is no longer whether the agent can answer correctly, but whether it can act within a bounded permission set and leave evidence behind.

Agentic authorisation drift: when an AI system inherits broader access than the task requires, and policy cannot reliably constrain what happens at runtime. That drift becomes visible in refunds, account access, and compliance workflows where intent, access, and execution are no longer aligned. Banks should expect internal control owners to ask for trace-level evidence and clearer ownership of agent permissions.

The next maturity step is to align AI agent controls with IAM and PAM language. That includes ownership, scoped entitlement, revocation, exception handling, and periodic review. When identity teams become part of the AI operating model, the organisation is better positioned to distinguish safe delegation from risky automation.

For practitioners

• Define explicit agent authorisation boundaries Document which systems each agent may access, which actions are allowed, and where human approval is mandatory. Treat refunds, account access, underwriting changes, and compliance decisions as separate authority scopes, then test whether the agent can exceed them through normal workflow execution. The boundary definition should be reviewed alongside the business process, not just the model.
• Instrument full agent-trace monitoring Collect every tool call, parameter, retrieval event, and downstream action so you can reconstruct the complete agentic trace after an incident. This gives security, compliance, and audit teams evidence for policy violations, data exposure, and unauthorised transactions. Without that trace, investigations stop at the prompt and miss the real failure path.
• Separate untrusted content from trusted instructions Apply runtime controls that distinguish retrieved documents, user inputs, and policy instructions before the agent acts on them. That reduces indirect prompt injection risk and prevents the model from treating hostile content as authorised workflow guidance. In practice, this means enforcing content provenance and validating every tool request before execution.
• Map AI agent controls to IAM and PAM review cycles Add agent permissions, access scopes, and revocation criteria to existing identity review processes so the security model covers delegated machine action as well as human access. Where agents can touch accounts or transactions, review them like privileged identities with clear owners, expiry rules, and exception handling.

Key takeaways

• AI agents in banking create a governance problem because they can move from analysis to action inside regulated workflows.
• The strongest evidence of risk is not model error alone, but the hidden execution chain that current AppSec tools cannot observe well.
• Banks should govern agents as bounded identities, with explicit scope, runtime policy checks, and full traceability for every sensitive action.

Key terms

• Agentic trace: The complete sequence of actions an AI agent takes while completing a task, including tool calls, intermediate decisions, data retrieval, and final output. It matters because security failures often occur between the prompt and the response, where the agent can exceed its intended authority without being visible in simple logs.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
• Tool Misuse: Tool misuse occurs when an agent uses an allowed integration in a way that exceeds its intended task, scope, or risk tolerance. The problem is often not access alone but the combination of valid credentials, broad permissions, and unbounded action sequencing.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

What's in the full article

Straikerai's full article covers the operational detail this post intentionally leaves for the source:

• How the vendor recommends instrumenting full agent traces across SDK, gateway, and sensor-based deployment patterns
• What its runtime validation approach looks like for tool authorisation, boundary detection, and agent boundary enforcement
• Examples of its detection categories for prompt injection, PII leakage, tool misuse, and excessive agency
• How the article frames staged adoption from observability to protection to AgentSecOps workflows

👉 Straikerai's full post covers the control gaps, agent trace visibility, and deployment options in more detail

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for teams that need a common operating model for access, lifecycle, and governance across machine and human identity.