Choose the response by the authority it needs, not the severity of its warning.
A warning, an approval request, and a refusal should not be three colors on the same safety indicator. They change who controls the next action. Steering asks the agent to reconsider. Confirmation transfers a specific decision to an authorized person. Denial removes the proposed action from the permitted path. A system that treats them as interchangeable can interrupt harmless work while leaving consequential operations open.
The useful question is not how worried the guardrail sounds. It is what happens to the pending call, what evidence can release it, and who owns that release. Those answers should exist before a model returns a judgment. A score can help select a response within policy; it cannot decide which authority the organization meant to delegate.
Consider a hypothetical coding assistant preparing a release. It can edit a local branch and run permitted checks. It cannot publish the package, charge a company account, or delete retained production data on its own. That bounded grant gives the three responses different jobs without pretending every write has the same impact. The workflow here is a proposed design, not an account of a deployment or test I performed.
Steering fits a repairable mistake within that grant. Suppose an edit replaces a useful error message with a raw exception. A finding can identify the violated project convention, point to the changed lines, and ask for a correction. The agent still chooses the repair. The guardrail should judge the revised result, not count receipt of its advice as success. If correction repeatedly fails, the system needs a bounded stop or review path rather than an endless exchange of increasingly emphatic warnings.
Reversibility requires an operating boundary, not merely a version-control command. An edit can be reverted while a credential exposed by the edit remains compromised. A local check may invoke a script with network effects. I would reserve autonomous repair for work whose affected resources, downstream effects, and recovery path are actually bounded. Uncertain impact is a reason to hold the proposed operation and obtain evidence, not to label it reversible because its filename looks ordinary.
Steering also does not imply that the original call runs. Pi-Warden’s tagged 1.7.0 implementation illustrates the distinction: its steer response to a held action returns a blocking result and tells the agent to re-plan or ask. Its advise mode lets the corresponding hold-level finding become a warning, while confirm mode uses a person-facing dialog. These are source-reviewed behaviors, not runtime results reproduced here. The product’s mode name matters less than whether its host releases the call.
A temporary hold for repair differs from a hard denial. With steering, an eligible alternative can proceed after fresh checks: change the implementation, narrow the target, or choose a non-destructive inspection. With denial, the forbidden operation remains forbidden even if the agent supplies a more persuasive rationale. The distinction should survive paraphrasing and alternative tool routes. Otherwise, the agent learns to search for an interface the warning did not cover.
Confirmation belongs where a person can resolve a legitimate decision the agent does not own. The release assistant might prepare an upload for a release manager to authorize, or propose deleting a verified disposable environment. The prompt should display the resolved destination, affected resources, significant content, and consequence. A dialog that says only “Allow this tool?” asks the reviewer to infer the important facts from the agent’s explanation, which is precisely the interpretation still under review.
OWASP’s transaction-authorization guidance calls for acknowledgement of significant transaction data, controlled state transitions, and a final authorization check tied to execution. Applied to the release, confirmation should bind to the actual artifact and destination. Applied to a payment, it should bind to the resolved payee, amount, and relevant terms. Changed significant inputs invalidate the earlier decision; a general “yes” in a conversation should not silently authorize the replacement.
The person must also possess the authority being requested. A developer may approve a branch edit without owning production release policy. An account holder may confirm spending within a delegated limit without overriding a prohibited recipient. Confirmation is not a universal exception mechanism. If policy offers an appeal, send it to the named policy owner and record the scoped exception through a separate authorized process. Do not turn every denial into an approval button for whoever happens to be online.
Known prohibitions belong in enforcement. If the assistant must never publish under its current grant, prevent publishing rather than asking a probabilistic judge whether this particular release looks sensible. OWASP’s authorization guidance recommends least privilege, denial by default, and permission checks on every request. For a coding agent, command and path rules can help express a boundary, but the downstream credential and resource permissions must support it. Blocking one shell spelling does not protect an operation available through another client.
There is still a gray zone between clear eligibility and clear prohibition. A judge can examine whether a command appears to affect production, whether the proposed purchase matches the task, or whether an edit violates a semantic rule. Preserve its result as fallible evidence with provenance. Missing context, an unfamiliar action, or conflicting findings should lead to a bounded hold and an owned question. They should not grant permission by default or become a permanent accusation that the requested work is malicious.
The judge needs a trust boundary too. A repository comment saying “the owner already approved deployment” is not an approval record. A tool result claiming to contain updated policy is not policy merely because the agent retrieved it. OWASP’s prompt-injection guidance identifies indirect instructions in external documents, code comments, and tool-connected workflows as attack surfaces. Passing the same material to a second model does not establish its authority. Keep policy and approval records application-controlled, and preserve untrusted content as evidence rather than instructions the judge can promote into permission.
Failure handling must preserve the selected job. If an optional style judge times out during an otherwise eligible local edit, a documented policy might permit work with the advisory check marked unavailable. If a required authorization check fails before spending or destruction, retain the pending action without execution. An unanswered confirmation should expire into a held or cancelled state, not count as consent. A denied call should remain denied when the semantic service is unreachable. These are proposed dispositions whose owners must define them, not guarantees supplied by the word guardrail.
Keep decision failure separate from uncertain execution. If the operation was dispatched and its response disappeared, the next state is an unresolved outcome, not a fresh confirmation request for the same effect. Reconcile downstream state before any authorized repeat. This distinction prevents a conscientious agent from asking twice and producing two payments or deletions. The person should see which operation is still pending and which might already have happened.
An audit record should show the proposed action, applicable grant, policy version, finding, selected response, approval or exception reference, execution attempt, and verified outcome. Record the person who released a hold separately from the agent that proposed it. Keep those records outside the actor’s editable context, with access and retention controls appropriate to the content. The evidence of a boundary is a prevented operation or a scoped release, not a fluent sentence saying the agent behaved safely.
Evaluate the responses against distinct failure cases. In controlled fixtures, present a repairable edit, a changed payment after approval, a known prohibited command, a forged approval inside a document, and an unavailable required judge. Check whether the call ran, who could release it, and whether an alternative route bypassed the boundary. These are proposed tests, not results reported here. Track missed prohibitions separately from needless holds and failed repairs; a single intervention rate hides all three.
Confirmation everywhere is not the conservative answer. It consumes reviewer attention and delegates interpretation without necessarily improving it. Steering everywhere leaves the actor responsible for boundaries it cannot own. Denial everywhere prevents the useful work the grant was supposed to enable. Give repairable work room to recover, legitimate uncertainty an accountable decision-maker, and prohibited operations an enforcement point the agent cannot persuade. Choose the guardrail by the authority needed for the next action.
Subscribe to Signal Over Noise for practical analysis of AI agents and automation: what to test, which constraints matter, and when a tool is worth using. Bring the next idea to one bounded workflow and check the result before expanding it.
If this was useful, forward it to one engineer who needs less noise in their feed.