A rules file is a short text file in your repository that tells an assistant how your project wants code written. Put in dependency rules, secret handling, authorization expectations and test requirements. It improves defaults but guarantees nothing, so keep your reviews and scanners.
What it is
Most assistants can read project level instructions from a file in the repository. The exact name and format differ by tool, so check your tool's documentation. The content is plain language: do this, never do that.
What to include
Dependencies
- Do not add a package without stating why and naming the registry page.
- Prefer the standard library or existing dependencies.
- Never run install commands without asking.
Secrets
- Never write real keys, tokens or passwords into any file.
- Read credentials from environment variables, using placeholders in examples.
Authorization and input
- Every route that accepts an identifier must check ownership or role on the server.
- Use parameterized queries. Never build SQL, shell commands or file paths from raw input.
Errors and logs
- Do not return internal error detail to users.
- Never log tokens, passwords or personal data.
Tests
- For each new route, add a test for the wrong user and an unauthenticated caller.
Scope
- Change only files related to the task and list any others you touched.
Keep it short and specific
A long vague file gets ignored. Ten concrete rules beat fifty general ones. Use examples from your own codebase.
What it cannot do
A rules file is an instruction, not a control. A model can miss or misread it, and a long conversation can push it out of attention. OWASP notes that constraining behavior through prompts is one mitigation among several and that no foolproof prevention of prompt injection is known. Enforce the important rules outside the model: required reviews, dependency checks, secret scanning.
Review the file itself
Anyone who can edit the rules file can change what the assistant does. Treat changes to it like changes to a CI workflow: require review, and look closely at pull requests from outside contributors. Instruction files from untrusted sources should not be loaded without reading them.
Safeguard's policies, gates and guardrails are one way to enforce rules where they cannot be talked around.
Testing the file
After writing the rules, test them. Ask the assistant to add a route that takes an identifier, and see whether it includes an ownership check. Ask it to add a library and see whether it explains why. If it ignores a rule, make that rule shorter and more concrete, and move it nearer the top.
Quick check
Is a rules file enough to make AI output secure?
No. It nudges the model, which helps, but you still need review, tests and automated scans to catch what it misses.
Sources
Last reviewed: 19 October 2026.
