ChainDrop shows repository hooks can execute AI agent attacks

At a glance

What this is: ChainDrop is a supply-chain campaign that turns repository hooks and agent startup actions into execution points for malware and credential theft.

Why it matters: It matters to IAM and NHI practitioners because developer identities, CI/CD tokens, and agent harness permissions can be abused before traditional controls or model-layer policies have a chance to intervene.

👉 Read Pillar Security's analysis of ChainDrop and AI agent execution risk

Context

Repository trust has become an execution problem, not just a code-review problem. When a cloned project can trigger startup hooks before a developer makes a decision, the security boundary shifts from package installation to workspace initialization, which is exactly where agentic workflows and developer credentials intersect.

That makes this topic relevant to identity governance as well as endpoint and supply-chain security. AI coding tools, local shells, and CI/CD runners all inherit authority from the developer session, so repository-controlled instructions can become a path to Non-Human Identity abuse when tokens, secrets, and automation credentials are already present.

Key questions

Q: What breaks when repository hooks are allowed to run before security checks?

A: The trust model breaks because a repository can supply executable startup behaviour that a local tool runs with the developer’s authority. That means malware can execute before prompt review, install-time scrutiny, or in-session policy enforcement. The right control point is outside the repository, where startup actions can be evaluated before any code runs.

Q: Why do developer tokens and CI/CD secrets create such high risk in agentic environments?

A: They act like live Non-Human Identities, so once attackers steal them they can impersonate trusted automation across repositories, build systems, and cloud services. In agentic workflows, those credentials are often present on the same workstation that opens untrusted code, which turns local execution into a supply-chain breach path.

Q: How do security teams know if agent harness controls are actually working?

A: Look for two signals: untrusted repository configuration being blocked before execution, and a clean correlation between allowed hooks and the processes they launch. If tools only detect suspicious behaviour after a process starts, then you have telemetry, not control. Effective governance stops the conversion from repository state to execution.

Q: Who is accountable when a poisoned repository leads to credential theft?

A: Accountability is shared across repository security, endpoint control, and identity governance, because each layer failed to prevent the attacker from reaching reusable credentials. The practical question is not only who introduced the payload, but why the environment still contained access that malware could harvest and reuse.

Technical breakdown

How repository hooks become execution primitives

ChainDrop uses trusted lifecycle features such as Claude Code SessionStart hooks, VS Code folder-open tasks, and npm preinstall scripts to launch code without relying on a user to manually run a payload. The key technical shift is that the repository is not just containing code, it is supplying instructions that a trusted local tool interprets as startup behaviour. The malicious action is therefore executed under the developer’s local authority, often before the first prompt or install-time scrutiny. This is a harness problem, not a model jailbreak problem.

Practical implication: evaluate repository-supplied lifecycle actions before the IDE, agent, or package manager runs them.

Why AI agent harnesses expand the attack surface

AI agents introduce a separate control plane made up of hooks, rules, plugins, tasks, and workspace configuration. Attackers can target the model, the instructions supplied to it, or the harness that decides what runs and when. ChainDrop targets the harness layer, which is more deterministic than prompt injection because it does not depend on persuading the model. That makes agent startup configuration a high-trust execution surface that deserves the same scrutiny as autostart services or login scripts.

Practical implication: inventory agent harness components the same way you inventory startup services and privileged schedulers.

How credential theft and persistence follow execution

Once the loader runs, the payload searches for GitHub and npm tokens, cloud credentials, SSH keys, Kubernetes and Vault tokens, and database secrets. It also attempts CI/CD memory scraping on Linux by reading GitHub Actions runner memory, which can expose secrets that never appear in logs. From there, the campaign can compromise additional packages and repositories, then maintain persistence by monitoring token revocation state. This is classic post-execution abuse of developer and workload identity.

Practical implication: protect developer and runner credentials as live identities, not as static artifacts confined to logs or vaults.

Threat narrative

Attacker objective: The attacker wants to harvest developer and CI/CD credentials, then use those identities to spread through repositories and packages at supply-chain scale.

1. Entry occurs when the attacker plants repository-controlled hooks or package lifecycle scripts that a trusted tool will execute during workspace open or install.
2. Credential access follows as the loader enumerates developer, cloud, and CI/CD secrets, including tokens, SSH keys, and runner memory content.
3. Escalation and propagation happen when stolen credentials are used to compromise additional repositories and packages while persistence tracks token revocation.
4. Impact is supply-chain reach across developer environments, CI/CD systems, and downstream package consumers.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Repository hooks are now a supply-chain execution layer. The article shows that lifecycle features such as folder-open tasks and session-start hooks can be weaponised because they are treated as trusted configuration. That changes the defender’s assumption from "what package is installed" to "what local automation is allowed to run," which is a more dangerous boundary in agent-heavy development environments. Practitioners should treat repository-controlled startup logic as executable input, not metadata.

