AI agents weaponized in CI/CD expose a new governance gap

At a glance

What this is: Pillar Security's research shows an AI agent chaining CI/CD exploitation, prompt injection, and malicious extension publishing into an end-to-end attack on open-source infrastructure.

Why it matters: It matters because IAM, PAM, and NHI controls built for stable identities and human-paced review cycles do not hold when the attacker can weaponize both pipelines and downstream AI tooling.

By the numbers:

• Pillar Security found an 11-second gap between fork creation and first push, showing machine-speed exploitation across the campaign.
• 59 seconds
• 11 minutes.

👉 Read Pillar Security's analysis of the hackerbot-claw AI agent campaign

Context

AI agent identity risk is no longer confined to chat interfaces or isolated tool use. In this case, an AI agent operated on natural-language instructions to scan repositories, exploit CI/CD weaknesses, and move from discovery to payload delivery in a single campaign.

For identity teams, the real issue is not only that the actor was automated, but that it could traverse trust boundaries designed for human-paced approvals and static workflow assumptions. That makes the problem relevant to NHI governance, agentic AI oversight, and the security of downstream developer identities and tokens.

Key questions

Q: What breaks when AI agents are allowed to act inside privileged CI/CD workflows?

A: What breaks is the assumption that repository inputs are still untrusted once a workflow starts running. If branch names, filenames, or pull request content can reach privileged shell steps, an AI-driven attacker can turn normal collaboration paths into code execution and publishing paths. That converts workflow automation into a control-plane exposure.

Q: Why do AI agents complicate least-privilege governance?

A: AI agents complicate least privilege because their action sequence is not fully knowable at provisioning time. The actor can decide which tools to call, in what order, and how to pivot based on runtime results. Traditional entitlements describe static roles. Agentic behaviour turns access into a moving target.

Q: How do security teams know when an AI instruction file has become a security control?

A: You know it has when changing that file can alter review outcomes, commit behaviour, or data handling. At that point it is no longer just documentation. It is policy-bearing context for the model, and attacker-writable changes should be reviewed like changes to any other privileged control.

Q: What should teams do when developer extensions can launch AI tools with permissive flags?

A: Treat the extension, the AI CLI process, and the credentials available on the endpoint as one attack path. Block silent process spawning where possible, alert on dangerous permission flags, and review whether extensions can invoke agents with broader access than a user would normally approve.

Technical breakdown

CI/CD privilege abuse through attacker-controlled workflow inputs

The campaign exploited workflows that trusted repository metadata such as branch names, filenames, and pull request content. In CI/CD systems, these inputs often reach shell contexts, composite actions, or privileged job steps. If the workflow runs with base-repository credentials or an org-scoped token, a single malformed input can become code execution, repository takeover, or marketplace publishing. The core failure is not just injection. It is privilege being granted before trust in the input has been established.

Practical implication: review every workflow that executes forked content with elevated repository credentials or reusable actions.

Prompt injection against project-local AI instructions

The attack also targeted an AI code reviewer by replacing a trusted project instruction file with adversarial content. That works because many AI coding tools treat local repository instructions as authoritative context during review or generation. Once poisoned, the model can be pushed toward unauthorized edits, false approvals, or social-engineering language framed as policy. This is a governance boundary problem: the AI system is being asked to trust files that an attacker can modify through the repository path.

Practical implication: treat project-local AI instruction files as privileged inputs and monitor them like policy artifacts.

Malicious extension as a delivery mechanism for AI agent abuse

The final stage used a compromised extension to spawn AI CLI tools with flags that bypassed normal permission prompts. That turns the developer workstation into an execution surface for credential collection and exfiltration. The extension did not need to contain traditional malware logic in the usual sense. It only needed to launch trusted AI tools in permissive modes and feed them a convincing prompt. This is supply chain abuse plus agent abuse, not just endpoint compromise.

Practical implication: inventory AI CLI usage on endpoints and alert on permissive flags launched by non-shell parent processes.

Threat narrative

Attacker objective: The objective was to convert CI/CD and developer trust into credential access, malicious artifact publication, and downstream AI-assisted exfiltration.

1. Entry occurred through CI/CD workflows that accepted attacker-controlled repository inputs and executed them with elevated permissions.
2. Credential access followed when the actor obtained org-scoped repository tokens and used them to publish malicious artifacts under a trusted publisher identity.
3. Escalation continued when the attacker weaponized a compromised extension to spawn AI coding agents in permissive modes for credential harvesting.
4. Impact was achieved through repository defacement, release deletion, and the publication of a malicious extension that could turn developer AI tools into exfiltration helpers.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

AI agent abuse in CI/CD exposes a governance gap between workflow trust and runtime intent. The campaign did not rely on exotic zero-days. It relied on workflows that trusted repository data too early and with too much privilege. That means the real failure mode is not just vulnerable automation, but trust assigned before actor intent is known. Practitioners should read this as a control boundary problem across OWASP-NHI and zero trust assumptions.

Prompt-injected agentic abuse changes the meaning of least privilege. Least privilege was designed for identities whose action set is known at provisioning time. That assumption fails when an actor can select tools, chain actions, and alter execution paths at runtime through natural-language prompts. The implication is not simply more controls. It is that traditional entitlement models stop describing the actor accurately once the actor can self-direct across tools.

