Secure by design for coding agents & beyond

The agent is the attack surface. Threat model, isolation, layered defenses, and the stakes for the people who never signed up for them. This series is about secure-by-design applied to the agents we now run on our own machines.

Ongoing · 3 chapters

The capabilities that make an agent useful are the same ones that make it exploitable. You can’t patch that away; you design around it. This is the move we drew at Fyde and the core principles of the Zero Trust Architecture: stop trusting the perimeter, assume the inside is hostile, contain the blast radius. We are repeating the mistakes the web already made and learned; it feels like we unlearned these principles but this time we have agents.

This series is the practitioner’s arc for coding agents and the systems around them. The prompt-injection vector gets its own first-principles treatment in Defending against prompt injection; here the focus is the rest of secure-by-design: the threat model, the isolation, the layering, and the stakes.

Some chapters are live, and others land as I voice them. Read in order or jump to the one that’s biting you.

03. A broken sandbox is worse than no sandbox, layer your defenses
Lessons we need to take from the second bypass of Claude Code's network sandbox in five months
04. Most people doing 'vibe-coding' inherited a developer's attack surface without realizing it
Coding agents hand non-developers a developer's full attack surface, without the years of instinct that usually come with being in the trenches doing software development. The exposure is identical, but the defense is absent. The fix must live in the defaults.
05. Overeager agents and a guardrail that admits it isn't one...
Claude Code's permission denial hands the agent a workaround, then asks it to infer and respect the user intent