Engineer the harness as part of the product.

Video caption

Engineer the harness as part of the product.

Guidance, local enforcement and release authority differ.

A policy is only as good as its fail path.

My rule: Do not let an agent approve its own claim.

#EricFieldNotes

Full written post / accessibility read

A coding agent can draft substantial changes, but one hook cannot govern every effect. The host must expose only bounded tools and permissions, capture post-action receipts and reserve release judgment for an independent grader. I would design those boundaries as architecture, then fault them before trusting a workflow.

An instructions file explains architecture. A pre-tool script parses only the file or operation shape it can actually inspect. Opaque shell and MCP routes need denial or OS and network isolation. A post-action script records the actual diff and a WAL receipt. Separately owned CI grades the exact build against a protected product decision.

Try a forbidden effect through file, shell and MCP routes in disposable work. Force a hook error and malformed output; confirm file and network state, not only hook messages. Cursor documents that some errors fail open and user-local hooks do not reach cloud agents; cloud beforeMCPExecution is absent. Test actual covered paths and sandbox escape attempts.

Bind trusted check status, source-linked acceptance and negative-control results to the exact commit and build digest. Keep consequential service permissions outside the agent's reachable routes. Do this because a worker can produce fluent evidence for a shortened requirement, while a protected grader and bounded authority can stop a wrong release.

#EricFieldNotes

Four-beat scene transcript

1. Engineer the harness as part of the product.

A coding agent can draft substantial changes, but one hook cannot govern every effect. The host must expose only bounded tools and permissions, capture post-action receipts and reserve release judgment for an independent grader. I would design those boundaries as architecture, then fault them before trusting a workflow.

Visual: Agent capability is only half the system.

2. Put each rule where it can act.

An instructions file explains architecture. A pre-tool script parses only the file or operation shape it can actually inspect. Opaque shell and MCP routes need denial or OS and network isolation. A post-action script records the actual diff and a WAL receipt. Separately owned CI grades the exact build against a protected product decision.

Visual: Guidance, local enforcement and release authority differ.

3. Test the control plane negatively.

Try a forbidden effect through file, shell and MCP routes in disposable work. Force a hook error and malformed output; confirm file and network state, not only hook messages. Cursor documents that some errors fail open and user-local hooks do not reach cloud agents; cloud beforeMCPExecution is absent. Test actual covered paths and sandbox escape attempts.

Visual: A policy is only as good as its fail path.

4. Separate producer from judge.

Bind trusted check status, source-linked acceptance and negative-control results to the exact commit and build digest. Keep consequential service permissions outside the agent's reachable routes. Do this because a worker can produce fluent evidence for a shortened requirement, while a protected grader and bounded authority can stop a wrong release.

Visual: Do not let an agent approve its own claim.

Research and claim limits

• Cursor hooks documentation (S04)
• GitHub Docs: ruleset required status checks (S146)
• NIST SP 800-218 Secure Software Development Framework (S150)

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