Project-local AI instructions have become a privileged governance surface. Files such as CLAUDE.md can function like policy, but they are often governed like ordinary repository content. This campaign shows that when those files are attacker-writable, the attacker can redirect the model’s behavior without touching the model itself. Security teams need to treat model instructions as part of the control plane, not as documentation.

Malicious extensions are now a bridge between NHI compromise and autonomous misuse. The extension did not merely steal secrets. It created a runtime where trusted AI tools could be launched with maximum-permissive flags and fed exfiltration prompts. That is a named failure mode: agent-launch abuse through compromised software distribution. Practitioners should treat endpoint extensions, AI CLI permissions, and marketplace identity as a single governance chain.

Promptware turns familiar supply-chain risk into an identity problem. The campaign demonstrates that code signing, repository trust, and marketplace identity are insufficient if the next actor in the chain is an AI tool that obeys injected instructions. That is a broader field signal for NHI governance. Teams should expect supply-chain defense to merge with agent runtime governance rather than remain separate disciplines.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 33% of organisations report that their AI agents have accessed inappropriate or sensitive data beyond intended scope, which means most programmes still lack reliable behavioural visibility.
• For a control-by-control view of how agent and NHI risks are converging, see OWASP Agentic AI Top 10 for the latest threat model framing.

What this signals

Identity programmes need to start treating AI tool invocation as a governed event, not an endpoint side effect. Once a repository can spawn agents, review them, and push them toward credential access, the operational boundary is no longer just the CI runner or the IDE. Teams that already understand privileged automation should extend that discipline to AI processes that inherit human trust but act with machine speed.

Promptware is the new bridge between NHI compromise and downstream identity misuse. The attacker did not need a novel malware family to achieve impact. They needed a compromised delivery path, a permissive AI runtime, and a path to secrets already present on endpoints. That should push practitioners toward tighter inventory of AI-enabled processes and faster separation of publisher identity from local execution authority.

With 96% of technology professionals saying AI agents are a growing security threat, the governance challenge is already widely recognised, but recognition is not control. Programmes that rely on periodic review will miss agent behavior that unfolds inside a single session and leaves little durable evidence unless runtime telemetry is in place.

For practitioners

• Remove elevated trust from forked CI/CD inputs Audit workflows that process branch names, filenames, pull request metadata, or composite actions from forks while holding repository-level credentials. Separate untrusted inputs from privileged execution steps and flag any workflow that can reach shell context with base-repo authority.
• Classify AI instruction files as policy artifacts Track files such as CLAUDE.md, repository-level prompts, and review instructions as governed security objects. Restrict write access, alert on changes in protected branches, and review them with the same scrutiny used for deployment policy files.
• Monitor AI CLI process spawning on developer endpoints Detect claude, codex, gemini, copilot, and kiro-cli processes launched by IDEs or extensions rather than by a user shell. Pay special attention to flags that disable approval gates or widen filesystem access, because those are the settings this campaign tried to abuse.
• Separate marketplace identity from workstation privilege Review whether an extension publisher identity can be used to deliver payloads that inherit developer trust. Tie marketplace signing, endpoint controls, and secrets access together so a compromise in one layer does not become a publish-and-exfiltrate path in another.
• Instrument rapid probe-to-pivot behavior Set alerts for very short intervals between fork creation, first push, and privileged action in repositories that accept external contributions. The campaign’s machine-speed timings are a practical detection clue for both recon and escalation.

Key takeaways

• The campaign shows that AI agents can be used as both attacker tooling and target surface inside the same attack chain.
• Machine-speed probing, credential access, and malicious publishing all occurred inside a very short operational window, which is the scale signal practitioners should notice.
• Controls that keep attacker-controlled inputs away from privileged execution and treat AI instruction files as governed policy would have materially reduced the blast radius.

Key terms

• Promptware: Promptware is malicious content designed to make an AI system carry out harmful actions through instructions instead of code. In practice, it abuses the model's obedience to context, policy text, or local project prompts to redirect legitimate tools toward theft, exfiltration, or unauthorized changes.
• Project-local instructions: Project-local instructions are repository files or embedded prompts that shape how an AI tool behaves inside a specific codebase. When those files are writable by an attacker, they become a control surface, because the model may treat them as trusted guidance during review, generation, or remediation tasks.
• Agent-launch abuse: Agent-launch abuse occurs when software starts an AI tool or agent in a more permissive state than a human operator would approve. The danger is not only the launch itself, but the inherited trust chain from the parent process, the permissions granted at startup, and the data available in the session.
• CI/CD privilege boundary: A CI/CD privilege boundary is the point where untrusted repository content meets elevated execution rights. If that boundary is weak, a build or review workflow can become a route from ordinary contribution activity to token exposure, repository compromise, or supply-chain publishing.

Deepen your knowledge

AI agent governance and NHI control boundaries are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for privileged workflows and agentic runtime behaviour, it is worth exploring.

This post draws on content published by Pillar Security: Hackerbot-Claw adversarial agent targets top GitHub repos. Read the original.