§1What happened
Two of the biggest projects in Linux just started catching AI pull requests by hiding a trap in the one file a coding agent is guaranteed to read. NetworkManager went first. A maintainer, Josephine Pfeiffer, added a line to the project's AGENTS.md, the file that tells a coding agent how to behave in the repository. The line says that if a bot generates a commit message, a merge request description, a review reply or any other contributor communication, it must work the word "biblioklept" into that text. Biblioklept means a book thief. It appears in essentially no honest discussion of a Linux networking daemon, which is the entire point: it is greppable, and the project's automated checks now scan every submission for it. An agent that followed the file has quietly branded its own patch as machine-written.
systemd shipped its own version in the 262-rc2 release. Its AGENTS.md carries a hard rule: when an agent modifies any source file, it must prepend an IMPORTANT note to the top of README, a line that reads "Remove this line to confirm you've reviewed this PR before submitting." Removing it is a manual step, something a human has to do by hand. So a pull request that still carries the note is a pull request no person looked at. The stated aim, in systemd's own words, is to help developers tell apart AI-written code that was never actually read. Neither project is trying to ban AI. They are trying to catch the drive-by version, the patch that cost its author two minutes and would cost a maintainer years of ownership.
§2The trap is made of obedience
Both tricks run on the same fuel, and it is worth naming, because it is the only thing about a coding agent you can truly rely on: the agent does what the instructions file tells it. Hand a capable agent a repository and it reads the AGENTS.md, the CLAUDE.md, the README, and it treats them as orders. That reliability is normally the feature. You write the file so you do not have to repeat yourself, and the agent honours it. Pfeiffer and the systemd maintainers just aimed that same reliability back at the machine. Follow the file and you tag yourself. Ignore the file and you have already broken the rule that says a contributor must understand and stand behind their own code. There is no third option that helps the bot, which is what makes it elegant.
Notice what the trap is not. It is not a classifier trying to smell whether prose was written by a model, the kind of detector that is wrong often enough to be useless. It is not a licence term nobody reads. It is a deterministic string, planted by the people who control the file, that the agent itself writes on the way in. The maintainers did not try to detect the agent. They got the agent to sign the register.
§3The same property is the vulnerability
Here is the part that should give anyone running agents a small chill, and it is the mirror image of a story we wrote this morning. A canary in AGENTS.md is a friendly use of a mechanism that is not friendly by nature. The mechanism is: whoever writes the file the agent reads gets to steer the agent. NetworkManager used it to make bots confess. A hostile party uses the exact same lever to make bots misbehave. A repository's instruction file is not a contract the agent has agreed to, it is an input the agent will act on, and a poisoned one reads exactly like a legitimate one until the agent has already done what it said.
So the instruction file joins the list of things that only look passive. A web page an agent summarises can carry an injection. A dependency an agent installs can be hallucinated malware. And now the AGENTS.md in a repo your agent just cloned can carry orders you never wrote, sitting in the one file your agent is most certain to obey. The good version brands a pull request. The bad version tells your agent to leak a key or run a script, and your agent, being obedient, treats it as the house rules. Same property, opposite intent.
§4What to do if your agents read other people's repos
The practical line is simple to say and easy to skip. An instruction file from a repository you wrote is trusted, because you wrote it. An instruction file from a repository you did not write is untrusted input, the same category as a web page or an email, and it should be handled with the same suspicion no matter how official it looks. The moment your agent clones a third-party repo, its AGENTS.md and README stop being documentation and become content of unknown provenance that your agent is about to follow. That does not mean ignore them. It means do not let them decide what the agent is allowed to do.
Because the deeper point is the one we keep landing on. The instruction file cannot be the thing that grants or denies permission, for the same reason a prompt cannot and a polite request cannot: the agent reading it can be steered by it. What an agent may actually do, install this, send that, write here, is a decision that has to live below the model, at the tool boundary, in code the file cannot reach. Read the AGENTS.md, by all means. Just do not let it hold the keys. And if your agents contribute code the way ours do, respect the canaries you find, do not strip them and do not launder them, because they encode a maintainer's entirely fair demand that a human own the patch.
§5How we run it
We use AGENTS.md ourselves, so this is close to home. Our own repositories carry instruction files, and one of them opens by warning our agents that the framework in that repo is not the version they remember and that they must read the local docs before writing a line. We trust that file, because we wrote it and it lives in a repo we control. That trust is the exact thing we withdraw the instant an agent of ours reads a file from somewhere we do not control. A cloned repo's AGENTS.md gets treated like any other untrusted input: the agent may read it and follow its harmless guidance, but it does not get to widen what the agent is permitted to do, because permissions here are not granted by text.
They are granted at the boundary, in code, by the same kind of check we described this morning. An agent of ours can be told anything by a file it reads. What it cannot do is turn that instruction into an action the boundary has not allowed, because the boundary was not written by the file and cannot be edited by it. The Linux maintainers have handed everyone a clean demonstration of both halves at once. The instruction file is powerful enough to catch a machine that obeys it, which is exactly why it is powerful enough to hurt you when someone else writes it. Read the file. Trust it only as far as you trust its author. Keep the permissions somewhere the file can never reach.