When the agent is in your pipeline, the text it reads is an attack surface

A new shape of CI/CD attack, disclosed this week

On June 5, Microsoft's Defender security research team published an analysis of a vulnerability in Anthropic's Claude Code GitHub Action. The short version: an AI coding agent running inside a CI/CD workflow could be steered by prompt injection, through content its Read tool ingested, into exposing the workflow's secrets. Anthropic addressed it, and to be clear up front, this was responsible disclosure of a specific, fixed issue, not a live fire we are sounding an alarm about.

We are writing about it anyway, because the specific bug matters far less than the class it illustrates, and the class is going to show up everywhere AI agents are wired into pipelines over the next year.

Here is the shift. Last month we wrote that your CI pipeline is an attack surface because untrusted code runs inside it with real credentials. That is still true. But when you add an autonomous agent to that pipeline, you introduce a second, less obvious attack surface: the untrusted text the agent reads. An issue title, a pull request comment, a code comment, a file in the repo, a dependency's README. To a traditional CI step, that text is inert data. To an agent, it can be an instruction.

Why an agent in the pipeline is a different problem

A normal CI step does exactly what its YAML says. An agent decides what to do based on what it reads, and it carries tools and credentials to act on those decisions. That combination is the whole risk.

The agent holds power and reads attacker-controlled words in the same breath

It can read your repo and your secrets, it can call tools, and it forms its next action from text that an outsider may have written. A pull request from a fork, an issue filed by anyone, a poisoned dependency file. The exploit is not malicious code that runs; it is malicious language that persuades.

Prompt injection is not a bug you patch once

It is a property of mixing trusted instructions and untrusted content in the same context window. You reduce it with architecture, not with a single fix. Treating "we patched that one" as "we are safe" is the mistake.

The blast radius is whatever the agent can touch

If the agent's identity can read every secret in the runner and make outbound calls, then a successful injection can read every secret and make outbound calls. The damage is bounded by the agent's privileges, not by the cleverness of the prompt.

This is why Microsoft's red team, in a companion piece the day before, published an updated taxonomy of failure modes in agentic AI systems after a year of red teaming. The industry is now cataloguing these failures as a category, not treating each as a novelty. That is the signal worth reading: agentic security is becoming its own discipline.

How we think about putting an agent near production

There is no product that makes this go away, and anyone selling one as a silver bullet is the tell. There is a posture, and it is the same posture we build our own agents to. We will name it concretely, because it is exactly how the Solon family of agents we build is designed.

Treat every input the agent reads as untrusted

An issue, a comment, a file, a tool response. None of it is an instruction from you. The agent should be built so that content it reads cannot silently become a command it obeys. This is the architectural core, and it is hard, which is why the rest of the list exists to contain the failure when this is imperfect.

Give the agent the least privilege that still lets it do its job, on a separate and short-lived credential. An agent that only needs to read should not hold a write credential. An agent that needs to write one narrow class of change should hold a credential scoped to exactly that, defaulting off, requested at the moment of use, expired after. The point is the same as OIDC for CI: a stolen or hijacked capability should be nearly worthless. When we built our write agent, the write credential is separate, defaults off, and is granted only for the specific change class, precisely so an injected instruction has almost nothing to grab.

Keep a human between the agent and the consequential action

Reading and proposing can be autonomous. Mutating your infrastructure, moving money, sending mail, exfiltrating data, those deserve a gate. Our write agent dry-runs by default, re-reads the live state at apply time, refuses anything that could lock you out, and records every action in a tamper-evident log. None of that trusts the model to have been un-injected; it assumes the model can be wrong and contains the damage.

Separate the two dangerous powers

The sharpest version of this attack pairs the ability to read secrets with the ability to send data out. If the same agent context can both read a secret and make an arbitrary outbound call, injection becomes exfiltration. Splitting those, or removing the outbound path entirely, defangs the worst outcome. It is why we build agents that keep your data inside your own boundary: the outbound path attackers need is simply not there.

The thread through all of these: do not rely on the agent being un-injectable. Assume it can be persuaded, and build so that a persuaded agent cannot do much harm.

What we are not claiming

This is not a claim that Claude Code, or AI agents in CI, are unsafe to use. We build on Claude every day. A responsibly disclosed and fixed issue is the system working, and an agent in your pipeline can be run safely with the posture above. The danger is running one without it.

This is not a claim that prompt injection is new or solved. It is a known, open, hard problem. Anyone who tells you their product eliminates it deserves the same suspicion as anyone selling a box that ends supply-chain risk.

This is not a claim that every team needs the same depth. An agent that drafts comments on a private repo and an agent that can touch production are different risks. Match the controls to what the agent can actually reach.

And about ourselves: holding this posture is ongoing work. We build our own agents fail-closed, least-privilege, human-gated on consequential actions, and we treat their inputs as hostile by default, because we would rather assume our own agents can be fooled than find out they can.

One-sentence takeaway

When you put an AI agent in your pipeline, the text it reads becomes an attack surface, and the defense is not a smarter model but an architecture that assumes the model can be fooled: least-privilege and short-lived credentials, a human gate on consequential actions, and never letting one agent both read secrets and phone home.