AI Agent Security in Financial Services: A Fintech Case

In January 2026, attackers compromised a handful of executive devices at Step Finance, a Solana-based DeFi portfolio manager. The device compromise itself was routine. What turned it into a $27 to $30 million loss, and into one of 2026's clearest AI agent security failures, was what came next: the firm's AI trading agents had standing permission to move large token balances without a human confirming the transfer. Once the attackers had a foothold, the agents did exactly what they were built to do. They moved 261,000 SOL tokens out of the fund. Only $4.7 million was ever recovered. The native token crashed 97%, and Step Finance shut down. (Source: Beam AI's 2026 agent security breach analysis)

Nobody hacked the model. Nobody found a clever prompt injection or a zero-day. The agents worked correctly on a task they were never supposed to be able to do at that scale, because nothing in the system's architecture said they couldn't. That gap is what AI agent security in financial services actually has to close, and the data below suggests it is a common one.

TL;DR

AI agents are already moving money inside production fintech systems, and the standard fix, policy documents and human review steps, has not kept pace with how fast those agents are being granted account access. Scala's type system offers a different kind of control: a function's signature can declare exactly which capabilities it is allowed to touch, so an agent that was never given authority to transfer funds cannot be coerced into calling code that does, regardless of what an attacker gets it to believe. Financial regulators have not written a rulebook for this yet, which makes the architectural choice the responsible party's own decision to get right, not something a future compliance checklist will hand them.

What Went Wrong at Step Finance

The failure sequence at Step Finance is worth walking through because it is the same sequence security researchers keep finding across fintech and DeFi incidents. An agent is granted broad standing access, usually because it is faster to build that way and nobody revisits the scope once the integration works. A credential or device is compromised, through phishing, malware, or a supply chain attack. Once inside, the attacker does not need to defeat the AI model at all. They only need to direct an agent that already has the permission to do the damage.

Compare that to what happens when the same compromise occurs against an agent whose authority is scoped and enforced by the type system rather than by a policy document. The agent might still be tricked. The credential might still be compromised. But if the code path for moving funds was never exposed to that agent's function signature in the first place, there is no call for an attacker to direct it toward. The unauthorized transfer does not get blocked at runtime by a monitoring system that might miss it. It fails to compile.

That distinction, runtime detection versus compile-time impossibility, is the entire argument for treating capability scope as an engineering decision rather than a governance one. A policy document says an agent should not move funds outside approved thresholds. A type signature that never grants access to the transfer function makes that constraint true whether or not anyone remembers to check.

Why AI Agent Permissions Are Becoming a Fintech Board Issue

Step Finance is not an outlier. Across industries, 88% of organizations running AI agents reported a confirmed or suspected security incident in the past year, while only 6% of security budgets are allocated to AI agent security specifically. (Beam AI, 2026) That gap between how fast agents are being deployed and how little is spent containing them is where incidents like Step Finance come from.

Industry-wide data backs this up with more granularity. According to the Kiteworks 2026 Data Security and Compliance Risk Forecast, 65% of firms experienced an AI agent security incident in 2026, and 35% of those incidents produced direct financial losses. The report traces this back to two specific control gaps rather than abstract capability shortfalls. 63% of organizations cannot enforce purpose limitations on an agent, meaning an agent granted access for one task has no technical barrier stopping it from reaching adjacent systems it was never meant to touch. 60% cannot terminate a misbehaving agent once it starts acting outside its intended scope. Monitoring catches the behavior. Almost nothing in most environments can stop it.

For a fintech board, that reframes the AI agent conversation. The question is no longer whether agents will touch money movement, settlement, or account data. Most fintechs are already past that point. The real question is what happens the moment one of those agents is compromised, tricked, or simply given a task it interprets more broadly than intended, and the purpose-binding and containment gaps cited above suggest the answer is rarely a novel attack. It is usually the permission that was already sitting there.

International regulators are reaching a similar conclusion from a different angle. The Financial Stability Board's June 2026 consultation on responsible AI adoption accepts that continuous human review of individual agent decisions is already becoming impractical at the scale institutions are deploying agents, and it recommends supplementing human oversight with AI systems that monitor other AI systems. That is a notable admission from a body coordinating financial regulators across the G20. If the people writing the rules are conceding that a human cannot watch every agent decision in real time, the case for building limits into the agent's architecture, rather than relying entirely on someone noticing a bad decision after it happens, gets considerably stronger.

Why Regulators Have Not Closed This Gap Yet

No regulatory framework currently tells fintechs how much autonomy an AI agent is allowed to have inside a production financial system. In April 2026, the Federal Reserve, OCC, and FDIC issued revised model risk management guidance, OCC Bulletin 2026-13, designated SR 26-2, replacing the long-standing SR 11-7. The revised guidance explicitly excludes generative and agentic AI from the formal definition of a model, describing them as novel and rapidly evolving, and narrows the framework's core focus to banking organizations with more than $30 billion in total assets. Even where the guidance does apply, it is principles-based, and a bank departing from it does not automatically trigger supervisory criticism.

That guidance does not say agentic AI is safe or unsupervised. It says the primary US bank supervisory framework for model governance has not caught up to autonomous agents that are already operating inside consumer-facing financial systems, and even the one category of institution it does address is not bound to follow it strictly.

FINRA is pulling in the opposite direction. Its 2026 Annual Regulatory Oversight Report expanded its section on generative AI and, for the first time, addressed AI agents directly, agents it characterizes as software that can act on a user's behalf across multiple steps without direct instruction at each one. The report directs member firms to evaluate whether an agent's autonomy creates novel supervisory obligations. Its own guidance to firms includes implementing guardrails to constrain or restrict AI agent behaviors, actions, or decisions, tracking and logging what agents actually do, and defining where a human needs to stay in the loop. FINRA is telling firms to build the guardrails. It is not telling them how.

That combination, one regulator stepping back from formal validation and another raising the bar on governance with no prescribed mechanism, means the responsibility for how an agent's authority is scoped sits with the engineering team building the system, not with a checklist that hasn't been written yet. For any fintech below the $30 billion threshold, there was never a formal framework to lean on in the first place.

Why Compile-Time Guarantees Beat Runtime Monitoring for Agent Authority

Scala's answer to this problem is not a new idea bolted onto AI governance. It is a pattern already used in production Scala systems for reasons that have nothing to do with AI agents, and it happens to map directly onto the fintech problem. Libraries like ZIO model the resources a piece of code is allowed to touch as a type parameter, often called the environment. A function's signature has to declare every capability it needs before it can compile, and nothing outside that declared set is reachable from inside the function body.

Applied to an AI agent's task execution, the pattern looks like this:

scala

// The agent's task can only touch what its type declares
trait ReceiptConfirmation:
  def confirm(orderId: String): IO[ConfirmError, Unit]
 
def runAgentTask(orderId: String): ZIO[ReceiptConfirmation, ConfirmError, Unit] =
  for
    svc <- ZIO.service[ReceiptConfirmation]
    _   <- svc.confirm(orderId)
  yield ()
  

The function's type signature is ZIO[ReceiptConfirmation, ConfirmError, Unit]. There is no path in that signature to a payment transfer, a balance withdrawal, or an account modification. If a prompt injection or a compromised credential convinces the agent to attempt one anyway, the call has nowhere to go, because the code that would perform a transfer was never wired into this function's environment. The compiler rejects the attempt before the code ships, not after an attacker finds it in production.

Why This Differs From IAM and Role-Based Access Control

This is a different guarantee than the access control lists and IAM roles most fintechs already have in place. A role-based permission system decides what an account or service is allowed to do at the infrastructure layer, and it has to be checked at run time, which means there is always a window where a misconfigured role or an over-broad grant sits live in production until someone audits it. Type-level capability scoping moves that check earlier. If the transfer function was never wired into the agent's declared environment, there is no configuration to misconfigure. The absence is structural, not procedural. At Step Finance, the permission existed, was technically correct according to the access policy in place, and still produced the loss.

Where Capture Checking Fits

Scala's newer, still-experimental capture checking feature pushes the same underlying idea further, at the language level rather than the library level. It can flag, at compile time, code where a tracked capability is used somewhere it was never authorized to persist, the same shape of failure behind Step Finance, generalized to any resource a program touches, not just payments. Capture checking is explicitly documented as experimental and evolving quickly, so it is not the mechanism a fintech should point to today. It is a sign of where the language is investing, and it is worth watching for teams thinking several years ahead about how far compile-time enforcement can reach. For readers who want the deeper technical mechanics of scoping what code is allowed to touch, our Learning Scala breakdown of capability surfaces in agentic commerce works through the pattern in more depth.

What This Means for Engineering Leaders Evaluating AI Agent Architecture

Most fintech engineering leaders are not deciding whether to use AI agents. That decision is already made across the industry. The decision still open is how much authority each agent gets, and whether that authority is enforced somewhere an attacker or a bad prompt cannot argue its way around.

• Audit standing permissions before adding new agent capability. Step Finance's agents had broad transfer authority long before the compromise happened. The permission scope was the pre-existing condition, not the attack.
• Ask whether authority is enforced at compile time or only at runtime. A monitoring dashboard tells you an agent did something wrong after the fact. A type signature that never grants the capability prevents the call from existing at all.
• Treat capability scoping as an architecture requirement, not a policy document. FINRA's guidance to build guardrails is a mandate without a mechanism. That mechanism is a decision your engineering team makes as part of your broader compliance infrastructure, and it can be made well before an examiner asks about it.
• Scope each agent to the narrowest task it actually performs. An agent built to confirm receipts does not need a code path that can also move funds, even if it would be more convenient to build it that way.

None of this requires waiting for regulators to finish deciding how agentic AI fits into existing frameworks. It requires deciding, now, how much of your production financial system an AI agent is allowed to reach if something goes wrong, and building the system so that answer is enforced rather than assumed. Our broader look at Scala's fit for fintech engineering covers the wider case for type-driven correctness in financial systems, and our piece on Scala for AI-assisted development looks at how the same type-system discipline applies when AI is writing the code itself, not just executing it.

Not sure how exposed your current agent architecture actually is?

A short conversation can surface where your AI agents have more standing authority than the task requires. Talk to a Scala expert.

Frequently Asked Questions

What is AI agent security in financial services?

AI agent security in financial services refers to the controls that limit what an autonomous AI system can do inside production banking, trading, or payment infrastructure, particularly what it can access, modify, or transfer without direct human approval. It covers both governance controls, such as monitoring and audit logs, and architectural controls, such as restricting which functions an agent's code is permitted to call.

Why did AI trading agents cause the Step Finance losses in 2026?

Step Finance's AI trading agents had standing permission to execute large token transfers without human confirmation. When attackers compromised executive devices, they did not need to defeat the AI model itself. They directed agents that already had the authority to move funds, resulting in a loss of $27 to 30 million.

Have US bank regulators issued rules for agentic AI?

Not formally. In April 2026, the Federal Reserve, OCC, and FDIC issued SR 26-2, which explicitly excludes generative and agentic AI from formal model risk management scope and focuses primarily on institutions with more than $30 billion in assets. FINRA has taken a different approach, introducing guidance on AI agents in its 2026 Annual Regulatory Oversight Report without prescribing a specific technical standard.

Can Scala's type system prevent an AI agent from making unauthorized transactions?

Scala's type system can prevent an agent's code from calling a function it was never granted access to in the first place. Libraries such as ZIO model required capabilities as part of a function's type, so a task scoped to one capability, such as confirming a receipt, has no compile-time path to a different capability, such as transferring funds, even if the agent is compromised or manipulated.

Is Scala's capture checking feature ready for production use in fintech systems?

No. Capture checking is documented as highly experimental and still evolving quickly. It is a useful signal of where Scala's type system is heading for tracking capability lifetimes at the language level, but production capability restriction today is better served by established, stable patterns such as ZIO's environment type.

What should engineering leaders ask AI vendors about agent permissions?

Ask whether an agent's authority is enforced at compile time, through the type system or a similar mechanism, or only through runtime monitoring and policy documents. Ask how narrowly each agent's capabilities are scoped to its actual task, and whether a compromised agent could reach systems beyond the one it was built to perform.