The work I never let an agent do in one shot

There's a category of work I've drawn a hard line around: my agents don't do it in one shot, regardless of how routine the task looks or how much I trust the agent otherwise. Authentication and authorisation logic. Anything touching secrets, tokens, keys. Input validation, permission checks, the security-sensitive layer generally. Not because the agent can't produce plausible code for these. Because plausible is exactly the problem.

The failure mode here is structural, and it's worth being precise about, because "be careful with AI code" is useless as advice. What actually happens is that the model satisfies the stated requirement while silently omitting the unstated one. You ask it to build a feature that lets users see their data. It builds a feature that lets users see their data. What you didn't say, because it was too obvious to say, was "and only their data." The access-control assumption was never in the prompt, so it was never in the output, and everything looks like it works because in your own testing you're only ever logged in as yourself.

This isn't hypothetical and the post-mortems have names. Lovable shipped apps with a CVE where row-level security was simply absent, so any user could read any other user's records. A tool called Moltbook exposed something like 1.5 million API keys. A security firm scanning vibe-coded applications found roughly 65 percent of them carried security issues. The through-line in every case is the same: the AI didn't make a mistake in the code it wrote. It correctly wrote the code that was described, and the security assumption lived in the gap between what was described and what was meant. You only find out at the breach, because nothing before the breach looks wrong.

The reason "prompt more carefully" doesn't fix this is that the missing assumptions are, by definition, the ones you didn't think to state. If you'd thought to state them, they'd be in the spec. The gap is unbounded and you can't prompt your way across an unbounded gap. So the fix lives somewhere else. Name the categories of work that don't get delegated in a single pass, and treat security as its own explicit review step rather than a property you hope came along for free with the feature.

Concretely, what the line means in practice. Auth and access-control logic is never a side effect of a feature; it's a separate, deliberately-reviewed change. Secrets are never generated, hardcoded, logged, or committed by an agent, and anything in a diff that reads like a live credential gets flagged and stopped, not merged. Security review is a pass in its own right, not something I assume happened because the tests were green. And there's a supply-chain corner people miss: agents hallucinate plausible package names, and a plausible package name is something an attacker can register and wait for. So a dependency gets confirmed to actually exist and be the real thing before it's installed, never trusted because the model wrote it down confidently.

The point that makes this a line rather than a nag is that it overrides the agent's normal autonomy. I let agents run a lot of work end-to-end and report back; that's the whole value. But when a task touches this category, the autonomy level doesn't matter, the task stops and a human looks. Even a task the agent would normally be trusted to just do. The categories are the override, and the override is not negotiable per task, because the entire failure mode is that these omissions are invisible until they aren't.

None of this is anti-agent. I ship agent-built code constantly. It's that the security boundary is precisely where the "it satisfies the requirement" heuristic breaks, because the requirement you can see is not the requirement that matters. The stated thing is easy and the model nails it. The unstated thing is the security, and the model leaves it out not through error but through doing exactly what it was told. Knowing which slice of work sits on that fault line, and refusing to one-shot it, is most of what separates an agent workflow you can trust from one that looks trustworthy right up until the incident.