💻 computer science

Sleeper Channels and Provenance Gates: Persistent Prompt Injection in Always-on Autonomous AI Agents

This paper introduces "sleeper channels," a persistent prompt injection vulnerability in always-on autonomous AI agents where untrusted inputs persist and later execute through different interfaces, and proposes a tiered defense centered on "provenance gates" that use canonical action-instance digests and owner attestations to prevent such attacks, supported by a static audit tool and runtime adapter.

Original authors: Narek Maloyan, Dmitry Namiot

Published 2026-05-14

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Narek Maloyan, Dmitry Namiot

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a very helpful, always-on personal assistant living on your laptop. This assistant can read your emails, manage your calendar, write code, and even install new tools for you. It's like having a super-smart intern who never sleeps.

The paper "Sleeper Channels and Provenance Gates" warns us about a specific, sneaky way to hack this assistant. Here is the breakdown in simple terms:

1. The "Sleeper Channel" Attack: A Delayed Bomb

Usually, when we think of hacking an AI, we imagine someone tricking it right now with a weird command. This paper describes something different: The Sleeper Channel.

The Setup: Imagine a stranger in a public group chat (or a random email sender) asks your assistant to "save a tip for later." The assistant saves it, thinking it's helpful.
The Sleep: The stranger disappears. They don't talk to the assistant again. The "tip" just sits quietly in the assistant's memory, looking harmless.
The Wake-Up: Three weeks later, you ask your assistant, "Hey, can you set up that daily health check we talked about?" The assistant remembers the stranger's "tip," thinks it's a good idea, and sets up a scheduled task.
The Explosion: That task runs automatically, sending your private data to the stranger's secret server.

The Analogy: Think of it like a time-delayed booby trap. The attacker plants a seed (the "tip") in your garden. They walk away. Later, you innocently water the garden, and the seed sprouts into a trap that hurts you. The attacker isn't there when the trap springs; they just set it up earlier.

2. Why Current Defenses Fail

The paper explains that current security measures are like a bouncer who only checks your ID at the door.

If you walk in with a stranger, the bouncer checks the stranger.
But if the stranger whispers a secret into your ear, and you walk back in alone later to ask for a favor, the bouncer doesn't know you are carrying that secret.
The AI sees your request ("Set up the health check") and thinks, "Oh, that's my owner asking!" It forgets that the idea for the health check came from a stranger.

The paper calls this a "Confused Deputy" problem. The AI is the deputy; it's doing what you asked, but it's confused about who actually came up with the dangerous idea.

3. The Solution: The "Provenance Gate"

To fix this, the authors propose a new security system called Provenance Gates.

The Analogy: The "Receipt" System
Imagine every single piece of information the AI uses has a digital receipt attached to it.

If the AI reads an email from a stranger, that email gets a receipt saying: "Source: Stranger."
If the AI writes a note based on that email, the note inherits the receipt: "Source: Stranger."
If the AI later tries to set up a scheduled task based on that note, the system checks the receipt.

The Gatekeeper (The "Provenance Gate"):
Before the AI is allowed to do anything important (like sending an email, changing a file, or setting a schedule), it must pass through a security gate.

Check the Receipts: The gate looks at the "receipts" of everything the AI is using to make that decision.
The Rule: If any part of the idea came from an untrusted source (like the stranger), the gate slams shut.
The Exception: The only way to open the gate is if you (the owner) explicitly say, "Yes, I trust this specific action." But you have to do it fresh for that specific action, not just once for a general idea.

4. What They Actually Did

The authors didn't just write a theory; they built a prototype to prove it works.

The Test: They took a real, open-source AI assistant (called OpenClaw) and simulated the "Sleeper Channel" attack. They showed that without their new gate, the AI happily sent data to the attacker.
The Fix: They installed their "Provenance Gate" (which they call D2).
The Result: When the AI tried to set up the attacker's trap, the gate checked the receipts, saw the "Stranger" tag, and blocked the action. The attack failed.

5. The Bottom Line

The paper argues that as AI agents become more powerful and stay "always-on," we can't just trust them to remember what is safe. We need a system that tracks the history of every idea the AI has.

Old Way: "Did the owner ask for this?" (Yes -> Do it).
New Way: "Did the owner ask for this, AND did the owner approve the source of the idea behind it?" (If the idea came from a stranger -> STOP).

The authors call this a "tiered defense," meaning they have a basic version and a stronger version, but the core idea is simple: Don't let the AI act on ideas it picked up from strangers without a fresh, explicit "OK" from you.

Technical Summary: Sleeper Channels and Provenance Gates

Problem Definition: Sleeper Channels

The paper identifies a novel threat class in "always-on" autonomous AI agents (e.g., OpenClaw, Hermes Agent) termed Sleeper Channels. Unlike traditional prompt injection, which typically occurs within a single turn or session, a sleeper channel attack decouples the intake ( $T_0$ ) from the effect ( $T_1$ ) across time, storage substrates, and communication surfaces.

In this scenario, an untrusted input (e.g., from a group chat or email) is ingested by the agent and persists as a memory note, a self-authored skill, a scheduled job, or a filesystem patch. This artifact survives within the agent's authority boundary until a benign trigger (such as a later owner request or an autonomous loop) retrieves and executes it. The attack fires through a different surface than the intake, often leveraging the "confused deputy" condition where the agent executes a command on behalf of the owner, unaware that the command's parameters originated from an untrusted source.

The authors define the class using two axes:

