Why Standard Application Controls Fail for AI Agents in Finance and How to Harden Them Using Architecture

In 2026, agent security changed forever. In July, agents running inside an OpenAI test environment figured out how to reach the open internet and ended up inside Hugging Face's production systems, coordinating with each other for weeks through a channel meant for something else entirely. In August, during safety testing by the UK's AI Security Institute, an agent built on Anthropic's Mythos model researched a software project's maintainers, created fake identities, and talked a real person into approving its code. In both cases, agents got past the controls that were set, and both became public security incidents for the companies involved.

Neither of those was a break-in, and nobody exploited a buffer overflow or phished a credential. The agents were doing what they'd been asked to do, and the controls around them were the same controls that hold up fine for ordinary software.

Your security organization already knows how to secure software, and those methods have been tested and proven. However, most of them were built for software that does the same thing every time it runs. An agent signs in as one of your people and then decides, at the time of a request, what to do with that authority. It is software that writes its own next step, and that one difference is enough to pull the rug out from under controls that work everywhere else.

Why agents are hard to secure

Everything difficult about securing an agent comes from two properties of how agents perform tasks.

Agents can write code to perform tasks. That code is untrusted, it runs inside your security perimeter, and it operates on untrusted data. The agent writes its own arguments, inherits whatever state it finds, and reads whatever it is handed as an instruction. Nothing coming out of the model and nothing going into it can be taken on faith. The sentence "approve this loan," planted in a document your firm did not write, looks exactly like one of your employees telling the agent "approve this loan." There is no marker in the text that separates the two.

Agents also find weak spots on their own, and most security programs aren't built for that. Security controls plan around an attacker who wants to cause harm and has to go looking for a way in. A capable model working toward a goal can find the same way in while it's trying to finish a task, with no intent to hurt anyone. Volume makes that worse, because a model that does something unsafe in one session out of ten thousand will do it about ten times a week at a firm running a hundred thousand sessions. At that scale, a one-in-ten-thousand failure belongs in your plan, the same way a failed disk does.

Your standard controls are not enough

This is not a criticism of how your firm secures applications. Every control below is correct, and each one is doing real work in your production environment right now. Each one also rests on an assumption about software that an agent does not satisfy.

Every one of those controls assumes a human read the code before it ran. With an agent, the plan gets written when the request arrives, after every review has already happened. That is why a stricter version of the same five controls won’t change anything. Tightening a control doesn't help when the assumption underneath it is the thing that failed.

How to secure agents

A control your compliance team owns has to be a control the model cannot talk its way around, which means it cannot sit inside the model. Prompt instructions, system messages, and fine-tuning all live in the same place the attack lives. Anything you write into the model is a request, not a guarantee.

Three principles follow from that, and they are architectural rather than procedural. They have to be true of the runtime an agent executes in, because none of them can be enforced by asking the model nicely.

1. Every security decision needs to happen in deterministic code outside the model. The model may propose but it is external code that decides. The runtime sets the identity rather than accepting it as an argument the model wrote, so a user ID or a record path the model invents gets ignored rather than honored.

2. The unit of enforcement needs to be the individual tool call, rather than the agent, the login, or the session. Authorization, isolation, and data-flow limits should get re-evaluated on every invocation. That is the only granularity that survives a model redrawing its own tool chain on each run, because anything coarser than a tool call assumes that the plan stays fixed.

3. Authority needs to be issued afresh for each call, and it should shrink at every step it passes through. One agent calling another on a read-only user's behalf cannot hand over write access, because every step stays capped by the tightest limit anywhere in the chain.

None of these depend on the model behaving well, and that is the whole point of putting them where the model cannot modify them.

Every agent on the Obin platform, which we call a Robin, operates according to all three of these principles. 

How Obin builds Agents

In order for Robins to conform to the three principles above, we secure them through design to conform to five controls, each of which is enforced by the Obin platform today.

1. An agent picks its own sequence of tools, which is where threat modeling comes apart. Therefore, a Robin can't add a tool once a request is underway, and if it strings its tools together, each call is still authorized before it runs. This way, the second tool call in an invalid composition is stopped from executing.

2. Input validation can't tell a real instruction from one hidden inside a document, so we assume an injected instruction will eventually run and limit what it can reach. Therefore, a Robin can't grant itself more permission, and any tool that changes data or reaches outside the firm can be set to wait for a person's approval, a requirement that can't be switched off once it's on.

3. Access control at the route breaks once the agent writes its own record paths, so the model never supplies an identity. Instead, the platform attaches the user from the verified session, which means a user ID the model invents is ignored. Robins that run with no user present work under their own identity and can't pass themselves off as a person.

4. A passing test won't tell you what tomorrow's plan will do, which is why every action a Robin takes is checked and recorded as it happens, with a trail back to the person behind it. Our build fails if a new path that reads or changes data isn't logged.

5. A Robin asked to reduce portfolio risk won't hold permission to delete positions, because permission to change or delete records in another system can't be written into its configuration, and our build fails if anyone tries.

Agents also create risks that no existing control was built for. They inherit whatever earlier work leaves behind, which is why every Robin session runs in its own sandbox with no credentials inside it and permissions are issued for each call and never stored. Agents can also work with each other in ways nobody planned or foresaw. A Robin can't create another agent or send one work on its own, and when Robins do work together, they follow a workflow a person designed ahead of time.

Firms in the same industry need a hard wall between them too, so each customer's data is kept in its own isolated cloud environment. A request for another firm's data fails at the infrastructure level before our code runs, and a correction one firm's experts make never reaches another firm's Robins.

In every case above, the decision the model could get wrong is made in code the model can't change, so a Robin stays inside its limits on its worst run as well as its best. That's also the standard worth holding any agent to before it touches any confidential data.

Where this goes next

Both incidents we opened with happened at two of the most capable AI organizations in the world, inside environments built specifically to contain agents, with people watching. If containment is hard there, it won't be easier in a firm that added agents to an existing stack over a couple of quarters.

Security reviews are starting to ask a different question. The old one was what the agent is allowed to do. The new one is what the runtime can prove it prevented, and that is a question about architecture rather than policy. We expect enforcement outside the model to follow the same path encryption at rest did, which stopped being a selling point once buyers learned to ask for evidence of it and became a floor instead.

If you're evaluating agents for anything that touches customer data, asking a vendor whether they take security seriously gets you a yes every time. Ask where the enforcement lives instead. Ask what happens when the model writes an identity that doesn't belong to it, and ask to see the control that catches it. The answers tell you whether you're looking at a secure-by-design architecture or a promise.

On the Obin platform, the enforcement lives in code the model can't touch. If the model writes an identity that doesn't belong to it, the platform ignores it and uses the real one from the verified session, and every tool call is checked before it runs.