ChainDrop shows repository hooks can execute AI agent attacks

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Pillar Security's research: ChainDrop is an ongoing supply-chain campaign that turns repository configuration into execution, with hooks able to launch payloads before normal review, install, or agent interaction.

Why it matters: It matters because AI agent and developer tooling now inherit authority from repository-controlled startup paths, so identity, workspace trust, and pre-execution policy become part of security control design.

Context

ChainDrop is a software supply-chain problem with an identity consequence: repository-controlled startup paths can inherit developer authority before anyone has assessed the workspace. Traditional review assumptions fail when configuration files, hooks, and task definitions are treated as normal project settings even though they can start local code.

For AI agents, this expands the attack surface beyond prompts and model outputs to the harness that launches the agent and grants it local context. The result is a governance gap between repository provenance, workspace trust, and executable initialization, and that gap is increasingly relevant wherever coding assistants or build-time automation operate inside the developer environment.

Key questions

Q: What fails when repository hooks are allowed to execute before review?

A: The failure is that trusted project configuration becomes executable input before anyone has validated the workspace or the hook’s purpose. That collapses the boundary between code and control plane, letting attacker-supplied startup logic inherit local authority from the developer tool itself. The result is pre-execution compromise, not just post-execution malware detection.

Q: Why do repository-controlled hooks create a security problem for AI agents?

A: They give attacker-controlled repository content a path to run local commands through the agent harness, which means the agent can act on hostile configuration before a prompt is even issued. The risk is not the model thinking badly. The risk is the host environment trusting a repository file enough to execute it automatically.

Q: How do security teams know whether hook-based execution is actually being contained?

A: Look for evidence that startup actions cannot run without an external approval point and that repository settings do not determine their own trust. If a workspace can still launch code from project configuration alone, containment is not in place. Effective control shows up as blocked or reviewed startup paths, not just better alerting after launch.

Q: What should teams do when a repository has already triggered local execution?

A: Contain the workstation or runner, revoke any exposed tokens, and assume the payload may have searched for cloud, GitHub, SSH, and CI/CD credentials. Then review the repository settings that enabled the launch and any downstream packages or repos the stolen credentials could reach. The immediate priority is limiting propagation, not preserving the session.

Technical breakdown

Repository hooks as execution primitives

Repository hooks, workspace-open tasks, and session-start actions are legitimate automation features, but they also function as execution primitives when a trusted tool interprets them as commands. In ChainDrop, the malicious configuration did not need to persuade the model to misbehave. It only needed the development environment to honor repository-controlled initialization. That shifts the problem from prompt security to lifecycle security, because the risky decision happens before a first prompt, model call, or manual install step. The key technical point is that the repository supplies instructions while the local tool supplies authority.

Practical implication: Treat repository-controlled startup paths as executable content and gate them before the IDE or agent can run them.

Why agent harnesses are a distinct attack surface

An AI agent is not just a model. It is a system that includes prompts, tools, host integrations, workspace rules, and the runtime harness that decides when execution occurs. ChainDrop targets that harness layer by using legitimate initialization behavior to launch code locally. That is different from classic prompt injection because the attacker does not rely on model compliance. The agent harness becomes the control plane for local authority, which means security must inventory hooks, rules, and startup tasks alongside traditional software artifacts.

Practical implication: Inventory agent harnesses and workspace rules the same way you inventory secrets, dependencies, and executables.

Pre-execution policy versus endpoint detection

Endpoint detection can see process ancestry, file access, credential access, persistence, and outbound activity after a process starts, but it usually cannot tell whether a repository-controlled hook was appropriate for that workspace. In ChainDrop, the critical question is not only what process ran, but what should have been allowed to run before the first local command executed. That makes pre-execution policy essential. The control point has to sit outside repository-controlled files so it cannot be replaced, reordered, or neutralised by the same project settings it is meant to police.

Practical implication: Enforce startup-policy checks outside the repository boundary so hook approval happens before execution, not after.

Threat narrative

Attacker objective: The attacker wants to turn trusted developer and agent initialization paths into a credential theft and propagation mechanism that spreads across packages and repositories.

