Guardrails: What a Security Agent Must Never Do Alone

The lines that never get crossed

Let's revisit the prohibitions set in the brief (module 2) and detail why they actually matter:

• Access to secrets and credentials — an agent handling API keys, tokens, or production passwords creates an extra point of failure. The risk isn't hypothetical: an ambiguous instruction or a reasoning error is enough to cause a leak.
• Destructive commands — push --force, branch deletion, reset --hard: none of these should run without explicit human confirmation, even within a legitimate security mission.
• Deployment without approval — a fix, even a correct one, should never go to production directly from the agent. The usual review chain (PR, CI, approval) applies in full.
• Publishing sensitive information — a detailed vulnerability report, published too early or in the wrong place, can literally serve as an exploitation guide before the fix is deployed everywhere.

The same instinct as with a junior

These guardrails aren't a statement of distrust toward this particular agent — it's the same frame you'd set for any new contributor, human or not, until trust has been built on repeated results. A security agent with a track record across dozens of well-scoped missions is still bound by the same limits: final accountability doesn't get delegated.

What's still left to do

Setting prohibitions isn't enough if nobody knows concretely who signs off on what, or how — that's where the human review needs actual structure, not improvisation.