We Put Hidden Instructions in an Image and Claude Code Ran Them. Here’s Why That Should Concern You.

Image prompt injection, AI feature risk, and what security teams should be doing about it.

We’ve been curious about prompt injection for a while. Not in the abstract, theoretical sense, but in the “let’s actually build the attack and see what happens” sense. So we did.

In September 2025, we published a technical breakdown of the attack. This post is about the broader implications for security teams evaluating AI tools.

The setup was simple. We took the kind of image you would find in any repository, like a logo or a screenshot, and embedded malicious instructions inside it as text using PyRIT’s AddImageTextConverter. Then we dropped it into a git repository alongside normal project files and checked whether Claude Code would follow those instructions when a developer ran a routine query. Something like “analyze the files in this directory,” the kind of thing developers do constantly, without giving it a second thought.

It worked. Claude Code read the image, interpreted the rendered text as instructions within its LLM context, and chose to run the suggested commands. No exploit. No CVE. No vulnerability in the traditional sense, although prompt injection is increasingly recognized as its own vulnerability class (it’s LLM01 in the OWASP Top 10 for LLMs). This is an AI tool doing what AI tools do, processing input, and an attacker controlling what that input says.

You can read the full technical breakdown, including the PyRIT pipeline we used to automate and score the testing, in our AI Red Teaming Part 3 post. 

What We Found

This isn’t a story about Claude Code being an insecure product. Claude Code has meaningful security mitigations in place. It’s about a default configuration that hadn’t anticipated this specific attack vector, which is a much more common situation than outright negligence, and arguably a more important one to understand.

In our testing, the injected instructions executed 'whoami' and ifconfig without the user being prompted for permission. Both fall within Claude Code’s default allowed command set — read-only operations that the tool considers safe to run without explicit approval. It’s worth noting that ifconfig is allowed by default, while the newer ip commands require approval. This is the kind of inconsistency worth auditing in your own deployment. We also tested commands that would require user approval and, to Claude Code’s credit, those were blocked or prompted correctly.

So, from a default installation, the immediate impact is information disclosure: system user context and network configuration, triggered by something as innocent as analyzing a repository. That alone is worth knowing about. But the risk compounds from there. Combine it with a user environment that has broader permissions configured, or with social engineering techniques like Lies-In-The-Loop that trick a user into approving additional commands, and you’re looking at something considerably worse.

The only requirement for the attack to work was for the victim’s Claude Code session to access the poisoned file. That’s a low bar.

For teams using Claude Code or evaluating it for broader deployment, the mitigations exist and they work within their defined scope. The gap is in default configurations not being designed with adversarial image input in mind. That’s worth knowing, and worth testing in your specific environment before assuming the defaults are sufficient.

Why This Matters Beyond Claude Code

Prompt injection via image input isn’t a Claude Code problem. It’s a problem for any AI system that processes user-controlled content without adequate input validation, and that describes a rapidly growing category of tools.

Think about what’s getting AI features right now: code assistants, document summarization tools, customer support chatbots, and AI agents that send emails or query internal systems on a user’s behalf. Each of these has an input surface. Each of them, to varying degrees, follows instructions found in that input. Most of them haven’t been adversarially tested for prompt injection specifically.

To put this into context, imagine a contractor submits a pull request that includes a logo image with injection text rendered onto it. A developer on your team runs Claude Code to review the PR. The image gets processed, the instructions execute, and your developer never saw anything suspicious — they were just reviewing code. That’s the scenario. It doesn’t require a sophisticated attacker. It requires someone who has read this blog post.

We tested Claude Code because it’s a tool we use and wanted to understand it better. The methodology of using PyRIT to build a testing pipeline, automate prompt variants, and score results systematically can be directly applied to other AI targets. 

What to Add to Your AI Procurement Checklist

One practical consequence of AI features shipping fast is that standard vendor security assessments don’t necessarily cover them well. A SOC 2 report covers the vendor’s infrastructure. It doesn’t say anything about what their AI feature does with your data once it leaves that infrastructure. Third-party model providers, training data policies, and prompt injection testing don’t show up in the standard assessment. You have to specifically ask for it.

