[ASI02/ASI09] Action-level approval + dry-run diff for destructive tool calls — close ASI02 #2 / ASI09 #1,#7

[initializ-mk]

Problem

An agent that is goal-hijacked or simply mistaken can invoke destructive tools (email delete, DB drop, git push --force, file deletion) with no human checkpoint. There is no confirmation and no way to see the effect of a state-changing call before it happens.

Current state

cli_execute enforces a no-shell sandbox, binary allowlist, and arg validation (forge-cli/tools/cli_execute.go), and egress is fail-closed (forge-core/security/resolver.go:12). Tool invocations are audited via tool_exec (forge-core/runtime/audit.go:20). But we do not gate destructive actions behind explicit approval, and there is no dry-run/preview that separates preview from effect. See docs/security/owasp-asi-conformance.md (ASI02, ASI09).

Proposed control

Prefer a policy-layer addition over a new forge-core builtin:

• A tool classification (requires_approval) in the policy layer.
• A preview mode that blocks state-changing calls and emits an approval_required (or guardrail_check) audit event, with the approval surfaced by the Platform.

Acceptance criteria

• A tool marked destructive/requires_approval cannot execute without an approval signal.
• Preview mode blocks state-changing tool calls and emits an instrumented audit event naming the tool.
• Metadata-only audit default and TestNoPayloadByDefault_LLMCall invariant unchanged.

Conformance test

TestASI02_DestructiveActionRequiresApproval, TestASI09_PreviewBlocksEffect (must go fail -> pass; assert on the block/approval audit event, not absence of output).

Out of scope

Approval UX/workflow (Platform). Model-side refusal. This does not address prompt injection itself.

Guideline reference

ASI02 mitigation #2 and ASI09 mitigation #1/#7 (OWASP Agentic Top 10 2026). Deduplicated: single control closes both.

[armorer-labs]

This is a good place to make the approval artifact slightly more specific than a boolean, otherwise the dry-run can prove the wrong thing.

For this control, I would treat preview and approval as a three-step contract:

• preview event: tool name, normalized args digest, target scope, predicted effect class, policy rule/version, and a preview id;
• approval event: approver principal, approval id, preview id, expiry, and whether the approval is single-use or reusable for a bounded scope;
• execution event: tool call id, final args digest, approval id, terminal status, and external receipt/id when the tool has one.

The invariant is: a destructive execution is valid only if the final args digest still matches the approved preview envelope and the approval has not expired or already been consumed. If the command, target resource, recipient set, file path, branch, or SQL text changes after preview, the old approval should go stale and the tool should emit another approval_required result rather than execute.

That also gives the conformance tests sharper failure cases:

• destructive tool with no approval -> blocked with approval_required;
• approval for a different args digest -> blocked as stale/mismatch;
• reused single-use approval -> blocked as already consumed;
• preview mode itself -> never mutates state, but still emits enough audit metadata for the Platform to render what would have happened.

Disclosure: I work on Armorer Labs.

[initializ-mk]

Dependency context: this is the approval keystone for new mutating tools

Flagging that #223 is now on the critical path for several proposed tool-gap issues. The existing HITL gate — R4c DEFER (#211, merged) — provides pause-and-resume approval, but it requires the operator to enumerate which tools pause and shows the approver a templated context string, not a computed diff. #223 adds the two things DEFER lacks:

1. Automatic destructive-action detection (don't rely on a hand-maintained per-tool allowlist)
2. Dry-run diff so the approver sees what will actually change before approving

Newly-filed tool issues that should route their mutating operations through the #223 approval path rather than inventing their own:

• feat(tools): sandboxed shell/command runner — controlled general execution beyond cli_execute's allowlist #265 — sandboxed shell/command runner (arbitrary execution → highest-risk; wants risk-classified approval, not just a static allowlist)
• feat(tools): wire up dormant file_read / file_write / file_edit / file_patch builtins for general agents #268 — wire up file_write / file_edit / file_patch builtins (file mutations → dry-run diff is a natural fit; approver sees the edit before it lands)

Net: prioritizing #223 unblocks a consistent approval story for the mutating tools above, instead of each one bolting on ad-hoc confirmation. Related existing gate: #211 (DEFER), #238 (denied-command patterns), #235 (path confinement).