Secure-by-Default Scaffolding for AI Coding Agents
The insecure version is usually the shorter path: a token in localStorage, an unvalidated body, a missing header.
A scoped security pattern sets the floor where the code is written, not in review after the fact.
What this covers
- A coding agent optimizes for the change that compiles and passes the obvious test, and the insecure default is usually fewer lines, so the first draft tends to be insecure.
- A security pattern places the specific secure default at the path where the relevant code lives, so it reaches the agent at the moment it is writing that code, not in review.
- Security patterns are rule-heavy, mark the dangerous items as strict rather than advisory, and pair with hooks for the violations that must never happen.
- A pattern is a floor, not a substitute for review; it removes the predictable findings so reviewers can spend attention on contextual risk.
Before and after
| Area | The agent reaches for the easy default | A security pattern sets the floor |
|---|---|---|
| Storing a session token | localStorage, because it is one line | Strict rule: httpOnly cookie, SameSite, short-lived, scoped to the auth path |
| Handling user input | Trusts the request body shape | Rule: validate and narrow every input at the boundary |
| Adding a dependency | Installs whatever the snippet used | Memory: pin, audit, and review new dependencies before they reach CI |
| Setting response headers | Framework defaults, often none | Rule: deny-by-default policy and security headers on every response |
The agent writes the first draft now
A coding agent now writes the first version of a lot of code. It scaffolds the auth flow, wires the form handler, adds the dependency, sets up the route. That shift is mostly good for speed. It is quietly bad for security, because the easy default and the secure default are rarely the same line.
Storing a token in localStorage is one line. Storing it in an httpOnly cookie with the right flags is several, and requires knowing which flags. Trusting the request body is free. Validating and narrowing every input costs a schema. The agent, optimizing for the change that compiles and passes the obvious test, reaches for the shorter path.
The result is code that works in the demo and fails the security review. Not because the model is careless, but because nothing told it the secure default before it started typing. The instruction arrived too late, in review, after the insecure shape was already written.
Secure defaults belong where the code is written
The fix is not a longer root instruction file that says be secure. That is advisory, global, and quickly buried. The fix is to put the specific secure default at the path where the relevant code lives, so it reaches the agent at the moment it is writing that code.
A rule about session cookies belongs at the auth path. A rule about input validation belongs at the API boundary. A content security policy rule belongs where responses are built. Scoped this way, the secure default is present exactly when it is relevant and absent when it would be noise.
This is the same scoping argument the blog makes for conventions in general, pointed at security specifically. The difference with security is the cost of getting it wrong, which is why the enforcement level matters more here than anywhere else.
What a security pattern actually ships
A security pattern is a bundle built mostly from rules, because security is mostly constraints. The Web Security pattern ships rules for deny-by-default policies, distrusting input, and secure response headers. The Auth pattern ships rules that push sessions toward httpOnly cookies and away from token shapes that a cross-site script can steal.
Alongside the rules sit a few memories: the decisions that are not hard constraints but are worth remembering, like why the team pins and audits dependencies before they reach CI. The Supply Chain Security pattern is largely this shape, because the dangerous step is a dependency entering the build, not a single line of code.
The point of bundling them is that a concern like web security is not one rule. It is a small set that only works together, scoped across the few paths where each part applies. Shipping them as a pattern puts the whole floor in place at once instead of one rule at a time.
Strict versus advisory is the lever
Pathrule rules carry an enforcement level. An advisory rule is guidance the agent should usually follow. A strict rule is one the agent is told it must respect, and the kind that pairs with a hook when the cost of a violation is real.
Security is where that distinction earns its place. Most conventions are fine as advisory. A rule that secrets never get committed, or that a destructive command never runs against production, is not advisory. It is strict, and a security pattern marks it that way so the agent treats it as a boundary, not a suggestion.
This connects security patterns to the enforcement story the blog has covered before. The pattern sets the strict rule near the code. A hook can lock in the one or two violations that must never happen. The two layers do different jobs, and a security pattern is the content half of that pair.
A floor, not a replacement for review
A security pattern is a floor, not a guarantee. It raises the default so the agent writes the secure shape on the first pass, which removes a whole class of avoidable findings from review. It does not make the code audited, and it does not replace a human who understands the threat model.
The honest claim is narrow and worth making anyway. Most security review time is spent on the same predictable mistakes: an unvalidated input, a token in the wrong store, a missing header, a dependency nobody checked. A pattern that ships those defaults moves that work earlier and frees the review for the judgment only a person can apply.
Used this way, the pattern and the review reinforce each other. The pattern handles the predictable floor. The reviewer spends their attention on the specific, contextual risks that no bundle can anticipate.
Adding the security floor today
A practical first step is to add the security pattern that matches your stack to the paths where the risk lives. Web Security for the app surface, Auth for the login flow, Supply Chain Security for the build. Import each one and its rules land scoped, strict where they should be.
Then run the next change through an agent and watch where the secure default shows up. The session token reaches for a cookie. The handler validates its input. The response carries its headers. The insecure first draft simply does not get written, which is the cheapest place to prevent it.
Every signup gets three months of Pathrule PRO on the house. If you want help mapping the right security patterns onto a real repo, [email protected] is open, and every pattern in the catalog is free to read and use.