All blog posts Blog

Tool policies, approvals and tainted sessions

"The agent may issue refunds" is not a policy. How to write tool rules the model cannot argue with, make approvals impossible to reuse, and remember what happened earlier in the conversation.

Koreshield Labs2026-10-224 min read

A permission is not a policy

"The agent is allowed to issue refunds" describes access to a tool. It says nothing about which refunds, to whom, how large, or when a person must decide instead. Without those limits, the only thing standing between a persuasive conversation and a large payout is the model's judgement.

Koreshield's proposed-action check sits on the execution path and adds a security decision before the tool runs. It is additional evidence, not a replacement for the application's own authorization, which we covered in Security inspection and authorization are different decisions.

A refund of $50 allowed, $150 waiting for approval and $5,000 blocked
One registered policy, three outcomes, decided before the tool executes.

Register each consequential tool

A tool policy turns intent into rules that are evaluated in code. With one in place, a $50 refund goes through, a $150 refund waits for an operator, and a $5,000 refund never executes, regardless of how convincing the conversation was. For each consequential tool, Koreshield lets the team register:

  • An argument schema, with unknown fields rejected.
  • Allowed destinations.
  • A per-call and per-session amount ceiling.
  • The threshold above which a human must approve.

Approvals that cannot be reused

Human review only protects anything if an approval cannot be recycled. When a call crosses its threshold, Koreshield returns an approval request; an operator approves it in the console, and the agent repeats the identical call with the approval ID. Three properties mean an approval for "refund $120 on order 4471" cannot quietly become "refund $1,200 on order 9902":

  • Single-use: one approval authorises one execution.
  • Short-lived: approvals expire after one hour.
  • Bound to the exact arguments: change the amount or the order and the approval no longer applies.

Remember the conversation

Attacks rarely arrive in one message. Turn one is a harmless question, turn two is an injection attempt that gets flagged, and turn five is a normal-looking refund request. If each check only sees the current message, turn five passes.

Passing the same session ID on the input, context and action checks fixes that. When hostile input or retrieved context is flagged, the session is marked tainted, and later consequential calls in that session are judged accordingly. Only a keyed hash of the session ID is stored.

Agents get the checks, people keep the controls

Agent platforms should never hand the model the security system's control plane. Koreshield's scan-only contract for agent platforms exposes exactly three operations: scan_input, scan_context and scan_action. Evidence review, policy changes, mode switches, key management and billing are operator capabilities, never tools a model can choose to call.

Inside application code the same principle applies. The Python and TypeScript SDKs can guard a tool function directly with a decorator, so the action check runs every time the tool runs and cannot be forgotten or skipped.

Sources and further reading

Koreshield tool-action integrationSecurity inspection and authorization are different decisions