Review the instructions an assistant actually consumes
Hidden Unicode can separate a rules file’s visible text from its consumed instructions. Review character visibility, provenance and authority before adoption.
By 
Paul. AI and agentic engineering
A coding-assistant rules file deserves review as an input that can influence generated code. Its rendered appearance is only one view of that input. When hidden characters conceal instructions, approving the visible text may approve less than the assistant consumes. Review both character visibility and provenance before allowing a borrowed rules file to shape work in a repository.
Looking back from November 2026, GitHub's 1 May 2025 announcement introduced a warning for files containing hidden Unicode text on github.com. GitHub advised opening flagged files in an editor that displays the characters and checking whether they were necessary. That was a visibility improvement, not a claim that a warning could establish the safety of every instruction in a file.
A different reader can receive a different text
Source review usually assumes that a reviewer can see the meaningful content. Some Unicode characters challenge that assumption because displayed text can differ from the underlying character sequence. In a rules file, the distinction matters even when the file is never compiled: the consumer may be an assistant interpreting instructions alongside source code.
The warning should therefore trigger inspection of the actual content. A reviewer needs a representation that makes hidden characters apparent, together with the surrounding text and change history. Merely looking at a screenshot of the file repeats the visibility problem. A clean-looking rendered paragraph cannot prove that its underlying sequence contains only that paragraph.
The related Pillar Security report, dated 18 March 2025, described what its researchers called a Rules File Backdoor. They reported demonstrations involving GitHub Copilot and Cursor, with concealed instructions influencing generated code. These are the security vendor's reported demonstrations. They do not establish that every model, assistant version or configuration obeys every such payload.
That evidence supports a narrower operational conclusion: instruction files can be an attack surface, and visual review alone may be insufficient. It does not supply an incidence rate, prove compromise in a particular repository or justify treating all Unicode as malicious. Keep the demonstrated mechanism separate from predictions about its prevalence.
Visibility and authority need separate decisions
After exposing the characters, the reviewer still has to decide whether the instructions belong in the project. Fully visible text could ask an assistant to weaken authentication or quietly introduce an external dependency. Removing concealment would make that request easier to notice, but would not make it acceptable.
Provenance answers another part of the decision. Identify where the file came from, who changed it and which revision the project reviewed. A copied community example, a dependency's documentation and a project's approved local rules have different origins. Their filenames can look equally authoritative to a hurried reader. The adoption process must supply the distinction the filename cannot.
Treat retrieved instructions and examples as untrusted material while evaluating them. A research page that includes an attack sample is evidence to inspect, not an instruction to execute. Copying that sample into an active rules location to see what happens would create a new experiment with its own permissions and consequences. Understanding the published mechanism does not require performing that experiment.
An illustrative review could compare a proposed rules-file change in a character-revealing editor with its ordinary rendered view. The reviewer would identify the source, explain each non-obvious character and approve the intended instruction scope. That is a suggested review procedure, not a security test performed here or a guarantee that one representation catches every deceptive construction.
Preserve useful text without granting it automatic trust
The strongest counterargument is that Unicode supports legitimate writing, and shared instruction files can capture useful conventions. A policy that rejects every unfamiliar character or every borrowed example could discard necessary language support and make collaboration harder. It could also push people toward unreviewed personal copies, weakening visibility further.
A better rule distinguishes unexplained concealment from legitimate content. Keep required characters when their purpose is understood. Review instructions for the authority they request, regardless of alphabet. A file with ordinary visible text still needs scrutiny if it changes where code may be fetched, what commands may run or who may approve consequential actions.
The absence of a platform warning is not a complete review result. A warning mechanism has a defined scope, while problematic instructions can be entirely visible. Conversely, a warning is not a finding of malicious intent. Both conclusions would overstate what a character-visibility signal can tell the team.
This article concerns the path by which repository guidance becomes an assistant input. That differs from deciding which tools an already running assistant may invoke. Restricting tools can limit consequences, but it cannot make an unseen instruction visible to a reviewer. The two decisions can support one another without becoming interchangeable controls.
For custom software development, include instruction-file changes in the review that already governs consequential repository changes. Record the reviewed revision and keep responsibility for adopting outside guidance with an identifiable person. The practical deliverable is a file whose real content and intended authority the team can explain, rather than a visually reassuring page that nobody has compared with the consumed input.