1. Entry occurs when a developer opens a compromised repository or consumes a poisoned package that carries repository-resident startup logic.
2. Credential harvesting follows as the payload searches for GitHub, npm, cloud, SSH, Kubernetes, Vault, and database credentials on developer workstations and CI/CD runners.
3. Escalation and persistence occur when stolen tokens are used to compromise additional packages and repositories, while token-monitoring logic reacts to revocation.
4. Impact is repository compromise at scale, with AI agent and developer workflows executing attacker code before normal review or install controls can intervene.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• ChainDrop npm worm 2026: A self-propagating npm worm starting with keyv hit 444 packages in hours, harvesting publishing tokens, CI secrets, cloud keys and AI tool credentials.

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

Repository-controlled hooks are now a governance boundary, not just a convenience feature. ChainDrop shows that startup commands embedded in repository settings can become executable input long before traditional controls see a model prompt or package install. That means the primary question is no longer whether the repository looks trusted, but whether the workspace is allowed to convert repository content into local authority. Practitioner conclusion: treat hook execution approval as a policy decision, not a developer preference.

Agent harness security is the missing control plane for AI-assisted development. The campaign succeeds because the harness, not the model, is the object being manipulated. AI security programmes that focus only on prompts, output filtering, or model guardrails leave a gap where local lifecycle automation can trigger code with inherited credentials. Practitioner conclusion: build controls around harness inventory, workspace provenance, and startup-path authorisation.

Pre-execution governance now matters more than post-execution detection for agentic workflows. Once a hook launches, EDR can help with telemetry, but it cannot restore the decision that allowed the hook to run in the first place. This creates a named governance gap: the pre-execution trust window, where repository content is still assumed to be configuration rather than code. Practitioner conclusion: close the trust window before execution starts.

Living off the agent harness is the right concept for this class of attack. The campaign uses legitimate lifecycle events as delivery primitives, so the security issue is not unusual malware but misuse of trusted orchestration paths. This is where identity security intersects with agentic AI: local developer identity, repository trust, and tool authority combine into one control problem. Practitioner conclusion: govern the harness as a privileged pathway, especially where agentic AI tools consume repository instructions.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Pre-execution control is the new control point for agentic workflows. Once repository settings can start local processes, the important boundary is no longer the prompt or even the model channel. The boundary moves to the moment a workspace is opened, which is where governance must decide whether project configuration is allowed to become authority.

Living off the agent harness: this is the failure mode teams should now name explicitly. It means a hostile repository does not need to break the agent, only to use the agent’s own startup path to run code under inherited trust. That changes review, detection, and onboarding workflows for any team using coding assistants or local agent runtimes.

For practitioners

• Restrict repository-controlled startup actions Block automatic execution of workspace-open, session-start, and preinstall actions unless they have been explicitly approved outside the repository boundary.
• Inventory agent harness configuration files Track .claude/settings.json, .vscode/tasks.json, and other agent or IDE settings that can launch commands, then review them with the same rigor as executable code.
• Separate trust in code from trust in workspace settings Require provenance checks for repository configuration so a trusted-looking repository cannot silently inherit the authority to run local commands.
• Correlate hook execution with endpoint telemetry Join repository-originated configuration events to process ancestry, credential access, memory reads, and network connections so alerting reflects the full attack path.
• Harden CI/CD and developer credential exposure Assume a malicious hook can search for GitHub, npm, cloud, SSH, and Vault tokens, so narrow token scope and monitor for unusual access from development tooling.

Key takeaways

• ChainDrop shows that repository hooks can turn ordinary workspace setup into a pre-execution compromise path for AI agents and developer tooling.
• The campaign matters because startup configuration, not just prompts or packages, can expose credentials and launch payloads before normal review controls apply.
• Teams need external approval for hook execution, because post-launch detection cannot undo a trust decision made at workspace initialization.

Key terms

• Agent Harness: The agent harness is the runtime layer that wraps a model and turns it into an acting system. It usually includes the loop, tools, context handling, permissions, hooks, and logs. In security terms, it is often the real place where privilege sits and where identity evidence must be governed.
• Repository-controlled Execution: Repository-controlled execution happens when files committed in a project cause local tools to run commands automatically. In practice, that means trusted startup settings, task definitions, or lifecycle scripts can become an attacker delivery mechanism if an organisation treats them as passive configuration.
• Pre-Execution Governance: Pre-execution governance is the set of controls that evaluate whether a command, hook, or task may run before the environment launches it. It matters when security decisions must happen outside repository-controlled settings, because post-launch detection cannot undo an unsafe startup decision.
• Workspace Trust: A trust control in code editors that separates passive file viewing from active execution of project-defined tasks. When disabled or bypassed, the editor can run repository instructions in the user’s context, which turns source control content into an execution path.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes that agentic workflows now depend on.