Your AI Agent Just Read a Malicious File. Here's What Happened Next.
Written by Derek Chua, digital marketing consultant and founder of Magnified Technologies. He runs a production multi-agent AI system for content creation and client work, and thinks hard about where these systems can go wrong.
I run multiple AI agents on a daily basis. They read files, browse the web, execute code, and push content live. Most of the time, they do exactly what I want. But a security disclosure published this week reminded me of something uncomfortable: an AI agent that reads data you did not write is an agent that can be manipulated by whoever wrote that data.
This is not theoretical. It happened. And the consequences were severe.
Key Takeaway: A hidden instruction inside a GitHub README file caused Snowflake's AI coding agent to download and execute malicious scripts, bypassing human approval entirely. If your business uses AI agents that read external content (web pages, documents, emails, third-party databases), you are exposed to the same class of attack. The patch exists, but the lesson is broader than any single product.
What Happened
On February 2, 2026, Snowflake released Cortex Code: a command-line AI coding agent built for developers who work with Snowflake databases. Think of it as similar to Claude Code or GitHub Copilot Agent, but with native access to run SQL directly in Snowflake.
Three days after launch, a security firm called PromptArmor found a serious flaw.
Here is the attack chain they demonstrated:
A developer asks Cortex Code to help review an open-source GitHub repository they found online. The agent browses to the repository and starts reading the README file. At the bottom of that README, an attacker has hidden a specially crafted instruction. The agent reads it, interprets it as a legitimate directive, and executes a command designed to download and run a malicious script from an external server.
That script then used the developer's active Snowflake credentials to exfiltrate data, drop tables, and add backdoor user accounts. All without the developer ever approving it.
Snowflake's security team patched the vulnerability on February 28, and PromptArmor coordinated public disclosure on March 16. The vulnerability was in how Cortex validated shell commands: it filtered certain dangerous patterns but missed process substitution, a technique where code hidden inside a seemingly benign command gets executed silently.
The attack worked roughly half the time in testing. For a security breach, that is a high success rate.
Why This Matters Beyond Snowflake
Snowflake fixed their bug. But the underlying attack type, called prompt injection, is not a Snowflake problem. It is an architecture problem that affects every AI agent that reads untrusted content.
An AI agent is fundamentally a language model following instructions. Those instructions can come from you, or they can come from data the agent encounters in the world. When an agent reads a web page, opens an email attachment, queries a database, or processes an uploaded document, it is ingesting potential instructions from whoever wrote that content. If an attacker puts hidden text into any of those sources, the agent may follow it.
Simon Willison, one of the most careful AI security thinkers writing today, covered this disclosure and made a point worth quoting directly: he is deeply skeptical of allow-lists that filter specific dangerous commands, because they are "inherently unreliable." His preference is to treat any command an agent issues as if it has the full privileges of the underlying process, and to contain the agent inside a deterministic sandbox that sits outside the agent's own layer entirely.
That is a more conservative stance than most AI vendors take. But the Snowflake incident suggests it is the right one.
There was another detail in the PromptArmor report that I have been thinking about. Cortex invoked sub-agents to explore the repository. One of those sub-agents encountered the injection and ran the malicious command. By the time the report propagated back up to the main agent, the context had been lost. The main agent then told the user: "A malicious command was found. Do not run it."
The command had already run.
This is a specific failure mode of multi-agent systems that I work with every day. When agents spawn other agents, and those sub-agents take actions, the top-level agent may not have full visibility into what happened. The "human in the loop" at the end of the chain may be receiving a summary that omits what actually occurred.
What SMEs Using AI Agents Need to Check
Most businesses deploying AI tools right now are not running bespoke agent pipelines. They are using off-the-shelf products: Claude Code, GitHub Copilot, Cursor, Microsoft Copilot with company data integrations, or AI tools built into their SaaS platforms.
The risk is real for all of them if those tools read external content. Here is a practical framework.
Understand what your agent reads. The most important question is not which tool you use. It is what data that tool has access to. An agent that only reads your own internal documents and talks to no external sources carries very low prompt injection risk. An agent that browses the web, processes incoming emails, or reads third-party reports carries meaningful risk.
Check permission scope. If your AI coding agent or automation tool has database credentials, it should have the minimum permissions needed. Read access where write access is not required. Named accounts with restricted scope rather than admin credentials. This does not prevent the attack, but it limits the blast radius.
Treat "human in the loop" as necessary but not sufficient. Approval flows are valuable. But as the Snowflake case showed, a sub-agent can run a command before the main agent has a chance to flag it. A human approving the final output may be approving something that already happened in an intermediate step.
Know what version of agentic tools your team is running. Snowflake's fix was in Cortex Code 1.0.25, released February 28. If someone on your team is still running 1.0.24, they are unpatched. Update cadence matters. For cloud-based tools, this is usually handled automatically. For local CLI tools, it is not.
At Magnified, we approach this by running agents with the narrowest possible file and network access relative to the task. Our content agents read from a specific set of monitored sources, not the open web. Where agents do need to read external content, that content goes through a layer before it reaches the agent. This is not foolproof, but it reduces the attack surface considerably.
Derek's Take
I want to be clear about something. I am not telling you to stop using AI agents. I use them constantly. They have made my business faster and more capable than it would be otherwise.
But I see a pattern in how these tools get adopted. Someone tries Claude Code or Copilot, has a great experience, and starts giving it more access. More file permissions. More API credentials. More ability to act autonomously. This happens gradually, informally, without a security review.
That is fine when you are experimenting with your own codebase. It is not fine when the agent is reading external content with credentials that matter.
The Snowflake disclosure is a concrete, documented example of what can go wrong. A README file. An agent trusted to read it. Credentials used to exfiltrate data. The whole chain, end to end, in a production enterprise tool.
The fix is not to avoid AI agents. The fix is to deploy them the same way you would deploy any system with access to your data: with defined scope, minimum permissions, clear audit trails, and the understanding that anything the agent reads is a potential attack surface.
Hype tells you AI agents will just handle things. Security tells you to ask exactly what they are handling and for whom.
One Action for This Week
Spend 15 minutes listing every AI agent or AI-powered tool your team uses that has credentials (database logins, API keys, file system access). For each one, ask two questions: What external data does this agent read? What could it do with the credentials it has?
You do not need to shut anything down. You just need to know what you are running.
Frequently Asked Questions
What is prompt injection and why does it matter for businesses using AI? Prompt injection is when an attacker embeds hidden instructions inside data that an AI agent reads, causing it to follow those instructions instead of (or in addition to) the legitimate task. It matters because AI agents increasingly read external content, including web pages, uploaded files, emails, and third-party data. Any of that content can contain an injection. The risk scales with how much access and autonomy the agent has.
Was this just a Snowflake problem, or does it affect other AI tools? The specific bug was in Snowflake Cortex Code and has been patched. But prompt injection as an attack class affects any AI agent that reads untrusted content, regardless of the vendor. Claude Code, GitHub Copilot Agent, Cursor, and similar tools are all theoretically susceptible when they process content from outside your controlled environment. Each product has different mitigations, but none are fully immune.
How do I know if the AI tools my team uses are vulnerable? The key factor is what external data each tool reads and what permissions it has. A tool with read-only access to internal documents carries much lower risk than one with database write credentials that also browses the web. Check the changelog or security advisories for any agentic CLI tools your team runs locally, as these do not always update automatically.
Should I stop using AI agents in my business because of this risk? No. The risk is manageable with the right approach: limit what data agents can read, scope credentials to minimum required permissions, keep tools updated, and understand that human-in-the-loop approval catches some but not all risks in multi-agent setups. The Snowflake case is a useful reminder to deploy AI agents with the same deliberateness you would apply to any system with access to your data.