The main failure is that the installer is no longer a human-reviewed action with a stable payload. An agent can execute code before a full review, and the server can vary what it serves by timing or caller. That makes installation a live trust decision tied to delegated identity, not a simple download event.
Why curl | bash Breaks the Trust Model for AI Agents
With an AI agent, curl | bash is no longer just a convenience shortcut. It collapses review, retrieval, and execution into one live decision, so the installer can change between calls or be shaped by the caller. That turns tool installation into delegated authority, which is exactly where agent security starts to matter.
The core problem is not simply that the command downloads code. It is that the agent is allowed to execute code before a human has meaningfully validated the payload, provenance, or intended side effects. If the agent already has access to credentials, files, or local tooling, the installer can inherit that context immediately.
That is why safer installation patterns separate fetch from execute, pin content, and require an explicit approval step before anything runs. For agentic systems, the installation step should be treated like a privilege grant, not a routine package download.
What Makes the Payload and the Caller Part of the Risk
curl | bash is brittle because both the script and the execution context are mutable. A server can serve different content by time, region, headers, or caller identity, and the agent may not notice the difference. That means the same command can produce a benign outcome in review and a different outcome at runtime.
For an agent, that variability is material because the caller is not just a browser or a developer terminal. The caller can be an automated principal with broader filesystem, network, or token access than a human would be given for the same task. The install action therefore becomes a trust decision tied to AI Agent Authorisation Guide and the scope of authority granted to the agent.
In practice, the most dangerous version of this pattern is when the installer is trusted because it is “just setup.” Setup code often runs with the widest available privileges, which makes it a high-value place for credential theft, persistence, or tampering with future tool behaviour.
How to Replace the Shortcut Without Freezing Delivery
The right response is not to ban all automation, but to make installation deterministic and attributable. A safer pattern is to download first, inspect or verify second, and execute only after the artifact has been pinned to a known source or digest. That preserves automation while removing the live, unaudited execution step.
Agents should also be constrained so that they cannot treat every installation as self-authorising. The closest useful control is to require per-action approval or a hard policy boundary for anything that would add executable code to the environment, especially when the tool can later reach production systems or sensitive secrets. Zero Trust for AI Agents is the right mental model here: verify the request, limit standing privilege, and assume that any fetched code may be hostile until proven otherwise.
For teams building or operating agent workflows, a good rule is simple: if the install command can alter the agent’s own future behaviour, it should be treated as a change to the control plane, not a convenience task. That is also where AI Coding Agents Security Guide is useful, because terminal-based agents and coding assistants are especially exposed to supply chain and sandboxing mistakes.
Risk and Threat Considerations
curl | bash creates a direct execution path from remote content to local authority, which means the main risk is code injection through a trust shortcut. For AI agents, the risk is sharper because the caller may already have broad access, making a single installer enough to plant persistence, steal tokens, or modify later tool use.
Failure mechanism: The agent executes a fetched script before verifying integrity, origin, or purpose, and the server can tailor the payload to the caller or the moment.
Impact: An attacker can turn an ordinary install step into code execution, credential exposure, supply chain compromise, or long-lived agent misuse.
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 SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent installs can turn fetched code into delegated privilege abuse. |
| ASI02 — Tool Misuse | curl | bash makes tool installation a direct misuse path for autonomous execution. | |
| Recommendation — Enforce approval and least privilege before agents execute fetched installers. Restrict agents to vetted tools and block arbitrary shell execution. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Installer code can expose credentials or tokens already present in the agent context. |
| NHI-07 — Long-Lived Secrets | Agent-install workflows often fail when long-lived tokens are present in the environment. | |
| Recommendation — Keep secrets out of install contexts and rotate any exposed credentials immediately. Replace long-lived secrets with short-lived credentials before automated installs run. | ||
| NIST SP 800-53 Rev 5 | SA-10 — Developer Configuration Management | The question concerns controlled acquisition and execution of third-party code. |
| CM-11 — User-Installed Software | Direct-pipe installs bypass review and software approval controls. | |
| IA-5 — Authenticator Management | Installer compromise can expose or misuse the credentials the agent carries. | |
| Recommendation — Require controlled sourcing and approval for installer code before execution. Authorize only approved software sources and block unsanctioned installs. Rotate and protect credentials that the installation path could expose. | ||
| MITRE ATT&CK | T1204 — User Execution | The attacker relies on the agent executing fetched code as part of the install path. |
| Recommendation — Detect and constrain execution paths that depend on user or agent-triggered scripts. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Tool installs must be inventoried and controlled to prevent unvetted code execution. |
| Recommendation — Inventory approved tools and remove the ability to install unsanctioned software. | ||
Practitioner Guidance
What to verify: Confirm whether the installer is immutable, whether the source is pinned, and whether the command can execute before inspection. If the answer to any of those is no, treat the install path as untrusted and require an offline or prevalidated artifact instead.
Decision rule: If the agent can reach secrets, production endpoints, or signing material, do not allow direct pipe-to-shell installation. Use a reviewed package source, explicit approval, or a controlled build step that separates retrieval from execution.
Practitioner takeaway: The important boundary is not “human versus machine,” it is “reviewed versus executable.” Once an agent can run fetched code on its own authority, installation becomes a privilege event, not a download.