AI agent harnesses create a new governance gap between model safety and endpoint control. Model guardrails cannot stop code that runs before a prompt is sent, and endpoint tools alone may not understand why a configuration file launched the process. That is a distinct governance problem for agentic AI: the system that starts the agent can be the attack vector. Organisations need harness visibility, pre-execution policy, and provenance checks, not just prompt filtering or EDR telemetry.

Credential theft in these campaigns is an identity failure, not only a malware problem. The payload targets tokens, SSH keys, cloud credentials, and CI/CD secrets because those artefacts function as Non-Human Identities in practice. Once stolen, they let attackers move laterally across repositories, build systems, and package ecosystems with legitimate authority. The specific failure mode is standing credential exposure inside developer and runner environments, and that is what governance must address.

Workspace trust is becoming a control-plane decision. A repository can now influence when execution starts, which tool consumes the instruction, and whether the developer session inherits the malicious action. That makes workspace trust comparable to authorisation, not just file safety. The named concept here is harness-mediated execution risk: trusted local tooling converts attacker-controlled repository state into code execution before conventional policy layers engage. Practitioners should build controls around that conversion point.

Secret masking is not enough when secrets are already in memory. The campaign’s attempt to read GitHub Actions runner memory shows why log filtering and output redaction do not cover all credential exposure paths. The stronger lesson is that secret protection must extend to process memory, runner isolation, and token scope. Organisations should assume that any identity material available to a local process can be harvested once execution occurs.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• For a deeper control perspective, see OWASP NHI Top 10 for agentic application risks that map to tool misuse, identity abuse, and harness-level compromise.

What this signals

Harness-mediated execution risk: teams should now treat repository startup logic, IDE tasks, and agent hooks as privileged control points that deserve the same scrutiny as login scripts and scheduled jobs. The practical shift is to enforce policy before execution, not after process telemetry appears. For teams aligning to external standards, NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both support governance thinking that moves left of runtime.

Developer and runner credentials will keep attracting attackers because they often sit close to cloud, package, and CI/CD authority. That means NHI programmes need to expand beyond vaulting and rotation into provenance, memory exposure, and scope reduction. The signal for practitioners is clear: if a token can survive in a workstation or runner long enough to be reused, then its lifecycle is too loose for modern agentic workflows.

For practitioners

• Pre-authorise repository startup behaviour Block or quarantine repository-controlled hooks, tasks, and autostart files until they have been checked against an allowlist of approved workspace behaviours. The control must sit outside the repository so a malicious commit cannot replace it.
• Separate agent harness trust from model trust Inventory agent startup mechanisms, extension points, and workspace configuration files, then classify them as executable surfaces with independent policy. Do not rely on prompt filtering to secure code that runs before the first model call.
• Reduce the value of stolen NHI secrets Scope GitHub, npm, cloud, Kubernetes, and Vault credentials to the smallest possible task boundary, and rotate them aggressively when they are present on developer workstations or CI/CD runners. Treat runner memory as a sensitive secret store, not a safe intermediate location.
• Correlate endpoint alerts with repository provenance Join process creation, credential access, and outbound network telemetry to the exact repository file or hook that triggered execution. Without that provenance link, security teams will detect malware behaviour but miss the attacker-controlled instruction that caused it.

Key takeaways

• ChainDrop shows that repository configuration can become executable input before a developer intentionally runs code.
• The campaign’s real target is identity authority, including tokens, keys, and runner memory that function as Non-Human Identities in practice.
• Organisations need pre-execution policy for agent harnesses, because post-execution detection cannot stop startup-time compromise.

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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Pre-execution Policy: Pre-execution policy is a control that evaluates whether a command or startup action may run before the local system converts it into a process. It is stronger than post-execution detection because it can stop malicious behaviour at the point of interpretation, not after damage begins.

What's in the full report

Pillar Security's full blog covers the operational detail this post intentionally leaves for the source:

• IOC appendix with file hashes, paths, and persistence artefacts for the malicious loaders and hooks.
• Detailed breakdown of the specific repository configuration files used across Claude Code, VS Code, Gemini CLI, and Cursor paths.
• Process-level memory-scraping indicators for GitHub Actions runners and the shell patterns the payload used to hunt secrets.
• Expanded discussion of the agentic endpoint detection approach used to correlate hooks, process launches, and credential access.

👉 The full Pillar Security post covers repository hooks, credential theft paths, and persistence indicators.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security teams build the governance discipline needed for developer, workload, and agent-driven environments.