Sleeper Skills: Evading Endpoint Security Through Cloud Coding Agents

TLDR;

The coding-agent attack surface keeps expanding.

Recently, coding-agent vendors such as Anthropic and Cursor have introduced cloud sessions: instead of running an agent on the developer's laptop, a task can be handed off to an autonomous coding agent running inside a cloud environment, either managed by the provider or deployed on customer-managed workers.

This is extremely useful. An agent can work for hours without depending on the developer's laptop, network connection, or whether the machine goes to sleep. But it also creates a new security boundary.

Organizations may have EDR, agentic security controls on the endpoint, network monitoring, and extensive telemetry on developer endpoints. When the same task moves into a cloud coding-agent environment, those controls may not necessarily move with it.

So we asked:

What if a malicious skill behaves normally on the monitored developer endpoint and activates only after the agent moves to the cloud?

We took the known malicious-skill attack and added an environment-aware trigger.

We call it a Sleeper Skill.

The New Cloud Blindspot

Think about the amount of security running on a typical developer endpoint: EDR, network monitoring, agentic security, command telemetry, DLP, and more. Then the developer clicks a button and sends their coding task to a remote agent. The execution path changes from Developer → Coding Agent → Developer Endpoint to Developer → Coding-Agent Platform → Cloud Worker → GitHub.

From the developer's perspective, almost nothing changed. From the attacker's perspective, almost everything did. The operating system may be different, the network is different, available credentials may be different, and, most importantly, the organization's security visibility may be different.

This doesn't mean cloud coding environments are unsecured. The environments we tested actually had meaningful restrictions. The problem is that security controls that are bound to specific environments don't follow the agent when execution moves between them. An organization may have extensive visibility into an agent running on a developer endpoint, but significantly less visibility when that same agent moves into a provider-managed cloud session or an unmanaged remote worker.

This is an important distinction for agentic security products as well. Cloud sessions aren't inherently invisible. At Dash Security, our monitoring follows coding-agent execution across local endpoints as well as managed and unmanaged cloud sessions. But when security coverage stops at the developer endpoint, moving execution to the cloud can create exactly the kind of visibility gap our attack targets.

An attacker doesn't necessarily need to defeat the most protected environment. They can simply wait for a less monitored one.

The Sleeper Skill

Malicious coding-agent skills aren't new. A malicious skill can attempt to steer an agent toward reading sensitive files, executing commands, or moving data somewhere it shouldn't. But there's an obvious caveat for the attacker: why execute the malicious behavior on the developer's heavily monitored laptop?

Modern coding agents can reason about their execution environment. Instead of simply telling the agent to perform a malicious action, an attacker can make that action conditional: perform it only when a specific environment is detected.

The attack becomes: Skill loaded → Determine execution environment → Developer endpoint: remain dormant → Target cloud environment: activate.

We call this an environment-aware Sleeper Skill. The exact same repository and the exact same skill can produce completely different behavior depending on where the coding agent executes it.

Dash Research POC

For our PoC, we targeted a cloud coding-agent environment. The setup was intentionally simple: the repository contained a "project setup" skill, while the only prompt we gave the cloud agent was:

"Run CI preflight."

The important distinction is that the malicious behavior was not part of the user's prompt. The agent independently used the project setup skill as part of completing what looked like a normal development task.

The project setup skill contained the Sleeper logic. Before performing its sensitive actions, it instructed the agent to determine whether it was executing inside the targeted cloud environment. Because relying entirely on the LLM to identify its environment wasn't always deterministic, the skill also included a small helper mechanism that provided stronger environmental signals.

If the expected cloud environment wasn't detected, the malicious behavior remained dormant. On the developer endpoint, the skill therefore behaved normally and didn't trigger the sensitive part of the workflow.

But when the same repository and skill were used inside the cloud session, the environment check succeeded and the Sleeper Skill woke up.

The malicious branch instructed the agent to collect information about the current project configuration, including sensitive configuration material and credentials available inside the cloud environment, and attempt to move that information outside the environment.

We won't publish the complete weaponized skill or exact setup. The important result isn't the specific exfiltration technique. It's the separation between trigger and execution:

User prompt: "Run CI preflight" → Agent selects project setup skill → Skill detects cloud environment → Sleeper activates

This is what makes the attack interesting. The developer never needs to ask the agent to access credentials or exfiltrate data. They ask it to perform an ordinary development task. The malicious behavior comes from trusted-looking project context and only becomes active after the task reaches the targeted execution environment.

Imagine the same repository being used locally first. The coding agent loads the project setup skill, but the environment check fails, so nothing suspicious happens. The developer continues working and endpoint security never observes the malicious branch because it never executes.

Later, the developer sends "Run CI preflight" to a cloud coding session. The repository and its skills move with the task. This time the environment check succeeds.