TL;DR: Gemini CLI permission boundaries can be bypassed through command redirection, allowing a supposedly benign allowed action to open a network connection, according to Mint Security. The finding reinforces that agentic execution boundaries reduce approval fatigue but do not make tool access hermetic or safe by default.
At a glance
What this is: Mint shows that Gemini CLI permission boundaries can be bypassed with shell redirection, letting a seemingly safe approved command open an outbound connection.
Why it matters: IAM, PAM, and NHI teams need to treat agent permission perimeters as fallible enforcement points, not proof that runtime tool access is safe.
Context
Coding agents expose a governance gap that classic allowlists do not fully close. Once an agent can invoke shell commands, connect to MCP servers, and chain tool calls, the security question becomes whether the perimeter still holds when input parsing, shell behaviour, and approval policy interact.
Mint’s example with Gemini CLI shows why approval boundaries matter for NHI governance and agentic AI identity security. The issue is not just whether a command is allowed, but whether the surrounding execution path can be bent into something materially different from what the policy intended.
Key questions
Q: What breaks when agent command allowlists only inspect the visible command name?
A: The control breaks when the visible command is not the same as the runtime effect. Shell features such as redirection, piping, and subshell syntax can preserve the approved token while changing what actually happens. That is why agent allowlists need to account for the full execution context, not only the command label.
Q: Why do permission boundaries for coding agents still create risk?
A: They still create risk because they reduce prompt fatigue without eliminating the possibility that parser logic, shell behaviour, or tool chaining will produce a different outcome than the policy intended. A boundary can lower operational noise and still leave a path to file access, egress, or data exposure if the runtime stack is not tightly constrained.
Q: How do security teams know when auto-approval policies are too permissive for agents?
A: The clearest sign is when approved actions can be repurposed into materially different behaviours without tripping the control. If a harmless command can become a shell escape, network connection, or data movement path, the policy is describing intent rather than enforcing it. That is a measurement failure, not just a tuning issue.
Q: What should teams do after a coding agent permission boundary is bypassed?
A: Teams should review the approved command set, check whether shell and network restrictions were actually enforced, and treat the event as evidence that the execution perimeter is not hermetic. The remediation question is not only whether to block that syntax, but whether the broader runtime needs containment beyond parser-based approval.
Technical breakdown
Why shell redirection can bypass command allowlists
Gemini CLI uses command parsing to decide whether a shell action is eligible for auto-approval. That works when the command structure is simple, but shell syntax can carry extra behaviour outside the narrow command token the policy expects. In the reported case, a harmless-looking mkdir command was paired with redirection, so the parser saw the approved command while bash still executed a network-relevant side effect. The failure is not just parsing accuracy. It is a mismatch between policy intent and execution semantics. Practical implication: treat allowlists as partial controls unless they constrain the full execution context, not only the visible command name.
Practical implication: validate the entire shell execution path, not only the nominal command being approved.
Why approval fatigue makes boundary controls easier to misuse
Permission boundaries are often adopted to reduce the number of human prompts an agent generates. That is sensible, because excessive approvals can train operators to approve reflexively. But once boundaries are used to suppress friction, the governance burden shifts to the quality of the boundary itself. If the boundary is porous, the organisation gets the worst of both worlds: less human scrutiny and a false sense of control. This is especially relevant for coding agents that operate across files, shells, and external services in one task flow. Practical implication: measure whether your approval policy is reducing noise without creating blind trust in auto-approved actions.
Practical implication: review whether auto-approval is shrinking scrutiny faster than it is shrinking risk.
Why agent tool access is not hermetic by default
Agent frameworks often present a clean policy layer, but the actual execution stack usually includes the agent, the parser, the shell, the OS, and any connected services. Each layer can reinterpret an action differently. That means a policy written at one layer can be undermined by behaviour at another. In this article, the visible action remained within the allowed command class while the shell produced a materially different effect. For identity teams, that is a reminder that runtime authorisation for agents must account for delegated execution, not only declared intent. Practical implication: design controls around the complete toolchain, including shell and network egress boundaries.
Practical implication: govern agent runtime behaviour across parser, shell, and egress layers as one control surface.
Threat narrative
Attacker objective: The objective is to turn an approved agent action into an unplanned network connection that can support exfiltration or broader shell escape activity.
- Entry occurs when a coding agent is granted auto-approved access to a shell command that appears benign, such as mkdir. The control assumption is that the approved action stays within the expected command boundary.
- Credential or execution abuse follows when shell redirection is attached to the approved command, allowing bash to interpret the action in a way the allowlist did not intend. The agent remains inside policy on paper while the runtime effect changes.
- Impact is the creation of an unintended outbound network connection, which can expose data or enable exfiltration from the agentic environment. Mint reported the issue and Google amended it.
Breaches seen in the wild
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
- Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Execution boundaries are a policy control, not a guarantee of safe behaviour: Gemini CLI shows that a permitted action can still produce an unsafe runtime outcome when shell semantics sit outside the policy’s narrow view. That means the real control boundary is the whole execution stack, not the allowlist entry alone. Practitioners should treat agent permission perimeters as probabilistic containment, not hermetic enforcement.
Approval fatigue is the governance problem that boundary controls are trying to solve: Auto-approval is attractive because it reduces prompt overload, but it also creates a dependency on parser correctness and shell predictability. When those assumptions fail, human review is already out of the loop. The implication is that reducing friction without stronger runtime containment can lower assurance at the same time it lowers workload.
Identity blast radius must be measured at runtime, not just at configuration time: This case shows that the apparent scope of an agent’s permissions can expand through composition, redirection, or chained execution. A static rule that looks narrow may still create a wider operational path once the shell interprets it. Practitioners need to think in terms of effective blast radius, not declared blast radius.
Hermetic permissioning is a misleading goal for connected agents: Once a coding agent can reach shells, MCP servers, and external services, the security question becomes whether each layer can safely absorb unexpected syntax and chained behaviour. That is a governance design problem, not just a parser problem. Teams should assume the perimeter will be tested by normal usage patterns, not only by obviously malicious input.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Agent permission perimeters only matter if they govern the full runtime path: When a shell command can be transformed by syntax the policy did not model, the control is narrower than the risk surface. That pushes agent governance toward runtime containment, egress control, and clearer separation between policy intent and executable behaviour.
Approval fatigue is now a control-quality issue, not just a user-experience issue: The more organisations rely on auto-approved agent actions, the more they need assurance that the approved action is the action that actually executes. Without that assurance, auto-approval becomes a path to silent control bypass rather than operational efficiency.
For practitioners
- Audit shell execution semantics Test whether allowlisted commands still permit redirection, piping, subshells, and other syntax that changes the runtime effect of an approved action.
- Constrain network egress from agent runtimes Apply OS- or container-level network restrictions so a command that escapes parser intent cannot open arbitrary outbound connections.
- Separate approval from execution context Review whether the thing being approved is the exact action that executes, or only a simplified representation of it, then close that gap where possible.
- Instrument suspicious agent activity Log and alert on commands that appear benign but trigger unexpected shell behaviour, especially file access followed by outbound connectivity.
Key takeaways
- The article shows that agent execution boundaries can fail when shell syntax changes the runtime effect of an allowed command.
- The practical risk is not just a policy miss but unintended network connectivity that can widen the agent’s blast radius.
- The limiting control is broader runtime containment, including shell handling and egress restrictions, not command-name approval alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article shows an approved tool action being repurposed into unsafe shell behaviour. |
| ASI03 — Identity & Privilege Abuse | The issue is a privilege boundary that appears valid but expands at runtime. | |
| Recommendation — Constrain agent tool execution paths so approved actions cannot be reinterpreted into unsafe runtime effects. Map agent permission scopes to actual runtime privilege and block privilege expansion through syntax tricks. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on whether the agent's permission boundary truly authenticates the allowed action. |
| NHI-05 — Overprivileged NHI | Auto-approved shell access can create an effective privilege scope wider than intended. | |
| Recommendation — Validate that the approved action is the executed action before treating agent permissions as trusted. Reduce agent privileges to the smallest execution scope that still prevents shell escape and unwanted egress. | ||
| MITRE ATT&CK | TA0006;TA0011 — Credential Access; Command and Control | The attack pattern combines execution abuse with outbound connectivity and potential exfiltration. |
| Recommendation — Hunt for command paths that convert benign execution into external connectivity or data access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about how entitlements for agent execution are defined and enforced. |
| Recommendation — Review agent authorisations so the approved entitlement matches the real runtime behaviour. | ||
Key terms
- Permission Boundary: A permission boundary is the enforceable limit on what an identity can do, regardless of how it behaves. For AI agents, this boundary matters more than session logs because it determines whether an action is possible in the first place.
- Approval Fatigue: The point at which repeated approval requests cause users to stop evaluating each one carefully. In agent governance, this is a control failure mode because the human reviewer becomes desensitised, making the oversight layer ineffective even though the workflow still appears compliant.
- Shell Escape: A shell escape is any method that breaks out of a constrained command environment and lands the user in a more capable shell. These escapes often rely on interactive utilities, misconfigurations, or reachable binaries that can spawn a new shell and bypass the original restrictions.
- Runtime containment: A control approach that limits harmful behaviour while an AI agent is still active rather than waiting for post-incident review. It depends on signals such as anomalous tool use, privilege expansion, or unusual data access so security teams can intervene before blast radius grows.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 1, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org