These questions are worth adding to your standard vendor questionnaire now, before the next procurement cycle:

• Where does AI processing happen? Is it on your infrastructure, or routed to a third-party model provider?
• If a third party is involved, what are their data retention and training policies for data processed through their API?
• Has the AI feature specifically been tested for prompt injection and adversarial input separate from the base product security assessment?
• What commands, APIs, or internal systems can the AI feature access, and what are the explicit permission limits?
• How are new AI capabilities disclosed to customers when added to existing products post-purchase?

Most vendors won’t have polished answers to all of these yet. That’s fine. The goal right now is to start building the baseline and understand where the gaps are, not to disqualify vendors who are still figuring it out.

Where to Start if You Want to Build This Capability

The right starting point depends on where your team is. There’s no single tool that works for everyone. If you’re just getting started, here’s what we would recommend: 

Start manual. Open the AI tool, try to inject an instruction into whatever input it accepts, and see if it follows it. No setup, no tooling, immediate feedback. Try this before anything else. 

Second, read the OWASP Top 10 for LLMs. It’s the clearest map of AI-specific risk categories available, written for security practitioners rather than AI researchers. It’ll give you language for what you’re finding.

Third, try PyRIT when manual testing starts feeling repetitive. It’s Microsoft’s open source AI red teaming framework that handles automation so you can focus on the interesting parts. Our Part 1 post walks through the setup and a first challenge end-to-end. It has a learning curve, but it’s worth it once you’re past the basics.

Finally, look at Garak. Different tool, different approach to probing model behavior. Some practitioners prefer it; at the very least, it’s worth knowing it exists.

Treat AI input surfaces the same way you’d treat any other user-facing input: assume someone will eventually try to abuse it, understand what the system can do when it follows those instructions, and test whether your controls would catch it. That framing applies regardless of which tools you use to get there. 

What to Fix

First, figure out what the AI tool can actually do. What can it run, read, or reach without asking for permission? That’s your starting point. Anything your team does not need is a risk you can cut by changing the configuration.

Second, think about what ends up in your working directories. The attack we ran worked because one poisoned file was sitting where Claude Code was told to look. If your team uses AI tools to analyze code repositories that pull in third-party dependencies or external content, that’s a similar setup. 

Third, check the default allowed command set and verify the approval prompts actually fire the way they’re supposed to. Default installations behave one way; customized ones sometimes don’t. Test your actual environment, not the documentation.

None of this requires a dedicated project. Most of it is an afternoon of configuration review. The point is to do it before someone else does it for you.

Which AI Tools to Test First

Start with whatever can do the most damage if it goes wrong, especially if someone else is controlling the instructions. We’re talking about tools that can take action: run commands, write files, call APIs, and send communications. 

Then move to tools that can surface sensitive data even if they can’t act on it, such as document summarization, internal search, and customer-facing chatbots with account access. Lower urgency, still worth finding.

You can save the read-only, no-backend tools for last. They’re not zero risk,  but they’re not where you need to start.

Within each tier, lean toward newer implementations first. Fresh AI features get less scrutiny than products that have been in production for years. That’s usually where the gaps are.

The Bottom Line

We want to be clear that the point of publishing this isn’t to claim Claude Code is broken. It isn’t. The point is that even well-built tools have edge cases that weren’t anticipated in their default configurations, and the only way to find those edge cases is to look for them.

That’s true of the AI tools you’re evaluating for procurement. It’s true of the ones already running in your environment. And it’s probably true of tools your staff is using that you don’t have visibility into yet.

The risk doesn’t show up in a vulnerability scanner. It shows up when someone with the right methodology goes looking for it. We’d rather that someone be you.

Our full PyRIT series, including setup, methodology, and real targets — is on the BreakPoint Labs blog. If you want to talk through AI testing scope for your environment, get in touch.

Frequently Asked Questions