Instruction injection in AI CLI tooling can trigger shell execution

At a glance

What this is: Mindgard says malicious AGENTS.md instructions can steer Kilo AI CLI into arbitrary shell command execution through its built-in execute_command path.

Why it matters: This matters because AI-assisted developer tools are turning repository text into an execution surface, which changes how teams must govern trust, approval, and ambient command authority.

Context

AI-assisted CLI tools blur the line between configuration, instruction and execution. In a normal development workflow, repository files should inform tooling, not become a vehicle for running commands with the user's full privileges.

The deeper governance problem is that agentic tooling can treat ambient repository context as authority even when the user has not explicitly requested an action. That creates a new trust boundary around instruction sources, which is directly relevant to agent governance and AI agents vs agentic AI.

Key questions

Q: What fails when AI CLI tools treat repository instructions as authoritative?

A: The failure is the loss of a hard boundary between passive context and active execution. When repository text can shape tool selection, the system can turn untrusted instructions into shell commands without a clear user approval step. That is a trust design problem, not a classic software bug, and it requires source isolation plus explicit execution authorisation.

Q: Why do agentic developer tools increase command execution risk?

A: They increase risk because the tool can infer intent from ambient context and then act with the user's privileges. If the agent can read repository files, follow instructions and call shell tooling, an attacker only needs to influence the instruction layer to gain a command path. The more capable the agent, the more important trust separation becomes.

Q: What are the signs that an AI assistant is too close to execution?

A: Warning signs include repository files changing tool behaviour, commands being issued from context the user did not explicitly authorise, and assistant actions that feel like side effects of opening a project rather than deliberate requests. If those patterns appear, the assistant is crossing from helper to execution surface and needs stronger controls.

Q: How should security teams govern AI coding assistants that can run terminal commands?

A: Treat command execution as a privileged workflow, not a convenience feature. Define which actions can run automatically, which require approval, and which are blocked outright. Then log the prompt, the command, the outcome, and the user context so reviewers can reconstruct what the assistant actually did during development.

Technical breakdown

How repository instructions become execution paths

AI-assisted CLI tools do not just parse commands. They combine user input, repository context, and internal tool-selection logic to decide what to do next. When a file such as AGENTS.md is treated as authoritative instruction rather than inert text, it can alter the agent's plan and push the system toward tool invocation. The security failure is that a text instruction layer sits close enough to execution that untrusted repository content can influence runtime behaviour. That is different from ordinary config parsing because the model may generalise intent rather than enforce a strict schema. See the AI Agent Authorisation Guide.

Practical implication: Treat repository-scoped instruction files as security-sensitive inputs and restrict which contexts can influence tool execution.

Why execute_command creates a privileged boundary

Built-in execution functions matter because they collapse interpretation and action. Once the agent decides that a directive should be carried out, execute_command turns that decision into shell activity in the user's environment. The attacker does not need code execution in the traditional sense because the tool already provides a sanctioned execution channel. The issue is therefore not only what the command does, but who gets to shape the decision to call it. That makes command authorisation and trust separation central to the control model.

Practical implication: Place explicit approval, scope checks, and source trust checks in front of any tool that can touch the shell.

How ambient instructions expand the attack surface in developer tooling

This pattern is broader than one product because agentic development tools increasingly blend documentation, prompts, repositories, and automation into a single interpretive layer. In that model, any text the agent consumes can become a behavioural input, which makes supply chain risk and delegated authority converge. The practical consequence is that public repositories, cloned workspaces, and shared project metadata can all function as delivery mechanisms for instruction injection. Security teams should think in terms of execution surfaces rather than file types. Read Red Teaming AI Agents for Identity Abuse.

Practical implication: Map every text source the agent reads and classify whether it can influence tool use, not just whether it is executable code.

Threat narrative

Attacker objective: The attacker aims to convert trusted repository text into unauthorised shell execution inside a developer workstation or build environment.

1. Entry occurs when an attacker places malicious instructions in a repository-controlled AGENTS.md file and a developer opens that repository in the CLI tool.
2. Credential or privilege abuse follows when the agent treats those instructions as authoritative and invokes execute_command in the user's session.
3. Impact occurs when arbitrary shell commands run in the developer environment with the user's available file, credential and system access.

