security
- The leak scan found me in my own guard's tests
Publishing a private repo as one public commit: four gates, six catches, and my real user name inside my own guard's test cases.
- OpenCode didn't want an account. It wanted a model name.
A forwarded warning said OpenCode 2.x needs an opencode.ai account for self-hosted models. It doesn't. It needs you to name the model.
- My agent guardrails passed every test. Then I used them.
Weeks of tests against a scripted fake model, then one evening of real work with my coding-agent templates: three complaints, six findings.
- Lock OpenCode 2.x to your self-hosted model
Stop OpenCode 2.x from picking its hosted free model: name your local model or disable the opencode provider, then prove it with a PoC script.
- Confine a coding agent's HTTPS to an allowlist with bwrap
Run a command, such as a coding agent, in bubblewrap with no network except HTTPS to allowlisted hosts, through a 97-line Python proxy on the host.
- Another guard's test list found holes in mine
114 example commands from a separately built shell-parsing guard went through my regex guard. Most held. The worst gap was a guard that could quietly vanish.
- The test rig was the unsafe part
A suite that tells six coding agents to run rm -rf and docker system prune had a throwaway HOME and bwrap --unshare-net. Neither isolated what it needed to.
- The secret filter made my security test pass
A guard test passed on the old code in one agent. Its secret mask had eaten the marker that meant 'ran'. Then the fix passed for a different wrong reason.
- The fix was in five agents. The sixth never called it.
A guard fix was unit-tested in both implementations and probed on one agent. Per-agent end-to-end cases found the one agent whose hook never ran it.
- Tests that could not fail
I broke my agent guard on purpose so its 'ask' meant 'allow'. Two new tests still passed on another layer's say-so; a third passed on the old code too.