Curl | bash becomes a credential risk for AI agents

At a glance

What this is: This is an analysis of why fetch-and-execute installs are harder to trust when an AI agent, not a laptop user, runs the installer with delegated credentials.

Why it matters: It matters because IAM and NHI teams have to govern what an agent can fetch, execute, and exfiltrate after installation, not just what a script looked like at download time.

By the numbers:

• The search across 2.7 million events from four internal agent instances flagged 3,299 events, but at most 73 were real commands, roughly 2 percent.
• A plain text search for the download-and-run pattern produced about 98 percent false alarms in Manifold Security's sample.
• Scanner coverage of the 855 public skills found a real download-and-run command in each reviewed skill set, with Manifold's allowlist adding another 17 percent of verified installers.

Context

Fetch-and-execute has always traded integrity for convenience, but the governance gap widens when the runtime subject is an AI agent rather than a human operator. The primary problem is not the shell syntax itself, but the fact that the code path now runs with delegated identity and can make follow-on network calls, file writes, and tool invocations without a human watching each step.

In practical terms, the trust boundary has moved from the installer to the session. A package, skill, or MCP component may look harmless at rest, yet the server can alter what it returns at request time and the agent can act on it immediately. That is why provenance, runtime attribution, and post-fetch behaviour matter more than a one-time review of the script.

Key questions

Q: What breaks when AI agents use curl | bash to install tools?

A: 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.

Q: Why do trusted domains create extra risk for AI agent security?

A: Because trust can be inherited by content that was never meant to deserve it. When an agent treats allowlisted domains as safe inputs, attackers can hide payloads in places the workflow already trusts, then use that trust to trigger exfiltration or manipulation without obvious user action.

Q: How should security teams monitor agent installs after the download?

A: Track the agent's actual behaviour after the fetch, including tool execution, file reads and writes, and outbound calls. Those signals reveal whether the installer behaved like ordinary setup or like a compromise path. Network destination alone is too weak to separate benign installer traffic from abuse.

Q: Should organisations allow AI agents to run remote installers at all?

A: Only when the task scope, provenance checks, and runtime logging are strong enough to make the trust decision explicit. If an agent can install, re-fetch, and act on remote code with broad credentials, the organisation is accepting a moving trust boundary that is difficult to audit and hard to contain.

Technical breakdown

Why curl | bash is more dangerous in agent sessions

curl | bash is risky because the shell starts executing while the download is still in progress, so the operator may never review the exact bytes that ran. In an AI agent workflow, that pattern becomes more consequential because the agent can execute the installer, interpret its output, and continue with downstream actions using the same delegated identity. The key failure mode is not just unseen code, but unseen code plus autonomous follow-on behaviour. A remote server can also tailor the payload to the caller, which means the file a scanner fetched and the file the agent ran do not have to match. Practical implication: treat installer execution as a live identity event, not a static file-download problem. See the AI Coding Agents Security Guide.

Practical implication: Instrument the agent session so installer execution, tool use, and network calls are visible together.

Why the same URL can deliver different code

A trusted domain is only a locator, not a promise of immutable content. The article points to cases where domain ownership changed, build systems were compromised, or the server served conditional payloads based on headers, user agent, IP range, or timing. That means integrity checks performed at one moment do not prove what the agent saw later, and content review on a different machine may be irrelevant to the live session. For identity governance, this is a supply-chain style trust problem attached to an execution identity. The agent does not know whether the upstream server is honest, compromised, or selectively malicious. Practical implication: anchor trust in signed artefacts and attestation, not in the apparent stability of a domain. See the Agentic AI Security Guide.

Practical implication: Require provenance and signature checks before execution, then re-validate when the agent later re-fetches content.

Why perimeter detection misses benign-looking abuse

Perimeter tools struggle here because the destination often looks legitimate. Traffic to GitHub, Anthropic, a CDN, or an object store can be normal for an agent, so the endpoint alone is not a useful discriminator. The article shows that even searches for download-and-run patterns or suspicious outbound traffic produced large volumes of false positives, while genuine misuse hid inside ordinary-looking sessions. That shifts the control problem from where the connection went to what the agent did with the fetched material. In identity terms, the context of the call matters more than the domain label. Practical implication: correlate tool execution, file access, and outbound calls to build a usable detection signal. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Correlate post-fetch actions so ordinary installer traffic does not mask real misuse.

Threat narrative

