What Is the Worst Your AI Agent Could Do? Putting a Money Number on It

Ask a risk committee how much damage a production AI agent could do if an attacker took full control of it, and you usually get one of two answers. The first is a description of the controls: "it has guardrails, it is monitored, it has a human in the loop." The second is silence. What you almost never get is a number.

That is odd, because banks put numbers on almost every other exposure. Credit limits, payment limits, daily payout caps, fraud loss budgets. The agent is the one new actor in the building whose worst day nobody has priced.

Why the question has become urgent

Agents are moving from answering questions to taking actions: issuing refunds, updating account details, approving claims, releasing payments. Once an agent can act, the security question changes. It is no longer only "can the model be tricked?" but "if it is tricked, what can it do?"

OWASP's guidance on Excessive Agency frames it exactly that way. It traces damaging agent behaviour to three root causes, excessive functionality, excessive permissions and excessive autonomy, and it is explicit that the risk applies whatever caused the model to misbehave, whether a hallucination, a prompt injection or a compromised plug-in. In other words, you should assume the model will eventually do the wrong thing and design so that the wrong thing is bounded.

Regulators are asking similar questions. FINRA's 2026 oversight report lists agents acting beyond the user's intended scope and authority among the risks firms should control. Neither document gives you the number. That is your job.

Why "we have guardrails" is not an answer

Most agent risk reviews test the model: can a red team get it to say or do something it should not? That is useful, but it measures the lock, not the size of the room behind it. A determined attacker, or a strange enough input, will eventually get through a model-level guardrail. When that happens, the only things that matter are deterministic: which tools the agent can call, what limits those tools enforce, and which actions need a human signature before they take effect.

Those are facts about configuration and code, and they can be checked without trusting the model at all. That is what makes a money figure possible.

How the exposure hides

When I look at how agents are wired into back-office systems, the same patterns come up:

• Inherited permissions. The agent runs under a service account built for an older batch process, with far wider access than the agent's task needs.
• Per-action limits without cumulative limits. Each refund is capped, but nothing caps the number of refunds per hour.
• Approval steps that can be routed around. A human must approve a payment over a threshold, but the agent can split it, or call a different tool that does not trigger the check.
• Chained tools. One tool changes a customer's payout details, another releases funds. Neither looks dangerous alone.

Fraud teams will recognise the last two. They are the same structuring and setup tricks human fraudsters use, applied to a new actor.

Self-check: put a rough number on one agent

You can make a first estimate yourself. Pick one agent and work through these:

• List every tool the agent can call, from the code or configuration, not from the design document. They often differ.
• For each tool, find the identity it runs as and what that identity can do beyond the agent's intended use.
• Write down every hard limit: per action, per customer, per hour, per day. Mark which are enforced in the downstream system and which only in the agent's prompt. Prompt-only limits do not count.
• Find the approval steps and test whether any sequence of allowed calls reaches the same outcome without them.
• Look for chains: pairs of tools where one changes a destination and the other moves value.
• Multiply: maximum value per action, times the maximum number of actions before a limit, monitoring or a human stops it. That is your first-cut worst case.

Illustrative example: an agent can issue refunds of up to 500 each, with no hourly cap, and the team reviews refunds the next morning. If the agent can issue one refund every few seconds overnight, the worst case is not 500. It is however many refunds fit in the hours before anyone looks, and that figure is usually large enough to change the conversation.

Why independence matters

A worst-case number is only useful if people believe it. If the same firm that calculates your exposure also sells you the fix, there is an obvious incentive to make the number scary. If your own team calculates it, there is the opposite pressure. A credible statement comes from someone who checks the controls deterministically and has nothing to sell afterwards.

How Riskernel runs this as a fixed-scope assessment

The Agent Blast Radius Statement is a signed, independent statement of the worst-case loss a production AI agent could cause if it were fully hijacked. It is built on deterministic checks of the agent's tool scopes, limits and approval steps, not on whether a red team happened to break the model on the day.

The fix is not sold in the same engagement, so the number stays independent. Scope and fees are agreed on a short call.