Security rules for AI coding agents: a practical checklist
In short: AI agents happily hardcode keys, trust request bodies and log tokens. A short, always-on security rule fixes most of it, as long as each line is concrete and checkable.
What to put in an always-on security rule
- Never write secrets in code, tests or logs. Read them from env and validate the env at startup.
- Validate every external input at the boundary with a schema (Zod, Pydantic).
- Check authorization on every server action and route, not only in the UI.
- Use standard library crypto (scrypt, argon2, HMAC with timing-safe comparison). Never invent your own crypto.
- Verify webhook signatures over the raw body before parsing it.
- Don't add a dependency without saying why, and prefer maintained packages.
Why concrete beats vague
"Be secure" does nothing. "Verify the X-Signature HMAC over the raw body with timingSafeEqual" gets followed and can be reviewed. Pair the rule with a /security-audit skill that walks the diff against the checklist.
The free sampler includes our security rule in every tool format. The SaaS Starter shows it applied: signed sessions, scrypt hashing and a verified Lemon Squeezy webhook.
FAQ
What should an always-on security rule for AI agents include?
Never write secrets in code, tests or logs; validate every external input at the boundary with a schema; check authorization on every server action and route; use standard library crypto; verify webhook signatures over the raw body; and justify every new dependency.
Why doesn't "be secure" work as a rule?
Vague rules do nothing. A concrete, checkable line such as "verify the X-Signature HMAC over the raw body with timingSafeEqual" gets followed and can be reviewed.
How should AI agents handle secrets?
Read them from environment variables, validate the environment at startup, and never write them into code, tests or logs.
How do I check a diff against the security rules?
Pair the always-on rule with a /security-audit skill that walks the diff against the checklist.