A $50 refund cap still lets an agent pay out $500 in ten pieces

The settings screen asks for one number. Maximum refund the agent may issue without human approval: 50 dollars. In Madhuri Chandoor's worked example, a user asks for ten of those rather than the single 500-dollar refund that would have gone to a person for review, and each of the ten looks permissible when examined on its own ^[7][8]. Ten times 50 is 500, so the per-action cap tolerates precisely the amount it was written to stop, and it does so without producing a single policy violation to alert on ^[15].

That is an arithmetic problem before it is a security problem, and it tells you what the log has to contain. A profile can only see a run if every action carries the session it belongs to and the agent identity that took it. Without both fields, each row is its own story, and the story is always fine. Chandoor, who spent two decades in financial services, says the model she wants is fraud monitoring, where the unit of analysis is the account and the run of transactions rather than the charge in front of you ^[11].

The uncomfortable part is that the agent's reasoning holds up at every step. "A technical conclusion can appear reasonable within a narrow focus," she says, and the context and downstream impact still need weighing before the action proceeds ^[9].

Keep the evidence separate from the pitch. Both of her cases are illustrations rather than reported incidents ^[17], and she founded PromptHalo, which sells inspection of why an action is being performed rather than only what is being performed ^[6]. The measured material belongs to IBM, and what it measures is how executives feel: 11 percent of 2,000 C-level technology executives called themselves fully prepared for the agent deployment they expect within the year ^[1][2]. Set that beside the 70 percent who said teams were deploying faster than IT could track, and roughly six times as many people report a visibility problem as report readiness ^[4][16]. Instrumentation comes before profiling in that order, because there is no behavioral baseline for traffic nobody is recording.

Here is a forcing function you can run against your own inventory of agent actions, two axes, no product needed. First axis: can the action be undone cheaply. Second axis: do ten of them add up to something that none of them is. Reversible and non-additive actions are fine under a per-call ceiling, which is where most existing controls already work honestly. Reversible and additive is the refund quadrant, and it wants a session budget and a rate limit instead of a different item ceiling. Irreversible and non-additive wants a scoped credential and one named human. Irreversible and additive is the quadrant to take back out of the agent's hands until the log can join actions to a session and an identity.

The tradeoff is plain. Reviewing aggregates means holding requests that individually qualify, which is latency for the customer and labour for whoever works the hold queue. That is worth paying in the additive quadrants and wasted everywhere else, which is the sorting job, not the tooling job.