A pull request lands with a tidy bug report in the description. A bot reads it before any person does, pulls a few shell commands out of it, gets them approved, and posts the output back on the thread. The maintainer reads the whole exchange the next morning. This scenario, repeated across three major vendors' own repositories using their default configurations, reveals a fundamental flaw in how AI agents handle trust decisions.
Elad Meged, a founding engineer at Novee Security, ran that exact sequence against Claude Code Action, Gemini CLI, and Codex CLI. In every case, the agents leaked secrets—credentials, API keys, internal configuration data—despite passing all standard safety checks. Anthropic's pipeline, for example, handed over secrets without hesitation. Any organization running one of these agents out of the box carries the same exposure.
The architecture of vulnerability
An AI agent is composed of two parts: a model that generates intent, and a harness that turns that intent into shell commands, file reads, API calls, and network requests. The harness holds the approval logic, tool permissions, path restrictions, and output handling. When a workflow runs without a person checking each step—a common scenario in CI/CD pipelines—the harness becomes the security boundary.
Meged builds AI agents for automated penetration testing at Novee, and he turned the same offensive techniques back onto the agents themselves. His findings highlight a critical insight: prompt injection is just the delivery mechanism. The actual vulnerabilities lie in how the harness makes trust decisions and how those decisions compose across stages.
"A command gets approved because it looks safe. The output gets published because that's the default. Neither decision is wrong alone. Together, they're an exfiltration chain. If you're only watching the prompt layer, you never see the handoff where one 'safe' decision feeds into the next," Meged explained.
Case study: Claude Code Action
Meged reported multiple findings against Claude Code Action, the default workflow configuration for anthropics/claude-code—a package installed by millions. The pattern was revealing: he would report a finding, Anthropic would patch it, and in patching it they would redraw the line around what counted as safe. The patch itself would tell him where the boundary had moved, which told him exactly where to look next.
Anthropic awarded bounties across multiple rounds, and the company runs dozens of checks in that pipeline. Each patch closed the specific hole, but the attacks grew harder to detect each round. By the final round, Meged was recovering secrets through a channel that survived every prior fix: no outbound connection to an attacker, no writes, no logs. The data flowed out through the legitimate approval and publishing chain.
The bounty paradox
"A bounty rewards a finding, scoped to 'here's a specific bug, here's what it's worth,' so a vendor can pay generously round after round and still treat each one as isolated," Meged said. He emphasized that paying out is the right call and Anthropic treated him well, but the bounty-per-bypass model creates a perverse signal. It says 'we consider this closed' when the underlying exposure isn't.
Google's advisory for a similar issue carried a CVSS score of 10.0, the maximum severity. They titled their update "Update to the Trust Model," which Meged noted names the problem structurally rather than treating it as an isolated bug.
Google's Gemini CLI: A severity score of 10.0
Gemini CLI, hosted in the google-gemini/gemini-cli repository with more than 100,000 stars, exhibited the same class of vulnerability. Meged demonstrated the kill chain using the security configuration Google's documentation recommends for CI workflows that process untrusted input. A restriction the operator had configured went unenforced at the point of execution.
The finding was published as part of GHSA-wpqr-6v78-jr5g, with severity at the top of the CVSS scale. This indicates not just a minor oversight but a fundamental architectural flaw in how trust boundaries are enforced in agent harnesses.
OpenAI's Codex CLI: The sandbox gap
Codex CLI ships a default sandbox with every deployment. In multi-stage workflows that share a workspace, state written by one stage gets picked up as trusted context by the next. The protected path list carries a set of assumptions about what needs protecting. Those assumptions fail when an attacker can write data into a path that the sandbox considers safe but that later stages use as privileged input.
Anthropic built layers of checks into its pipeline, Google built multiple execution modes with environment sanitization, and OpenAI built a sandbox with protected paths. The defenses exist. They fail at the handoffs—the points where one stage's output becomes another stage's trusted input.
The shared architectural assumption
"A structural fix stops trusting the label and re-validates trust at the point of consumption, not just at the point of decision. Right now, harnesses make a safety call early—'this command is read-only,' 'this domain is pre-approved'—and downstream components inherit that judgment without checking whether it still holds in their context," Meged said.
He provided concrete examples: a read-only command feeding into a public output channel isn't read-only in effect. A pre-approved domain serving attacker-controlled content isn't safe in practice. The trust decision must be remade at each stage, not assumed from an earlier label.
"A single vendor can absolutely ship meaningful improvements, and some already have after our disclosures. But the pattern repeats across all three vendors we tested, which suggests there's a shared architectural assumption in how agent harnesses are being built industry-wide. Whether that needs a formal standard or just a shared understanding of the failure mode, the conversation needs to happen across vendors, not just inside one security team," Meged emphasized.
Implications for enterprise deployments
Enterprises deploying AI agents in CI/CD pipelines face exposure that standard safety testing may not catch. Traditional red-teaming focuses on the model's outputs—whether it generates toxic text or reveals training data. The vulnerability Meged discovered is orthogonal: it's about the infrastructure layer that sits between the model and the execution environment.
Agent harnesses are increasingly built on top of large language models, but the security principles that apply to any automation system are often overlooked. The ability to read files, run commands, and post outputs is a powerful capability, and each permission must be scoped independently. More importantly, the permissions must be revalidated at the point of use, not just at the point of approval.
Background: The rise of coding agents
AI coding agents have become central to developer workflows. Tools like Claude Code, Gemini CLI, and Codex CLI automate code review, bug fixing, and even deployment. Their integration into CI pipelines means that a single compromised agent can execute arbitrary commands on production-like environments. The safety checks in these agents are designed to prevent the model from acting on malicious instructions, but as Meged showed, those checks are easily bypassed through the harness layer.
Practical auditing guidance
Meged offered one immediate audit for teams running these agents in production. "Trace every path where the agent's output, or any state the agent can influence, gets consumed by a later stage with different privileges. Find where your harness says 'this is safe' and then ask: what happens to that output next? Is it published? Is it loaded as configuration? Is it passed to a tool with broader access than the approval assumed?"
"Most teams audit what the agent can do. The exposure we keep finding is in what happens after—the handoff between 'approved' and 'executed,' between 'read' and 'published,' between 'fetched' and 'trusted,'" he said.
The findings highlight that security testing must move beyond prompt injection to include supply-chain style analysis of the entire agent workflow. Each step in the pipeline is a potential trust boundary, and each boundary must be independently enforced.
Historical context: From chatbots to agents
The evolution from curated chatbot to autonomous agent has widened the attack surface considerably. Early language models were confined to generating text within a controlled interface. Agents, by contrast, have direct access to file systems, shell commands, and network resources. The model's intent is mediated by a harness that decides which actions to allow, but as Meged demonstrated, the harness's security model is often built on implicit trust that does not survive composition across stages.
In many ways, this mirrors the progression in web application security. SQL injection was initially addressed by escaping inputs, but it took the industry years to adopt parameterized queries as a structural fix. Agent security may be at a similar inflection point, where labeling and blocking specific attacks gives way to rethinking the trust model entirely.
What vendors are doing
Anthropic, Google, and OpenAI have all released patches following Meged's disclosures. Anthropic updated their pipeline to add additional checks on output channels. Google revised their documentation and default configurations to enforce restrictions more aggressively. OpenAI enhanced their sandbox to prevent cross-stage data contamination. However, Meged's repeated bypasses suggest that these fixes are moving the boundary rather than eliminating the underlying vulnerability.
The challenge is that each patch addresses a specific attack vector, but the root cause—the lack of re-validation at consumption points—remains. Until vendors adopt a structural approach, similar vulnerabilities are likely to emerge as agents gain more capabilities and are woven into more complex workflows.
Source: Help Net Security News