Breaches seen in the wild

• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.
• xinference PyPI compromise 2026: Three xinference releases on PyPI carried a stealer for cloud, Kubernetes and registry keys, reportedly via a compromised bot account.

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

Instruction trust is now an execution control problem: the central failure here is not that a file exists, but that the system treats repository-authored instructions as a valid source of runtime authority. That collapses the distinction between documentation and command path, which is exactly where agentic tooling becomes dangerous. Security teams should govern which instruction sources can influence tool invocation, not just which binaries can run.

Agentic developer tools create a new form of privilege amplification: once an AI assistant can decide to invoke shell tooling, any trusted context it ingests can inherit the user's effective privileges. That means repository content, prompt material and workflow notes all become candidates for abuse if the trust model is loose. The governance gap is delegated authority without explicit source isolation, and practitioners should treat that as a control-design issue.

Ambient instruction exposure: the attack surface expands whenever free-form text can steer action without a hardened approval boundary. This is not classic parser security, and it is not solved by scanning only for malicious code. Organisations need a model for instruction provenance, because the path from repository text to shell action is now part of the security boundary.

AI coding workflows need identity-aware control points: when an agent can act on behalf of a developer, it effectively becomes a non-human actor with delegated authority. That makes the question one of NHI governance as much as application security, especially where tool use can touch secrets, repositories or build systems. Teams should classify agent actions as governed access events, not informal productivity automation.

Read next: AI Agent Authorisation Guide

What this signals

Instruction-to-execution is becoming a distinct control plane: as AI development tools absorb more ambient context, teams need to govern instruction provenance with the same seriousness they apply to credentials and privileged sessions. The practical shift is from scanning inputs for malicious code to understanding which text sources can influence action. That is where the next wave of developer-tool risk will concentrate.

The broader programme implication is that AI assistants in engineering environments should be classified as governed non-human actors when they can issue commands or reach sensitive resources. That makes approval boundaries, source trust and delegated authority part of the identity and access conversation, not just an application feature question. Organisations that do not map those paths will miss the real control point.

For practitioners

• Harden repository instruction trust Treat AGENTS.md and similar files as governed inputs. Restrict which repositories can influence agent behaviour, and prevent untrusted project content from altering tool-selection logic. See the AI Agent Authorisation Guide.
• Separate reasoning from execution Require explicit authorisation before any agent-issued shell action, especially when the action originates from repository context rather than a direct user request.
• Inventory all agent tool paths Document every function that can move an AI assistant from interpretation to execution, including command runners, file writers and network-capable tools.
• Treat developer AI as delegated access Apply least-privilege thinking to AI-assisted coding workflows so that agents cannot reach credentials, sensitive files or environment resources they do not need.

Key takeaways

• The core problem is not a malformed command but a broken trust boundary between repository text and executable action.
• The article shows how a malicious AGENTS.md file can push an AI CLI into arbitrary shell execution without explicit user intent.
• The control gap is source provenance and execution authorisation, which need to be separated before agent tooling can safely act on ambient context.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · AI Agents vs Agentic AI · Red Teaming AI Agents for Identity Abuse

Key terms

• Instruction Injection: Instruction injection is a poisoning technique where malicious commands are embedded inside documents so the model follows them during retrieval and generation. The attack works by blending harmful instructions into otherwise plausible content, which can bypass simple content filters and redirect answers.
• Execution surface: An execution surface is any system or environment where an identity can actually do work, such as an application, trigger, endpoint, or API. For AI agents, execution surfaces matter because risk appears where action is taken, not only where authentication occurs.
• Delegated authority: Delegated authority is the effective power a system has to act on behalf of a user or service. For AI agents, it matters because the assistant may inherit file access, shell access or other privileges that outlive the user's immediate intent unless tightly bounded.
• Instruction Provenance: Instruction provenance is the record of where an instruction came from, who supplied it, and how it was transformed before reaching an AI system. In agentic AI and MCP-enabled workflows, it helps separate trusted system prompts from user input, tool output, and injected content, reducing prompt injection and unauthorized action risk.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and secrets management for teams building and securing delegated AI workflows. It helps practitioners turn identity and access concepts into controls that fit modern AI-assisted operations.