AI agents are failing where it matters most: the handoff
AI agent security vulnerabilities arise when the surrounding automation that turns model outputs into actions mishandles trust, so even though the model passes all AI safety checks, downstream systems still execute or publish those outputs in ways that leak secrets or escalate access without a human ever seeing the full chain of events.
The key takeaway: the dangerous part of an AI agent is not the model but the glue code around it. An agent is a model plus a harness that converts intent into shell commands, file reads, API calls, and network requests, and that harness holds the approval logic and output handling. When workflows run end-to-end without human review, that harness stops being a convenience layer and becomes your real security boundary. Focusing on prompt safety alone is a strategic mistake; attackers are walking straight around guardrails by abusing how “safe” outputs get reused later. If you run Claude Code, Gemini CLI, or Codex agents in default configurations, you should assume they are composable parts of an exfiltration chain, not isolated tools.
How Claude Code, Gemini CLI, and Codex were turned into leak pipelines
Novee researcher Elad Meged showed that Claude Code Action, Gemini CLI, and Codex-based agents can all pass AI safety checks yet still leak secrets during code execution handoffs in their default setups. His method was blunt: send prompt-injected pull requests and watch where the harness made blind trust decisions. Anthropic’s pipeline handed over secrets, meaning any organization running the same agent out of the box carried the same exposure.
Meged reported multiple findings against Claude Code Action, the default workflow configuration for anthropics/claude-code, which millions of people install. Each fix “drew a new line” around what counted as safe, but he kept finding new ways to recover secrets, eventually through a channel with no outbound connection, no writes, and no logs. Google’s Gemini CLI, hosted in a repository with more than 100,000 stars, was serious enough to trigger an advisory with a 10.0 CVSS score — the top of the severity scale. OpenAI’s Codex CLI ships with a default sandbox, but as with the others, the exposure surfaced in the way the harness transitions between protected and unprotected states.
The real flaw: trustworthy labels cascading into untrusted contexts
According to Elad Meged, “prompt injection was just the delivery mechanism, but the actual vulnerabilities were in how the harness made trust decisions, and how those decisions composed across stages.” A command gets approved because it looks read-only; the output gets published because that is the default behavior. Neither decision is wrong alone; together, they form an exfiltration chain that moves secrets from a secure environment into a public channel.
Right now, harnesses make a safety call early — a command is labeled read-only, a domain is marked pre-approved — and downstream systems inherit that label without checking whether it still holds in their context. The exposure keeps appearing in what happens after: the handoff between “approved” and “executed,” between “read” and “published,” between “fetched” and “trusted.” The defenses exist; they fail at the handoffs. If you are only watching the prompt layer, you never see the moment where one safe-looking step feeds a more privileged component that was never designed to question upstream assumptions, enabling AI safety checks bypass without any obvious misbehavior in the model itself.
What developers must patch now: trust, containers, and supply chain
If you are shipping AI-powered automation, you cannot outsource security thinking to bounties and default configs. The finding that triggered GHSA-wpqr-6v78-jr5g came after multiple rounds of patches and payouts, but the architectural seam stayed the same. Bounty-per-bypass programs reward individual bugs while quietly normalizing the underlying exposure. A structural fix, in Meged’s words, “stops trusting the label and re-validates trust at the point of consumption, not just at the point of decision.”
Start with an audit. 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 ask what happens next: is that output published, loaded as configuration, or passed to a tool with broader access than the original approval assumed? In parallel, treat container image security as a foundational control point for these workflows, because container images have become long-lived supply-chain components that move unchanged across teams and clusters. Mature security teams map vulnerability entry points across base images, build layers, third-party components, and configuration drift, instead of waiting for scanners to shout after the fact.
From reactive band-aids to intentional AI agent architecture
Most organizations are still stuck in a reactive mindset: they bolt on scanning tools, celebrate each fixed CVE, and assume safer models equal secure agents. Container image security tools are useful, but on their own they detect risk after images already exist, which keeps teams stuck in backlog triage mode. The same mistake is repeating in AI agents: closing one Claude Code exploit while leaving the underlying trust model intact makes the next bypass harder to see, not less likely.
The way out is opinionated. Treat AI agents as distributed systems with explicit security boundaries, not as smart assistants. Combine noise-cutting detection with upstream prevention and downstream enforcement for both code and containers, so you govern risk end-to-end instead of hoping safety filters catch everything. And stop assuming that a “safe” decision near the model stays safe forever. If you rebuild your pipelines so every privileged consumer re-validates what it receives, you turn secret leakage prevention into a property of the architecture, not a fragile side effect of whatever the model felt like doing that day.