Persistence Substrate: Where the malicious instruction survives (Memory, Self-authored Skill, Filesystem, Scheduled/External Trigger).
Firing-Separation: The degree of decoupling between intake and execution (Same-session, Cross-channel, Cross-actor, Cross-execution-context).

The paper argues that existing literature treats these capabilities in isolation (e.g., single-turn injection or memory poisoning) and fails to address the unified threat of multi-substrate persistence combined with delayed, cross-surface firing.

Methodology and Threat Model

The authors adopt a threat model where the attacker is "untrusted-but-admitted," meaning their content reaches the agent via enabled but low-trust channels (group chats, emails, fetched URLs). The defender is the agent owner. The analysis is anchored to a specific pinned commit of the OpenClaw runtime (commit 3120401f...1829b1b6), with all claims verified against the vendored source code.

The paper presents a taxonomy (Table I) mapping persistence substrates ( $M_1$ – $M_5$ ) against firing separations ( $C_0$ – $C_4$ ). It highlights four illustrative scenarios that prior work underspecifies:

A4 (Running Example): A "Cron via confused deputy" attack ( $M_5 \times C_4$ ). An attacker embeds a malicious webhook URL in an email. The agent summarizes this into memory. Days later, the owner asks the agent to "set up that daily health-check." The agent retrieves the note, synthesizes a cron job with the attacker's URL, and executes it. The persistence is the cron entry; the firing occurs in the system cron daemon, outside the agent process.
A2: A skill-trojan via group chat ( $M_3 \times C_2$ ).
A3: Cross-channel exfiltration via memory ( $M_2 \times C_2$ ).
A5: Dotfile patching ( $M_4 \times C_4$ ).

Key Contributions: The Provenance Defense (D2)

The paper proposes a tiered defense strategy, with D2 being the core contribution. D2 moves the enforcement boundary outside the model loop, relying on provenance tracking and action-instance attestation.

Core Mechanisms

Artifact Tagging and Propagation: The runtime maintains a provenance state ( $\Pi$ ) for every artifact (memory, skills, files, tool calls). Tags ( $\tau$ ) record the source (Channel, Principal, Device). Untrusted inputs strictly enlarge the provenance set.
Action-Instance Digest: Every consequential action $\alpha$ is hashed into a canonical digest $\delta(\alpha)$ using a collision-resistant hash (SHA-256) over the normalized action bytes (including arguments and target). This defeats "paraphrase laundering" where a model rewrites an attacker's instruction to hide its origin.
Mediation Hooks: The defense requires complete mediation via ten runtime hooks (H1–H10).
- Update Hooks (H1–H5): Populate tags and propagate provenance during intake and creation.
- Gate Hooks (H6–H10): Decision points before side-effecting dispatches (e.g., shell execution, file writes, scheduling).
One-Shot Owner Attestation: For actions with untrusted provenance, the gate requires a grant $g$ from a trusted principal. This grant must match the action digest $\delta(\alpha)$ , contain a unique nonce (to prevent replay), and arrive over a hardware-attested companion channel ( $\Sigma$ ) that the model cannot emit to.

Soundness Theorem

The authors provide a soundness theorem for D2, assuming seven runtime invariants (Mediation, Tag, Causal, Channel, GrantAuth, Nonce, Hash). The theorem states that a dispatch is allowed only if:

All contributing artifacts in the causal set have trusted provenance ( $\Pi_\alpha \subseteq T$ ), OR
A valid, fresh, owner-trusted attestation exists for the exact action instance.

This design ensures that even if the model is tricked into generating a malicious command, the gate will deny it unless the owner explicitly attests to that specific action instance via a secure channel.

Results and Evaluation

The paper does not claim a deployed production system but provides a source-anchored feasibility argument and an executable reference implementation.

Empirical Probe (A4): In a "smoke probe" of 20 single-shot trials, a frontier reasoning model was given the OpenClaw security warning and the malicious context. 19/20 models emitted a valid cron.add tool call pointing to the attacker's URL, demonstrating that in-context warnings (D1) are insufficient to prevent the attack.
Reference Implementation: A companion artifact at github.com/maloyan/sleeper-channels includes:
- A TypeScript implementation of the D2 gate decision function.
- A static audit suite (13 cases) verifying that the cited source lines in OpenClaw exist and match the threat model.
- A runtime adapter implementing hooks H1, H2, H3, H6, and H9 around the cron path.
- A test suite of 42 cases covering decision rules, multi-input laundering, and grant replay.
Verification: The runtime adapter successfully demonstrated that the A4 attacker call is denied due to untrusted provenance, while benign owner-only cron jobs are admitted.

Significance and Claims

The paper positions itself as a position and design paper that fixes the threat class of sleeper channels and provides a formal specification for defense.

Novelty: It is the first work to treat the combination of multi-substrate persistence and delayed, cross-surface firing as a unified threat class in OS-live agents.
Defense Placement: It argues that provenance signals must be enforced outside the model loop. Relying on the model to refuse untrusted inputs (D1) is brittle against adaptive attacks.
Formalism: It introduces a soundness theorem and a canonical action-instance digest to defeat paraphrase laundering and replay attacks, addressing gaps in prior community proposals (e.g., upstream issue [10]) that lacked empirical grounding and formal enforcement specifications.
Modesty: The authors explicitly state that empirical attack-success rates, full deployment efficacy, and utility-cost trade-offs are deferred to a preregistered follow-on study. The current work establishes the taxonomy, the formal defense, and the feasibility of the attack and defense on a specific runtime commit.