Your Agent Doesn't Have A Prompt Injection Problem. It Has A Signing Authority Problem.

If you can't answer that with a single number, the answer is "all of it."

I start here rather than with the injection itself, because injection is the delivery mechanism and not the vulnerability. Something in the loop — a scraped page, a supplier PDF, a support ticket, a calendar invite — carried text that read as an instruction, and the agent acted on it. That will keep happening. Retrieved content is attacker-influenced by definition, and no amount of prompt hardening turns that into a guarantee.

The real defect is that a system reading untrusted text was also holding a payment instrument with no ceiling on it. In security terms this is a confused deputy: the agent has more authority than the task requires, and anyone who can talk to it inherits that authority. The fix isn't better instructions. It's less authority.

Assume the prompt layer will fail

Everything below is built on one assumption: at some point the model will decide to do the wrong thing, with full conviction and a plausible justification. Maybe from injection, maybe from a hallucinated requirement, maybe from a genuinely ambiguous instruction it resolved badly.

If your controls only work when the model behaves, you have no controls. Guardrails belong at the layer that executes the action, where they hold regardless of what the model believed at the time.

Give the agent its own money, not the company's

The single highest-leverage change is to stop handing agents a shared corporate card at all.

Issue scoped, ephemeral payment credentials — a virtual card minted per session or per task, with its own limit, its own expiry, and its own merchant restrictions. The blast radius of a compromised run becomes the balance on that one card, which you chose in advance.

This also solves attribution. When the incident review starts, "which agent, on which task, under which instruction, spent this" is a lookup rather than an investigation.

Layer the limits so a single number can't be the whole defence

One cap is brittle. Attackers find the shape of it and stay just underneath — twenty purchases of $2,400 against a $2,500 per-transaction limit is not a defended system.

Stack constraints across different dimensions so that evading one runs into another:

Per transaction — the ceiling on any single action
Per session or task — the total this run of the agent can commit, irrespective of transaction count
Per rolling window — hourly and daily aggregates across all sessions, so a loop of fresh sessions doesn't reset the budget
Per counterparty — a cap on new or low-history vendors specifically
Per category — spend classes the agent simply cannot touch, at any value

The useful framing is not "what should the limit be" but "if this run is fully compromised, what is the maximum loss I am willing to book?" Set the caps to that number and work backwards.

Approval thresholds that can't be argued with

Above a defined value, the transaction routes to a human. The important part is where that check lives: in the payment service, not in the agent's reasoning. If the agent can decide that this particular purchase is urgent enough to skip review, the threshold is decorative.

Two details that get missed:

Give the approver context, not a bare number.

An approval request showing amount, vendor, the task that triggered it, the retrieved content that motivated it, and how it compares to prior similar spend is reviewable. A modal saying "Approve $8,400 to Acme Ltd?" trains people to click yes.

Watch for approval fatigue.

If the threshold is so low that a human is rubber-stamping forty requests a day, you have added latency and removed the control at the same time. Tune it until approvals are rare enough to still be read.

Constrain the "who" before you constrain the "how much"

An allowlist of vendors and spend categories is a stronger control than any dollar limit, because it removes whole classes of attack rather than bounding them. An agent that can only pay four known suppliers is not a general-purpose money-mover no matter what text it ingests.

Default posture: nothing is purchasable from anyone. Additions to the list are a deliberate act with an owner, and new counterparties go through the human path on first use regardless of amount.

Separate data from instructions at the tool boundary

Injection works because retrieved content and operator instructions arrive as the same undifferentiated token stream. Reduce that where you can:

Wrap retrieved content in explicit delimiters and label it as untrusted data, never as directives
Strip or neutralise imperative content in scraped and third-party material before it reaches context
Have the tool layer validate that requested actions trace back to the original task, not to something that appeared mid-run
Keep the purchasing tool's parameters narrow and typed — an enum of approved vendors beats a free-text merchant field

None of this is a guarantee, which is exactly why it sits here, in the middle of the list, rather than at the top. It raises the cost of the attack. The financial controls are what cap the damage when it works anyway.

Prefer money you can still get back

Where the payment rail allows, choose the reversible form: an authorisation hold instead of a capture, delayed settlement instead of instant, invoice terms instead of a card charge, a purchase order awaiting confirmation instead of a completed order.

A settlement window is a detection window. It is the difference between an incident you unwind on Tuesday and a write-off you explain at the board meeting.

Detect velocity, then stop the agent automatically

Monitor the rate and shape of spend, not just the totals — transactions per minute, new-vendor ratio, deviation from this agent's own historical baseline, repeated near-threshold amounts.

And make the response automatic. Alerting a human at 3am produces a loss with a timestamped notification attached to it. Auto-pause the agent's payment capability on anomaly, fail the pending transactions closed, and require a human to resume. A false positive costs you a short outage and an unblock. The alternative costs you the balance.

The point

Autonomy is a scope you grant, not a capability you enable. Every guardrail above is really the same instruction expressed differently: give the agent exactly the financial authority its task requires, for exactly as long as it needs it, and no more. Do that and a successful injection becomes a contained, reversible, auditable event rather than an open line of credit for whoever writes the best paragraph.