Irreversible Actions an Agent Must Never Take Without a Human

Classify by what happens if the call runs and turns out to be wrong. A read that leaks data is bad, but a delete that runs is gone. The categories below cover the actions where "undo" does not exist or costs more than the approval would have.

OWASP's agent guidance sorts actions into four risk levels running from plain reads up to irreversible or security-sensitive changes, and asks for explicit approval on high-impact or irreversible actions plus an action preview before execution (runtime policy enforcement guide). The table above is that idea made concrete for the actions most likely to hurt.

Two refinements matter. First, classify on arguments, not just tool name: a restart in a staging namespace and a restart in the payments namespace are different actions and belong in different tiers. Second, read, generate and execute are separate capabilities and should receive separate permissions, so a drafting agent that writes an email does not automatically inherit the right to send it (ThreatLocker).

The line for "send" is the boundary of your own system. Writing a message to your internal queue is a one-hop problem you can roll back. Delivering to a customer, a partner or a public feed leaves your blast radius permanently.

The enforcement point is the code that sits between the model's tool call and the real API. Every tool call goes through one function, and that function holds the last word.

def execute_tool(name, args, context):
    decision = policy.decide(name, args, context)  # may raise
    if decision.effect == "deny":
        return refusal(name, decision.reason)
    if decision.effect == "approve":
        token = approvals.request(name, args, decision)
        return pending_approval(name, token)  # agent sees a structured "wait"
    return real_tool_map[name](**args)        # allow, logged

Three properties make this wrapper a real control rather than a speed bump. It runs inside the process that holds the credentials, so the model cannot route around it by calling another tool. It sees the arguments before execution. And it returns a value the agent can read, so the agent learns to wait instead of retrying. An approval gate is an authorization primitive, not a UX affordance (Scalekit).

The same reasoning applies to the shell. Terminal agents need a command grammar rather than a regular expression list, and the check has to see the command before it executes (harness engineering). The OWASP guidance is explicit that a rule at the gate sits outside the model's reach while a rule in the system prompt does not (runtime policy enforcement guide).

Framework hooks help but do not replace this. The OpenAI Agents SDK runs an input tool guardrail before the tool executes and can skip the call or raise a tripwire, but those hooks run inside the agent's own process (runtime policy enforcement guide). Pair an agent-side hook with a policy gate outside the agent and with infrastructure backstops such as admission control and cloud IAM, which still hold when an agent-side check is skipped.

Deny by default means an unknown tool, an unparseable argument, an unrecognized destination or a missing policy entry all resolve to refusal. This is the opposite of how most agent stacks are wired, where a new tool is usable the moment it is registered.

The permission model that works for agents is stated flatly: the LLM proposes actions and policy authorizes them, because letting the agent's reasoning become your authorization logic is how you build an incident generator (Oso). Over-permissioning usually arrives quietly, through connectors added to make a demo work, and it never gets tightened.

Fail closed covers the unhappy path. If the classifier times out, if the approval service is unreachable, if the policy engine returns an error, the answer is refuse and log, never allow and hope. A useful test of any gate: unplug the policy service and confirm that writes stop rather than proceed.

def decide(name, args, ctx):
    try:
        rule = policies.get(name)
        if rule is None:
            return Deny("no policy for tool")        # deny by default
        return evaluate(rule, args, ctx)
    except Exception as e:
        return Deny(f"policy error, failing closed: {e}")  # fail closed

Two more defaults earn their place. First, scope grants to one task and set an expiry, because a grant that outlives its task turns into a standing permission (runtime policy enforcement guide). Second, give each agent its own identity with a named owner, so a bad call is attributable to both the agent and the person who authorized it.

When the gate blocks, the agent needs to understand what happened or it will loop, retry, or hunt for another tool that does the same thing. Return a typed object with a stable shape.

{
  "status": "refused",
  "category": "destructive_delete",
  "tool": "db.delete_rows",
  "reason": "irreversible: requires two approvers and a restore plan",
  "approval_url": "https://…/approvals/9f2c",
  "expires_in_seconds": 900,
  "retryable": false
}

Three fields do the heavy lifting. retryable: false tells the agent to stop rather than iterate. approval_url points at the human queue entry, so the agent can surface "waiting on approval" to its user instead of inventing a different route. reason carries the policy rationale, which is the context a reviewer will also need.

Approval as a workflow state, not a sentence in the prompt, is the pattern the stronger implementations converge on: the run pauses, a reviewer sees the proposed action and its effect, and the run resumes only after a valid decision (Promptessor). Approve and reject are usually too narrow; modify and escalate are useful decision types, and reviewer identity and authorization have to be checked, not assumed.

The gap most approval implementations skip is what happens between the pause and the resume. The credential that was valid at pause time is not guaranteed to be valid at resume time, and a queue-then-execute model has to hold credential state across that window while the agent references an identity and connection name, never a raw token (Scalekit).

A token that carries the decision should therefore be:

• Signed, so the tool wrapper can verify it was minted by your approval service and not by the agent.
• Single use, consumed on first execution, so a replay of the same token cannot run the delete twice.
• Bound to the exact call, including a hash of the tool name and arguments, so an approved refund of one amount cannot authorize a refund of ten.
• Short lived, expiring in minutes, so an approval granted on Friday does not authorize a merge on Monday.
• Bound to an approver identity, so the audit trail records who said yes and what they were authorized to approve.

def consume(token, name, args):
    claims = verify_signature(token)            # raises on bad signature
    assert claims["tool"] == name
    assert claims["args_hash"] == sha256(canonical(args))
    assert claims["exp"] > now()
    assert store.mark_used_once(claims["jti"])  # atomic, fails on replay
    return True

Then revalidate state before you execute. A pending action can go stale while it waits: the record changed, the balance moved, the deploy target moved. If the world no longer matches what the reviewer saw, request a new decision rather than honoring an approval for a situation that no longer exists (Promptessor).

Approval fatigue is the quiet killer of this whole scheme. Constant prompts train reviewers to click yes without reading. Start with materially consequential actions, watch the telemetry, and only loosen thresholds for repeated, well-understood actions inside tighter boundaries (ThreatLocker).

An approval prompt that says "Allow this agent?" protects nothing. The reviewer needs enough context to judge the specific call: the agent, the requesting user, the tool, the target resource, the data involved, the requested permission and the expected result, plus the proposed diff, recipients or privileges where relevant (ThreatLocker).

A worked example makes the economics clear. Suppose a remediation agent proposes a schema migration touching a table with 40 million rows, and a restore takes about four hours versus a human review that takes about ten minutes. Add the two-approver rule and you have spent twenty minutes of reviewer time to bound a four-hour outage plus whatever data the migration dropped. That ratio, not a blanket rule, is how you decide where approvals go.

For irreversible and security-sensitive tiers, the stronger pattern is to refuse rather than hold inside the agent flow and require the change to be made outside the agent entirely. IAM changes, disabling audit logs and promoting from staging to production belong there (runtime policy enforcement guide). Some actions should never be one click away from an autonomous loop.

Work through this in order; each step is testable on its own.

The audit line is not optional for regulated teams. SOC 2 requires evidence that logical access controls were functioning at the time of each action, and most security reviews want the stronger claim that a human authorized this specific operation at this timestamp. Scope grants do not satisfy that; approval events do (Scalekit).

If you are wiring several model providers and tool surfaces behind one gate, a single key across text, image, video and embedding models removes one moving part from the credential inventory. That is what Quanta Inference is for. For the reviewer side, the context an approver needs is the kind of thing a mapped expert can assemble and hand back as a finished decision packet, which is what the experts at Quanta Experts are built to produce.