Your assistant reads a project instruction file every time it works, so anything you put there is in context on every request instead of something you hope it remembers. People use it for style and stack conventions, which is fine, but it is also the earliest point where you can steer the model away from the handful of patterns that cause most of the security problems in AI-generated code. The rules below are the ones worth the space.
Put them in the file your tool reads
- Cursor:
.cursor/rulesorAGENTS.md - GitHub Copilot:
.github/copilot-instructions.md - Claude Code:
CLAUDE.md - Codex:
AGENTS.md
If you use more than one tool, keep the shared rules in AGENTS.md and point the tool-specific files at it. What matters is that the rules land in the file the tool actually loads.
Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.
See a live scan →The rules worth adding
Keep each one short and specific. A blunt rule the tool can apply every time beats a paragraph it half-follows. These four cover the patterns behind most of the real damage.
## Security rules Secrets: never write API keys, tokens, passwords, or connection strings as literal values. Read them from environment variables (process.env.NAME). If a value is missing, reference the variable and add it to .env.example, never inline it. Authorization: every endpoint that reads or changes data must check on the server that the record belongs to the current user. A check in the UI does not count. Input handling: never build SQL, shell commands, or HTML by concatenating user input. Use parameterized queries, argument arrays, and sanitized output. Protections: do not disable, widen, or skip a security control to make something work. No rejectUnauthorized: false, no CORS origin "*", no cookies without httpOnly, secure, and sameSite.
Each rule maps to a specific, common failure. The secrets rule targets the top finding in AI-built apps, covered in the four-layer secrets setup. The authorization rule targets the IDOR pattern the tools build constantly. The input rule covers SQL injection and command injection. The protections rule targets the insecure defaults assistants reach for when they hit an error.
Be honest about what this buys you
A rule lowers how often the model reaches for the insecure pattern. It does not stop it. The model still optimizes for code that runs, so an inline key or a skipped check will still happen sometimes, just less often. This is the layer people over-trust, which is exactly why it should not be the only one. Pair it with the mechanical gates that do not depend on the model choosing well: gitignored secrets, a pre-commit secret scanner, and a scan of the whole repo on a schedule.
Put differently, the instruction file changes the odds; it does not change the guarantees. That is still worth having, because shifting the odds across thousands of small decisions removes a lot of issues before they are ever written.
Frequently asked questions
Which file does my tool actually read?
Cursor reads .cursor/rules or AGENTS.md, GitHub Copilot reads .github/copilot-instructions.md, Claude Code reads CLAUDE.md, and Codex reads AGENTS.md. Put the rules in the one your tool uses so they are in context on every request. If your team uses several tools, AGENTS.md is becoming a common shared convention, and you can keep a short tool-specific file that points to it.
Do these rules actually change what the model does?
They reduce how often it reaches for an insecure pattern; they do not eliminate it. The model still optimizes for code that runs, so a rule lowers the frequency of an inline secret or a missing check rather than guaranteeing it never happens. Treat the rules as prevention that shifts the odds in your favor, and keep a gate like a pre-commit hook and a scan for what slips through.
Won't a long list of rules dilute the important ones?
Yes, which is why short and blunt beats exhaustive. A handful of specific, high-value rules that the tool can apply consistently is worth more than a page it half-follows. Cover the few patterns that cause most of the real damage, secrets, authorization, input handling, and disabled protections, and leave the rest to review and scanning.
Is an instruction file enough on its own?
No, and treating it as enough is the common mistake. It is the first and weakest layer. It belongs alongside gitignored secrets, a pre-commit secret scanner, and a periodic scan of the whole repo. The rules make the good path more likely; the other layers catch the times the model takes the bad one anyway.
The gate the rules cannot replace
Rules protect the code you are about to write. They do nothing for what already shipped, and if you have been building with an assistant without them, assume some issues are already in there. A scan reads the repo the way an attacker's bot does and hands you the file and line for each one. Run a free scan to see what the rules would have caught, then add them so the next diff starts cleaner.