AI agents are failing at the exact point we trust them most
AI agents are automated systems that pair a language model with a surrounding control layer, or harness, that turns model decisions into commands, file reads, API calls, and network requests while enforcing safety rules and approvals. Their biggest security risk is not the model’s output itself but how that harness makes trust decisions and passes supposedly safe data into later stages, where it can be exposed without any human review. This design flaw means an AI agent can pass every AI safety check on prompts and tools yet still leak secrets when its “approved” actions are logged, published, or consumed by higher-privilege systems downstream. The uncomfortable takeaway: the industry has treated AI safety checks as the boundary, but in production agent workflows, the true security boundary is the harness—and right now, that boundary is riddled with gaps. This is not a theoretical issue; it is already showing up in real platforms and real breaches.
Claude Code, Gemini CLI, and Codex fail in their default security posture
Recent research shows that default AI agent configurations from major vendors are failing basic security expectations in live workflows. Claude Code Action, the default workflow for anthropics/claude-code, has had multiple reported findings and “millions of people install the package,” meaning any one of them may be running exposed agents out of the box. Google’s Gemini CLI, shipped as google-gemini/gemini-cli with more than 100,000 stars, carries a security advisory rated at 10.0 on the CVSS scale. OpenAI’s Codex CLI ships with a default sandbox that only protects the paths it already knows about, leaving other state to be treated as trusted when it should not be. These are not fringe tools; they sit in CI pipelines and developer workflows at scale. The pattern repeats: vendors ship agents with sensible-sounding defaults, and those defaults quietly allow credential and secret leakage in multi-stage workflows.
How AI safety checks are bypassed at the handoff point
The core AI agent security vulnerabilities are not failures of filtering prompts but failures in how agent harnesses treat early approvals as permanent truth. An attacker uses prompt injection as the delivery mechanism, but the breach happens when the harness decides a command is “read-only” or a domain “pre-approved,” and downstream components inherit that judgment without re-checking it in their own context. A read-only command that pipes sensitive output into a public channel is not read-only in effect, and a pre-approved domain serving attacker-controlled content is no longer safe. In one set of tests, a bot processed a pull request, executed shell commands that looked safe, and posted the output—including secrets—back to a public thread before any maintainer saw it. “The defenses exist. They fail at the handoffs,” as the researcher put it, describing an exfiltration chain built entirely out of individually reasonable decisions.
Default sandboxes and pipelines quietly leak credentials
The most alarming finding is not that AI agents can be made to leak secrets, but that they do so in recommended, default setups that pass all documented safety checks. Anthropic’s pipeline “handed over secrets” when tested in its default Claude Code Action workflow, and “any organization running one of these agents out of the box carries the same exposure.” Codex CLI’s default sandbox protects known paths, but in multi-stage workflows that share a workspace, state written by one stage is picked up as trusted context by the next, and the protected path list embeds unexamined assumptions about what needs protection. By the final round of testing against Claude Code, the researcher was “recovering secrets through a channel that survived every prior fix: no outbound connection to an attacker, no writes, no logs.” Anthropic paid bounties and shipped multiple patches, each closing a specific hole, yet each new boundary line exposed the same architectural weakness: safety decisions that do not travel safely downstream.
Enterprises must treat agent harnesses as a first-class security boundary
Enterprise teams deploying AI agents need to stop assuming that baseline AI safety measures—prompt filters, tool whitelists, “read-only” checks—are enough. The failure mode is clear: “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.’” The immediate advice for anyone running these agents in production is blunt: “Trace every path where the agent’s output, or any state the agent can influence, gets consumed by a later stage with different privileges.” Secret leakage prevention now means mapping those flows, checking where the harness says “this is safe,” and then asking what happens to that data next—does it get published, loaded as configuration, or passed into a tool with broader access than the original approval assumed? A single vendor can ship meaningful improvements, and some already have, but the architecture problem spans Claude Code, Gemini CLI, Codex, and likely more. AI agent security vulnerabilities will not disappear until the industry treats harness design, and not only model behavior, as a shared security problem.
