Make the agent boundary deliberately boring.

Video caption

Make the agent boundary deliberately boring.

Before, after and outside the worker.

Try every route the agent can use.

A green hook log is not acceptance.

#EricFieldNotes

Full written post / accessibility read

A strong agent can propose architecture and code quickly. Give it a predictable effect perimeter: covered file operations face a parsed allowlist; opaque shell or MCP routes are denied or isolated by OS and network permissions; protected release checks sit outside its write scope. AGENTS.md can explain the rule, but cannot itself enforce it.

Before a supported file call, validate its path and operation. Do not pretend that parsing a shell string proves what a spawned program or MCP server will do; deny that route or sandbox its permissions. After execution, record actual changes. At release, require independent non-empty tests bound to the exact artifact.

In a disposable worktree, try an outside-path write through file, shell and MCP routes. Force malformed hook output and an unexpected exit, then inspect actual file and network state. Cursor's permission-hook invalid JSON with exit zero should block, while other error exits can proceed; the sandbox must still prevent forbidden effects.

Protect the customer's source decision and negative-control fixture outside worker write scope. Require trusted status on the exact build before release. Do this because hooks can only intercept routes they see, lower permissions limit missed routes, and independent evidence decides whether the finished behavior is right.

#EricFieldNotes

Four-beat scene transcript

1. Make the agent boundary deliberately boring.

A strong agent can propose architecture and code quickly. Give it a predictable effect perimeter: covered file operations face a parsed allowlist; opaque shell or MCP routes are denied or isolated by OS and network permissions; protected release checks sit outside its write scope. AGENTS.md can explain the rule, but cannot itself enforce it.

Visual: The creative center should not own its own gate.

2. Divide the controls by moment.

Before a supported file call, validate its path and operation. Do not pretend that parsing a shell string proves what a spawned program or MCP server will do; deny that route or sandbox its permissions. After execution, record actual changes. At release, require independent non-empty tests bound to the exact artifact.

Visual: Before, after and outside the worker.

3. Exercise failures on purpose.

In a disposable worktree, try an outside-path write through file, shell and MCP routes. Force malformed hook output and an unexpected exit, then inspect actual file and network state. Cursor's permission-hook invalid JSON with exit zero should block, while other error exits can proceed; the sandbox must still prevent forbidden effects.

Visual: Try every route the agent can use.

4. Let the release gate carry product authority.

Protect the customer's source decision and negative-control fixture outside worker write scope. Require trusted status on the exact build before release. Do this because hooks can only intercept routes they see, lower permissions limit missed routes, and independent evidence decides whether the finished behavior is right.

Visual: A green hook log is not acceptance.

Research and claim limits

• Cursor hooks documentation (S04)
• GitHub Docs: ruleset required status checks (S146)

The examples identified as illustrative or simulated are design probes, not reported incidents. Vendor specifications do not establish workload performance.