Attacker objective: The attacker wants code execution and trusted-channel abuse from inside an agent session that already carries useful credentials and network reach.

1. Entry occurs when an agent installs or updates code from a remote source using a fetch-and-execute pattern such as curl | bash.
2. The credentialed session then executes the fetched content and may immediately call additional tools, read secrets, or interact with trusted services.
3. Impact follows when the server serves a conditional or malicious payload that abuses the agent's delegated identity for execution, exfiltration, or follow-on compromise.

Breaches seen in the wild

• Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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

Credentialed fetch-and-execute is now an identity problem, not just a software hygiene problem. The article shows that the same install pattern becomes materially different when the executor is an AI agent with delegated access and follow-on tool authority. That changes the control question from whether the script is readable to whether the runtime identity should be allowed to fetch, interpret, and act on remote code at all.

Static review is the wrong assurance model for conditional payload delivery. A URL can be clean for the analyst, malicious for the agent, and benign again for a later fetch because the server decides what to send at request time. That is a broken assumption in NHI governance: the idea that a reviewed install artifact is the same object the runtime identity will execute. The implication is that trust must move from artifact inspection to provenance-aware runtime governance.

Observability at the connection layer is too weak to govern agentic installation paths. The domain label tells you almost nothing about intent, because ordinary agent behaviour and malicious theft both ride over legitimate services. What matters is the sequence after fetch, including what tools ran, which files changed, and which outbound calls followed. Security teams need to govern the agent session as an identity event, not just the network flow.

Ephemeral installer trust debt: A single install command can accumulate hidden trust debt when the agent that runs it can later re-fetch, re-interpret, or re-execute remote content without review. That debt grows wherever developers treat initial provenance as equivalent to ongoing trust. The practitioner conclusion is to stop assuming a one-time check closes the risk window for an agent that keeps acting after installation.

From our research library:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Installer trust now has a runtime component: if the identity that runs the installer can also keep acting afterward, the security question is no longer whether the script was reviewed. The question is whether the session can prove what it fetched, what it executed, and what it touched next.

Trust decisions built around static artefacts fail when a server can vary output by client context. The better control plane is session-level attribution, where tool use, file access, and outbound calls become the evidence of whether the agent stayed inside its intended boundary.

AI systems often receive more access than humans performing the same job, and that pattern makes installer governance harder to justify when the agent can self-initiate follow-on actions. Programme owners should expect fetch-and-execute to become a recurring identity-control issue rather than a one-off secure-coding concern.

For practitioners

• Define agent installer trust boundaries Classify which agents may execute remote installers, which may only read them, and which must be blocked from fetch-and-execute paths entirely.
• Require provenance over bare URLs Pin releases to signed artefacts or verified hashes instead of latest tags, and reject installers that depend on mutable remote content.
• Log the full post-fetch session Capture the tools the agent ran, files it touched, and outbound requests it made after download so the runtime intent is visible.
• Triage runtime outliers, not domains Build detections around unusual post-install behaviour, such as new file writes, secret reads, or unexpected tool chaining, rather than domain reputation alone.

Key takeaways

• AI agents turn a familiar insecure install pattern into an identity-governance issue because the runtime actor can keep acting with delegated credentials after the fetch.
• The article's evidence shows why static review and domain reputation are weak controls when the server can vary what it serves by caller and timing.
• Practitioners need to move assurance from the installer itself to provenance, session logging, and post-fetch behaviour analysis.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · AI Agent Observability, Audit and Incident Response Guide · MCP Security Guide

Key terms

• Fetch-and-execute: A software installation pattern where a script downloads content from a remote source and immediately runs it. In an agentic environment, the risk is not only unseen code but also a runtime identity that can continue acting after the initial execution.
• Conditional payload delivery: A server behaviour where the same URL returns different content depending on caller context, timing, user agent, IP address, or other request attributes. This undermines static review because the inspected file may not match what the live session received.
• Runtime Identity: Runtime identity is the practice of making identity and authorization decisions at the moment an action occurs. For agents and workloads, it means access is validated against live context, not only against the identity state set during onboarding or provisioning. That makes accountability and scope enforcement possible inside fast-moving workflows.
• Provenance Validation: A control approach that verifies where a payment, credential, or approval came from, who authorised it, and whether its path matches expected business logic. It is stronger than appearance-based review because it anchors trust in lineage and context, not visual similarity.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.