Declared agent sandbox is decorative - sandboxEnabled removes the human approval gate but does not confine the process

coding-agent-sandbox-perimeter-enforcement is a high severity check in the ai category, written in shell. Its source is templates/ai/coding-agent/coding-agent-sandbox-perimeter-enforcement.sh in cert-x-gen-templates.

What it checks

Drives a synthetic coding-agent host twice over the same synthetic stdio MCP server - once with sandboxEnabled true (a narrow sandbox.allowWrite and an allowedDomains list, the approval gate traded away) and once with the sandbox off as the differential control. The MCP child attempts three things the declared perimeter forbids: a write outside allowWrite, a TCP connection to a loopback canary listener that is not in allowedDomains, and a read of a planted decoy ~/.aws/credentials nonce. Each is verified by the template itself - a canary file it named, a connection its own listener received, a nonce only a real read could echo back - never by the host’s own ledger. CONFIRMED when a probe succeeds WITH THE SANDBOX ON that the unsandboxed control also achieves: the confinement that justified removing the human does not confine. REFUTED when every probe the control achieves is denied under the sandbox (the perimeter holds). SKIP on Windows, when the host declares no sandbox, or when the unsandboxed control achieves nothing (denial cannot be attributed to the sandbox).

There is a playbook for this check

The decorative sandbox (a confinement control that removed your approval prompt and confines nothing) sets out the use case, the probe flow, the oracle, and the fixture that proves it in both directions.

Header

Field	Value
Id	coding-agent-sandbox-perimeter-enforcement
Severity	high
Language	shell
Category	ai
Author	CERT-X-GEN Security Team
Template version	not recorded
Confidence	90
CVSS	not recorded
Weakness	CWE-693
Tags	ai, coding-agent, cli, agent-posture, sandbox, confinement, approval-bypass, differential, mcp, cwe-693, cwe-1188, cwe-732
Target kind	cli
Oracle	property, diff

Conventions of the repository, not fields the engine reads

@target_kinds and @oracles are documented in the templates repository’s contribution guide, and cxg’s annotation parser does not carry them into a template’s metadata. Nothing at scan time selects on them. The annotation header schema is every field the parser does read.

References

Declared in the header. cxg parses @references and then discards it, and nothing at scan time reads it, so this is the only place the links a template cites are surfaced.

• docs/playbooks/coding-agent-sandbox-perimeter-enforcement.md

Run it

To see what the copy on your machine says about itself, and to confirm it is installed at all:

cxg template info coding-agent-sandbox-perimeter-enforcement

The id it prints is the one to pass anywhere a template is selected. See cxg template for the rest of the subcommand, Scan a target for running a scan, and A match is not a finding for how to read what comes back.

Related

• Template catalog is the whole corpus.
• ai is the rest of this category.
• Templates by weakness class groups checks by the defect they look for.
• Contribute a template is the route from a check you needed and could not find to a merged one.