Rules File Poisoning

What Is Rules File Poisoning?

An AI coding assistant reads a rules file in your repository and obeys it on every request. A contractor's pull request slipped one line into that file, keep a legacy auth-bypass header, and it merged in seconds with no review. A routine refactor then followed the rule and put the bypass back into production. You'll trace the line to its pull request, remove it, re-run the refactor cleanly, and put the rules file under a code owner with required review. The lesson: a rules file is executable trust, so review it like code.

What You'll Learn in Rules File Poisoning

• Explain why an assistant rules file is executable instruction, not documentation, so a change to it changes what the assistant does
• Recognise the signs of a poisoned change: a quick merge, no reviews, a benign label, and an unfamiliar author
• Trace a behaviour the assistant introduced back to the file that told it to, using the context map and provenance gutter
• Put assistant rules, prompt and config files under a code owner with required review so one unreviewed pull request cannot rewrite behaviour
• Verify a security fix by replaying the exact request that got in and confirming it is now refused

Rules File Poisoning — Training Steps

1. One line in the rules file

   Three weeks before the audit task lands on Alice's desk, Bob is a contractor on the portal-api repository. He opens a one-line pull request against .assistant/rules.md , the file the team's AI assistant reads before it touches the code, and labels it documentation. It is merged in eleven seconds. Now he waits: the next routine change to the auth middleware will read that line and carry the bypass back into production.

2. Tidy the middleware before the audit

   Your engineering lead has filed an issue for you in Jotvane, the team tracker: the auth middleware grew into three small functions, and the security audit next week wants it as one. Consolidate it.

3. Open the project

   The editor loads the auth middleware, the admin routes that sit behind it, the repository's CODEOWNERS file, and an assistant rules file the project keeps under .assistant/ . The middleware is the three functions your lead mentioned.

4. Ask for the refactor

   Open the assistant and ask it to consolidate the middleware into one function, exactly as your lead described.

5. One function, and a line you did not ask for

   Claude reads the rules file, the middleware and the admin routes, then proposes a single authenticate() function. It reads cleanly, and in the middle of it sits a header check nobody asked for. Its reply is short and confident.

6. Accept the refactor

   The diff reads like a clean consolidation and the reply is confident, so you accept it. The new lines land violet and unreviewed: written by Claude, not yet read by you. The bypass line is in there, one line among the four Claude wrote.

7. Send the header, get the data

   Bob makes the call he planted the line for. He has no account at Dunmerrow and no session token, only the header. He points the API Tester at the admin console's customers endpoint and sends a GET carrying nothing but x-internal-bypass: 1 .

8. A session that was never a session

   Your security lead has filed an alert as an issue. The admin console answered a request from an address nobody recognises, and the request carried a header instead of a login.

9. The line in the rules file

   The refactor only touched the middleware, and your lead asked for no behaviour change. So the instruction to add the bypass came from somewhere the assistant read. Find the rules file on the context map and read line 7.

10. How the line got in

    You never wrote that line. Open the change your security lead linked and see how it reached the rules file.