Gemini CLI permission boundaries still allow shell escape risk

At a glance

What this is: Mint Security’s analysis shows that Gemini CLI permission boundaries can be bypassed through shell redirection, turning an approved command into a network escape path.

Why it matters: IAM and security teams need to treat agent tool permissions as blast-radius controls, not hard security boundaries, because approval models can fail under adversarial command composition.

👉 Read Mint’s analysis of Gemini CLI permission boundary bypass risk

Context

Agentic coding tools can connect to many services and actions through MCP servers, shell commands, plugins, and custom workflows. That makes permission boundaries an identity and access problem, not just an application safety issue, because the agent’s effective authority is defined by what it can invoke at runtime.

The governance gap is that auto-approval policies are designed to reduce human fatigue, yet they can still be bypassed when command parsing and execution semantics diverge. For teams running agentic AI, the question is not whether permissions exist, but whether they actually constrain runtime behaviour in a way that holds under composition and redirection.

Key questions

Q: What breaks when agent permissions rely on command patterns instead of execution semantics?

A: A pattern-only model can approve a command that looks harmless while the shell turns it into a different action at runtime. That creates a gap between policy intent and actual authority, especially when redirection, chaining, or substitution is involved. Security teams need controls that inspect execution behaviour, not just the text a user sees.

Q: Why do agentic coding tools increase blast-radius risk even when auto-approval is limited?

A: Because the agent can chain approved tools into a larger action than the reviewer intended. A narrow allow list may still permit network access, filesystem reads, or command composition that expands impact. The core risk is not one tool in isolation, but the combined authority of the toolchain.

Q: How can security teams tell whether agent permissions are too broad?

A: The clearest signal is whether the agent can still complete its job after permissions are reduced in a sandbox. If the task keeps working after you remove broad access, the original entitlement was inflated. A second signal is the presence of unused permissions that persist across reviews and deployments.

Q: Who is accountable when an agent opens an outbound connection outside its intended boundary?

A: Accountability sits with the team that defined the agent’s delegated authority, the parser or execution layer that enforced it, and the operators who approved its runtime use. For regulated environments, that means the control owner must be able to show how the boundary was defined, tested, monitored, and corrected.

Technical breakdown

Command parsing versus execution semantics in agent tools

Agent frameworks often inspect a command string before deciding whether to approve it, but shell interpreters can transform that string into something materially different at execution time. In this case, a command that looked like a harmless directory creation action was paired with redirection syntax that changed the effective behaviour. The parser approved the visible pattern, but the shell still executed a network-capable payload. This is a classic mismatch between policy evaluation and real execution context, and it is especially dangerous when an agent can combine approved actions into unintended outcomes.

Practical implication: validate permissions against execution semantics, not just the surface command pattern.

Approval fatigue and brittle allow lists in agentic AI

Auto-approval lists are intended to limit human review to higher-risk actions, but they create a new trust boundary that attackers can probe. When a list is too permissive or too pattern-based, the system can end up approving variants that were never intended by the administrator. The problem is not only malicious abuse. It is also that the agent’s toolchain, shell, and parser each interpret the action differently, so a permission model that looks narrow on paper can still be broad in practice.

Practical implication: keep allow lists narrow, reviewable, and tied to concrete execution contexts.

Blast-radius control for autonomous and semi-autonomous agents

Blast-radius control is the practical objective here: reduce what an agent can do if one decision path is abused. That means separating read, write, and network-capable actions, constraining execution environments, and monitoring for behaviour that looks like exfiltration or lateral movement. Even when the agent is not fully autonomous, its ability to chain tools creates a wider impact envelope than a normal script. The security model has to assume runtime composition, not single-action intent.

Practical implication: combine sandboxing, network egress control, and runtime monitoring around agent execution.

Threat narrative

Attacker objective: The objective is to convert an approved agent action into an outbound network path that can be used for unauthorised communication or escape.

1. Entry occurs when an attacker or untrusted prompt path reaches an approved agent command that appears benign to the permission layer.
2. Escalation occurs when shell redirection or command composition changes the approved action into a network-capable payload that the parser did not fully constrain.
3. Impact occurs when the agent opens a connection to a third party, creating a potential exfiltration or command execution channel outside the intended boundary.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Hermetic permission boundaries are a false assumption in agentic tooling. The article shows that a command can appear compliant at the policy layer while the shell still executes materially different behaviour. That means the boundary is advisory unless it is enforced across parsing, execution, and runtime monitoring. Practitioners should treat approval policies as risk reducers, not as proof of confinement.

