Beyond Command Text: Caper Lets Coding Agents Be Judged by Consequences

Introduction: a command is only the beginning

When an autonomous coding agent can execute shell commands, approval becomes a key security boundary. Yet the command string often reveals very little about its eventual behavior. The real logic may live in an invoked script or tool, and the same command may be harmless in one workspace but destructive in another. Text-only approval therefore asks a difficult question: can a system predict consequences without observing the code and state that produce them?

The paper “Shall We Approve? Consequence-Aware Approval for Autonomous Coding Agents” proposes Caper, a mechanism built around a different question: what happened when the command was actually run in a controlled environment?

How Caper works

For each proposed command, Caper creates a snapshot of the workspace and pre-executes the command in a sandbox while tracing system calls. An independent LLM approver does not receive an unrestricted execution transcript. Instead, it reviews a bounded report summarizing observed effects, including:

• files created, modified, or deleted;
• attempted network activity; and
• reads of secrets or other sensitive information.

If the command is approved, the sandbox changes are committed to the workspace. If it is blocked, those changes are rolled back and the coding agent receives a reason that can guide a revised action. The design therefore combines observation with transaction-like execution: try first in isolation, then commit only after a decision.

What the evaluation shows

The authors compare Caper with six existing systems, including rule-based checkers, guardrail models, and deployed permission classifiers. On SABER, Caper records a harmful-outcome rate of 6.7%, while the comparison systems reach at least 14.8%.

The paper also introduces YoloFS-Ext, a benchmark designed to expose a weakness in text-based approval: harmful behavior can be hidden inside a tool that the agent is asked to run. On this benchmark, Caper’s harmful-outcome rate is 7.8%, compared with at least 35.3% for the other systems. The reported false-blocking result is also notable: Caper blocks 1.0% of the safe twins of the dangerous tasks in YoloFS-Ext.

The broader lesson is that authorization should not treat the agent’s command string as the complete object of inspection. The execution context and the effects produced inside it are part of the security decision.

Why it matters—and what remains open

Caper’s main contribution is not simply adding a stronger language model to the approval step. It changes the evidence available to that model. Instead of asking an approver to infer behavior from a short request, the system supplies a structured account of what the command tried to change, reach, or read.

This approach also moves checking from post-execution inspection to pre-commit verification. That can reduce the chance that a mistaken command immediately alters the agent’s working environment. At the same time, sandbox pre-execution is not a universal guarantee. The sandbox may differ from the real environment, and commands involving external state or irreversible side effects raise questions about how representative a trial run can be. The report itself must also balance useful detail against sensitive disclosure.

Even with those boundaries, Caper presents a practical direction for safer coding agents: approve observable consequences, not only stated intent.

Source: Hugging Face Daily Papers