The uncomfortable truth about AI agent security
AI agent security vulnerabilities arise when models that appear safe in isolation interact with surrounding automation, allowing secrets and privileged actions to slip through at workflow handoff points where outputs are treated as trusted inputs for later stages. In practice, that means an AI agent can pass every AI safety check, obey tool restrictions, and still leak credentials or execute sensitive commands once its "approved" output is consumed by other systems that carry broader access or weaker assumptions about trust. The main risk is not the model itself, but the chain of shell commands, file reads, and publications that follow its decisions. That is the key takeaway: if you think your AI safety checks are enough, you are looking in the wrong place. The attacks emerging against Claude Code, Gemini CLI, and Codex agents show a consistent pattern. The defenses exist. They fail at the handoffs.
Claude Code, Gemini CLI, Codex: safe alone, dangerous together
Researchers have shown that three of the most visible development agents—Claude Code Action, Gemini CLI, and Codex CLI—share the same architectural weakness. An agent is a model plus a harness: the model generates intent, and the harness turns that intent into shell commands, file reads, and network requests, holding approvals, path restrictions, and output handling. When nobody reviews each step, the harness becomes the security boundary—and that boundary is full of seams. Against Anthropic’s default Claude Code Action workflow, the research found prompt injection was only the delivery mechanism; the real flaw lay in how the harness made trust decisions and how those decisions composed across stages. A command gets approved because it looks safe; output gets published because that is the default. Alone, each decision is defensible. Together, they form an exfiltration chain that handed over secrets from Anthropic’s own pipeline. Any organization running this package out of the box carries the same exposure.
Google’s Gemini CLI, hosted in a repository with more than 100,000 stars, suffered a similar problem. The researcher demonstrated a full kill chain using the very security configuration Google recommends for CI workflows that process untrusted input. A restriction the operator had configured went unenforced at execution time, which is why Google’s advisory carries a 10.0 CVSS rating and appears as GHSA-wpqr-6v78-jr5g. Codex CLI tries to contain risk with a default sandbox and protected paths, but in multi-stage workflows, state written by one stage is picked up as trusted context by the next. The protected path list encodes assumptions about what needs protection, and those assumptions fail whenever a later stage treats prior output as configuration or credentials.
Where AI safety checks break: the handoff problem
Vendors have not been careless. Anthropic runs dozens of checks in its Claude Code pipeline, and each patch closed a specific hole. Google built multiple execution modes with environment sanitization. OpenAI ships a sandbox with protected paths for Codex CLI. The defenses are there. The trouble is that they are bound to individual stages, while attacks exploit the seams between those stages. According to the researcher, "In every case, 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". By the final round of the Claude Code exploit work, secrets were recovered through a channel that survived every prior fix: no outbound connection to an attacker, no writes, no logs. That is an AI safety checks bypass in the strictest sense—the system passes all model and tool policies yet still leaks secrets, because a later component blindly trusts the label "safe" that an earlier component applied.
This is why bounty-per-bypass thinking is misleading. Anthropic awarded bounties for each finding and treated each one as an isolated bug. Google framed its response as an "Update to the Trust Model," which is closer to the real issue: these are trust model failures, not simple software bugs. A structural fix stops trusting the label and re-validates trust at the point of consumption, not just at the point of decision. Most teams audit what the agent can do. The exposure keeps appearing in what happens after—the handoff between approved and executed, between read and published, between fetched and trusted.
Hidden privilege escalation in real enterprise workflows
Enterprise teams are already wiring AI agents into CI pipelines, code completion tools, and development workflows. The harsh reality is that any organization running one of these agents in default or recommended security configurations inherits the same hidden privilege escalation risks. AI agents increase the potential blast radius because they can inherit the privileges of the people who deploy them or retain access to the credentials they receive. Once an agent’s output is treated as configuration, script content, or deployment metadata, it can influence a later stage that runs with far broader permissions than the agent itself. One quoted finding should be a wake‑up call: "Most organizations have more standing access in their environments than they can see or justify". 1Password’s recent research found that 40% of developers grant agents persistent access to systems or credentials, which means an old access problem now moves at machine speed: more identities, more systems, and more permissions that can persist long after the work is done. In that setting, a single prompt injection is enough to stitch together an exfiltration chain across multiple trusted components.
If you treat "safe" agent output as inherently trustworthy, you are building a privilege escalation path. The model may never touch secrets directly, yet its suggestions can cause a build step to read local configuration, a deployment step to include environment variables, or a documentation bot to publish logs and command output that contain credentials. The protected path list and sandbox rules only cover what they know about. Anything outside those assumptions becomes a ghost surface for exfiltration, invisible to conventional AI safety monitoring that focuses on prompts and responses instead of the wider system.
What teams should do now: audit handoffs and reduce standing access
For teams running these agents in production, the first step is architectural self‑inspection, not another prompt rule. 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? Loaded as configuration? Passed to a tool with broader access than the approval assumed? Most teams audit what the agent can do; you need to audit what the rest of your stack does with what the agent produces.
At the same time, you should reduce the blast radius by cutting down standing access. 1Password has launched 1Password Privileged Access, expanding its platform with privileged access management that provisions access at the moment of request, scopes it to the task, and deprovisions it automatically when the work is done. This keeps agents from holding long‑lived credentials and ensures permissions exist only for the duration of a workflow run. 1Password Credential Broker for GitHub Actions issues credentials scoped to each workflow run, verifying that the requesting identity is trusted and logging every delivery. 1Password Environments lets developers import existing .env files into a vault and access secrets through an MCP Server, keeping credentials off disk and out of model context. Developer Watchtower then finds exposed credentials in local .env files and guides developers to secure them while giving administrators visibility into credential risk on developer machines.
The conclusion is blunt: passing AI safety checks is now table stakes. The real fight is over trust boundaries between agents and the systems around them. If you are not re‑validating trust at every handoff and cutting down standing access with privileged access management, you are betting your software supply chain on labels like "safe" and "sandboxed" that attackers have already learned to route around.