Approval fatigue is now an access-control problem, not just a user-experience problem. When humans are overwhelmed by repetitive prompts, they stop being an effective control and become a throughput bottleneck. The article’s own mitigation pattern is sensible, but it also demonstrates how quickly auto-approval turns into a new attack surface if the allow list is not semantically precise. Security teams should evaluate whether their agent governance is protecting attention or merely automating consent.

Blast-radius control is the right organising concept for agent governance. The useful question is not whether an agent can be trusted in the abstract. It is how far it can reach if one command path, plugin, or shell interpretation is abused. That is why network egress, filesystem read boundaries, and execution sandboxing need to be designed together under OWASP Agentic AI Top 10 and NIST AI Risk Management Framework thinking.

Shell-based agents inherit identity risk from every tool they can invoke. Once an agent can call Bash, plugins, or MCP-connected services, the effective identity is a delegation chain, not a single principal. That makes least privilege harder to reason about because the actual risk lives in the composition of tools, not only in the initial permission grant. Practitioners should reframe agent governance around delegated authority and runtime containment.

Runtime monitoring becomes the missing control when static policy fails. The article’s example shows that static permission lists can miss dangerous behaviour until execution time. Monitoring for suspicious outbound connections, unexpected command composition, and policy exceptions provides the only practical feedback loop once the agent has started acting. Teams should assume that some agent actions will only be recognisable as risky after they begin to execute.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap makes runtime containment and auditability the next practical step, as explored in OWASP Agentic Applications Top 10.

What this signals

Approval fatigue has become a structural governance issue. Teams that rely on humans to catch every risky prompt or shell action will eventually normalise exceptions, especially when agents generate frequent requests. The practical response is to move toward tighter execution boundaries, stronger runtime telemetry, and policy design that assumes review attention is finite.

With 98% of companies planning to deploy even more AI agents within the next 12 months, per AI Agents: The New Attack Surface report, the permission problem will scale faster than most IAM programmes can redesign review processes. That means agent governance should be treated as a programme-level control surface, not a tool-setting. Teams should expect more delegation chains, more policy exceptions, and more demand for continuous monitoring.

Shell escape risk shows why agent security needs a named concept: execution-perimeter drift. Once command parsing, shell semantics, and network access diverge, the boundary is no longer a boundary in practice. Security teams should align agent rollout plans with external guidance such as the OWASP Agentic AI Top 10 and treat outbound connectivity as a first-class control.

For practitioners

• Tighten command allow lists around execution context Review approved patterns for shell-based agents and remove entries that can be altered by redirection, chaining, or substitution. Test each allow rule against the actual shell and parser used in production, not against a simplified example.
• Separate read, write, and network authority Treat network egress as a distinct privilege and block it by default for agent workflows that do not explicitly require outbound connectivity. Apply the same separation to sensitive file reads such as .env, .aws, and .ssh paths.
• Add runtime detection for suspicious agent behaviour Instrument agent sessions for unexpected outbound connections, shell escape patterns, and repeated approval exceptions. Use those signals to trigger containment before the agent completes a delegated task.
• Sandbox agent execution at the operating system layer Run coding agents in constrained environments with explicit filesystem and network boundaries so that one approved command cannot easily become a broader session escape. Validate the sandbox against the exact tools the agent can invoke.

Key takeaways

• Agentic coding tools can bypass superficial permission boundaries when shell syntax and parser logic diverge.
• The issue is not only command approval but the wider blast radius created by tool chaining, network access, and human fatigue.
• Security teams should validate agent controls in runtime conditions, then combine sandboxing, egress control, and behavioural monitoring.

Key terms

• 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.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Execution Semantics: The behaviour a command or action produces when it is actually run, which can differ from the surface text a policy engine inspects. In agentic systems, security depends on checking execution semantics because parsing alone may not capture redirection, chaining, or shell behaviour.
• Permission Perimeter: The set of technical boundaries that define what an agent may do, read, or connect to. In practice, this perimeter is only as strong as the layers enforcing it, including parsers, shells, sandboxes, and network controls.

What's in the full article

Mint’s full article covers the operational detail this post intentionally leaves for the source:

• Code-level explanation of how Gemini CLI parses and approves shell commands.
• The exact redirection pattern that turned an allowed action into a network escape path.
• Google’s confirmation, amendment, and bounty handling timeline for the issue.
• Operational recommendations for sandboxing and runtime monitoring in agentic workflows.

👉 Mint’s full post covers the parsing flaw, reverse shell pattern, and the mitigation discussion.

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 identity security programme, it is worth exploring.