Your AI Instruction Files Are Code

The essentials in 5 points

• An agent instruction file (CLAUDE.md, skill, config) downloaded from the internet is executable code, not documentation.
• The AI supply chain has four real vectors: compromised dependencies, malicious MCP servers, invisible Unicode, anti-scanner packages.
• An AI scanner that refuses to analyze a file is an alert, not a green light. Never let it through by default.
• The defense rests on three rules: admission control before installation, least privilege, human review on refusals.
• This article complements Securing AI Agents in the Enterprise: the supply chain is its upstream layer.

The short answer

An AI agent does not just read its configuration files, it executes them. A CLAUDE.md, a skill, or an agent configuration pulled off the internet is not documentation: it is instructions the model applies, sometimes hidden instructions the human eye does not see.

The practical conclusion fits in one sentence: every instruction file from an external source must be audited like code, before it enters your environment.

The AI agent supply chain became one of the ecosystem’s major attack surfaces in 2026. It is defended with principles familiar from software development, adapted to the specifics of agents: an admission control that filters every incoming component, least privilege applied to each connector, and a firm rule on scan refusals.

The rest of this article details the real vectors and a six-point checklist.

An instruction file is executable code

The line between code and data collapses with agents. A conventional program keeps them apart: code decides, data is processed. An AI agent, by contrast, interprets in natural language everything it reads, including the content of its own configuration files.

An instruction slipped into a CLAUDE.md or a skill becomes an action the agent executes, on the same footing as a line of code.

This shift has a direct effect on security. In the spring of 2026, a documented attack technique consisted of hiding malicious code inside agent rule files by means of invisible Unicode characters: zero-width characters, homoglyphs, Unicode tags. The agent reads the concealed instructions and applies them, while the human reviewing the file sees nothing unusual.

An associated campaign spread dozens of malicious packages across public registries, released in hundreds of versions and built to steal keys and tokens.

The operating rule that follows is clear: treat agent instruction files as executable code, not as documentation. That means auditing them, pinning their version, and inspecting every external file for invisible Unicode before bringing it into a working environment.

The four real vectors

Compromised dependencies. The textbook case remains the attack on a popular LLM library in the first quarter of 2026. A simple install of the package was enough to exfiltrate SSH keys, cloud credentials, orchestration configurations, and every environment variable. There was no need even to import the module or use it: the malicious code ran at install time. The AI ecosystem rests on deep dependency chains, and a single compromised link grants access to the entire infrastructure.

Malicious MCP servers. The MCP protocol connects agents to external servers that provide them with tools and data. The problem is implicit trust: an agent treats an MCP server’s responses as being as reliable as those of a safe source. A compromised server can therefore inject instructions or booby-trapped content straight into the agent’s context. Every connected server widens the attack surface, which calls for isolating servers and verifying their provenance.

Invisible Unicode. Described above, this vector deserves a separate mention, because it defeats human review. A file can look perfectly harmless on reading and still carry active instructions for the agent. Only a tooled inspection, one that surfaces control characters and suspicious Unicode ranges, can detect them.

Anti-scanner packages. The most recent generation of malicious code targets defenders themselves. Packages embed comments that amount to prompt injection, content designed to provoke a refusal, and deliberately obfuscated code, in order to find the cases where AI-assisted security scanners refuse, truncate, or miss the analysis. The malware turns the defending model’s own safeguards against it: its refusal to analyze becomes a way to evade detection.

The three hygiene rules

Admission control before installation. Nothing enters the fleet without passing through a checkpoint. Every package, MCP server, skill, or instruction file is considered untrusted until proven otherwise: verified source, scan performed, Unicode inspected, version pinned. It is the equivalent, for AI components, of the quality control already applied to software dependencies.

Least privilege. A component gets only the access strictly needed for its function. An MCP server that reads documents does not need to write to a production database. This discipline bounds the impact of a component that turns out to be compromised: even booby-trapped, it can only act within the perimeter it was granted.

A scan refusal is an alert. This is the most counterintuitive and most important point. When an AI scanner refuses to analyze a file, the temptation is to treat the absence of a result as an absence of danger, and to let it through. That is exactly the behavior anti-scanner packages aim for. A refusal must always route to human review, never to a fail-open.

The six-point checklist

1. Inventory. List the agents in service, their dependencies, their MCP servers, and the origin of their instruction files. Without this stocktaking, everything else is done blind.
2. Filter at admission. Ban any direct installation from an unverified source. Run every incoming component through a control before it executes.
3. Pin versions. Freeze the versions of dependencies and components so an update cannot silently introduce a compromised package.
4. Inspect Unicode. Run every external instruction file through a tool that surfaces invisible characters before bringing it into an environment.
5. Apply least privilege. Restrict the access of every connector and every MCP server to the strict minimum, and isolate critical components.
6. Treat refusals as alerts. Route every scanner refusal or analysis failure to human review. Never let it through by default.

Where to start

If your teams already use AI agents, the first step is an inventory of their supply chain: dependencies, MCP servers, provenance of instruction files. This stocktaking reveals the real surface, runs without interrupting production, and leads to a prioritized list of fixes. It precedes setting up admission control and least privilege.

Colombani.ai carries out this kind of AI security audit (supply chain review, agent-assisted penetration testing), covered by professional liability insurance dedicated to penetration testing, and trains technical teams through the AI agent security course (admission control, OWASP LLM Top 10, red teaming), delivered by a Qualiopi-certified provider and eligible for OPCO funding.

For securing agents at runtime, see also Securing AI Agents in the Enterprise.

Sources

• OWASP, Top 10 for Large Language Model Applications
• NIST, AI Risk Management Framework
• Anthropic, Building trustworthy agents