💻 computer science

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

Dit artikel introduceert "slaapkanalen", een aanhoudende prompt-injectiekwetsbaarheid in altijd-aanstaande autonome AI-agenten waarbij onbetrouwbare invoer blijft bestaan en later via andere interfaces wordt uitgevoerd, en stelt een gelaagde verdediging voor die is gebaseerd op "provenance-poorten" die canonieke actie-instantie-digests en eigenaar-attestaties gebruiken om dergelijke aanvallen te voorkomen, ondersteund door een statisch audittool en een runtime-adapter.

Oorspronkelijke auteurs: Narek Maloyan, Dmitry Namiot

Gepubliceerd 2026-05-14

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Narek Maloyan, Dmitry Namiot

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een zeer behulpzame, altijd aanwezige persoonlijke assistent hebt die op je laptop woont. Deze assistent kan je e-mails lezen, je agenda beheren, code schrijven en zelfs nieuwe tools voor je installeren. Het is alsof je een superintelligente stagiair hebt die nooit slaapt.

Het artikel "Sleeper Channels and Provenance Gates" waarschuwt ons voor een specifieke, sluwe manier om deze assistent te hacken. Hier is de uitleg in eenvoudige bewoordingen:

1. De "Sleeper Channel"-aanval: Een vertraagde bom

Meestal, wanneer we denken aan het hacken van een AI, verbeelden we ons dat iemand het nu bedriegt met een vreemde opdracht. Dit artikel beschrijft iets anders: De Sleeper Channel.

De opzet: Stel je voor dat een vreemde in een openbare groepschat (of een willekeurige e-mailafzender) je assistent vraagt om "een tip voor later op te slaan". De assistent slaat het op, in de veronderstelling dat het behulpzaam is.
De slaap: De vreemde verdwijnt. Ze praten niet meer met de assistent. De "tip" zit gewoon rustig in het geheugen van de assistent en ziet er onschuldig uit.
Het wakker worden: Drie weken later vraag je je assistent: "Hé, kun je die dagelijkse gezondheidscontrole instellen waar we het over hadden?" De assistent herinnert zich de "tip" van de vreemde, denkt dat het een goed idee is, en stelt een geplande taak in.
De explosie: Die taak wordt automatisch uitgevoerd en stuurt je privégegevens naar de geheime server van de vreemde.

De analogie: Denk hierbij aan een tijdsvertraagde val. De aanvaler plant een zaadje (de "tip") in je tuin. Ze lopen weg. Later, giet jij onschuldig de tuin, en het zaadje ontkiemt tot een val die je pijn doet. De aanvaler is er niet bij wanneer de val springt; ze hebben het eerder opgezet.

2. Waarom huidige verdedigingen falen

Het artikel legt uit dat huidige veiligheidsmaatregelen lijken op een portier die alleen je ID aan de deur controleert.

Als je binnenkomt met een vreemde, controleert de portier de vreemde.
Maar als de vreemde een geheim in je oor fluistert, en je later alleen terugkomt om een gunst te vragen, weet de portier niet dat je dat geheim bij je draagt.
De AI ziet je verzoek ("Stel de gezondheidscontrole in") en denkt: "Oh, dat is mijn eigenaar die vraagt!" Het vergeet dat het idee voor de gezondheidscontrole van een vreemde kwam.

Het artikel noemt dit een "Verward Ondergeschikte" probleem. De AI is de ondergeschikte; het doet wat je vraagt, maar het is in de war over wie eigenlijk het gevaarlijke idee bedacht heeft.

3. De oplossing: De "Provenance Gate"

Om dit op te lossen, stellen de auteurs een nieuw veiligheidssysteem voor genaamd Provenance Gates.

De analogie: Het "Kassabon"-systeem
Stel je voor dat elk stukje informatie dat de AI gebruikt, een digitale kassabon heeft eraan gehecht.

Als de AI een e-mail leest van een vreemde, krijgt die e-mail een bon met de tekst: "Bron: Vreemde."
Als de AI een notitie schrijft op basis van die e-mail, erft de notitie de bon: "Bron: Vreemde."
Als de AI later probeert een geplande taak in te stellen op basis van die notitie, controleert het systeem de bon.

De poortwachter (De "Provenance Gate"):
Voordat de AI iets belangrijks mag doen (zoals een e-mail sturen, een bestand wijzigen of een planning instellen), moet het door een veiligheidshek.

Controleer de kassabonnen: De poort kijkt naar de "bonnen" van alles wat de AI gebruikt om die beslissing te nemen.
De regel: Als enig deel van het idee van een onbetrouwbare bron kwam (zoals de vreemde), slaat de poort toe.
De uitzondering: De enige manier om de poort te openen is als jij (de eigenaar) expliciet zegt: "Ja, ik vertrouw deze specifieke actie." Maar je moet dit vers doen voor die specifieke actie, niet slechts een keer voor een algemeen idee.

4. Wat ze daadwerkelijk hebben gedaan

De auteurs hebben niet alleen een theorie geschreven; ze hebben een prototype gebouwd om te bewijzen dat het werkt.

De test: Ze namen een echte, open-source AI-assistent (genaamd OpenClaw) en simuleerden de "Sleeper Channel"-aanval. Ze lieten zien dat zonder hun nieuwe poort, de AI graag gegevens naar de aanvaler stuurde.
De oplossing: Ze installeerden hun "Provenance Gate" (die ze D2 noemen).
Het resultaat: Toen de AI probeerde de val van de aanvaler in te stellen, controleerde de poort de bonnen, zag het label "Vreemde" en blokkeerde de actie. De aanval mislukte.

5. De kernboodschap

Het artikel betoogt dat naarmate AI-agenten krachtiger worden en "altijd-aan" blijven, we ze niet zomaar kunnen vertrouwen om te onthouden wat veilig is. We hebben een systeem nodig dat de geschiedenis van elk idee dat de AI heeft, bijhoudt.

Oude manier: "Heeft de eigenaar dit gevraagd?" (Ja -> Doe het).
Nieuwe manier: "Heeft de eigenaar dit gevraagd, EN heeft de eigenaar de bron van het idee erachter goedgekeurd?" (Als het idee van een vreemde kwam -> STOP).

De auteurs noemen dit een "tiered defense" (verdediging in lagen), wat betekent dat ze een basisversie en een sterkere versie hebben, maar de kernidee is simpel: Laat de AI niet handelen op ideeën die het van vreemden heeft opgepikt zonder een frisse, expliciete "OK" van jou.

Technische Samenvatting: Slaperkanalen en Bewijslastpoorten

Probleemdefinitie: Slaperkanalen

Het artikel identificeert een nieuwe bedreigingsklasse in "altijd-aan" autonome AI-agenten (bijv. OpenClaw, Hermes Agent) die Slaperkanalen worden genoemd. In tegenstelling tot traditionele prompt-injectie, die doorgaans binnen één wisselwerking of sessie plaatsvindt, ontkoppelt een aanval via een slaperkanaal de ontvangst ( $T_0$ ) van het effect ( $T_1$ ) over tijd, opslagsubstraten en communicatieoppervlakken.

In dit scenario wordt een onbetrouwbare invoer (bijv. uit een groepschat of e-mail) opgenomen door de agent en blijft bestaan als een geheugennotitie, een door de agent zelf geschreven vaardigheid, een geplande taak of een patch voor het bestandssysteem. Dit artefact overleeft binnen de autoriteitsgrens van de agent totdat een onschuldig trigger (zoals een latere verzoek van de eigenaar of een autonome lus) het ophaalt en uitvoert. De aanval wordt afgevuurd via een ander oppervlak dan de ontvangst, vaak gebruikmakend van de "verwarde adjunct" (confused deputy)-conditie waarbij de agent een opdracht uitvoert namens de eigenaar, zonder zich bewust te zijn dat de parameters van de opdracht afkomstig zijn van een onbetrouwbare bron.

De auteurs definiëren de klasse aan de hand van twee assen:

Persistentie-substraat: Waar de kwaadaardige instructie overleeft (Geheugen, Zelfgeschreven Vaardigheid, Bestandssysteem, Geplande/Externe Trigger).
Afscheiding van Afvuren: De mate van ontkoppeling tussen ontvangst en uitvoering (Zelfde-sessie, Kruiskanaal, Kruisactor, Kruis-uitvoeringscontext).

Het artikel betoogt dat bestaande literatuur deze capaciteiten geïsoleerd behandelt (bijv. injectie in één wisselwerking of vergiftiging van het geheugen) en faalt in het adresseren van de verenigde bedreiging van multi-substraat-persistentie gecombineerd met vertraagde, kruisoppervlakte-afvuring.

Methodologie en Bedreigingsmodel

De auteurs hanteren een bedreigingsmodel waarbij de aanvaller "onbetrouwbaar-maar-toegelaten" is, wat betekent dat hun inhoud de agent bereikt via ingeschakelde maar laag-vertrouwde kanalen (groepschats, e-mails, opgehaalde URL's). De verdediger is de eigenaar van de agent. De analyse is verankerd bij een specifieke vastgepinde commit van de OpenClaw-runtime (commit 3120401f...1829b1b6), waarbij alle claims zijn geverifieerd tegen de meegeleverde broncode.

Het artikel presenteert een taxonomie (Tabel I) die persistentie-substraten ( $M_1$ – $M_5$ ) in kaart brengt tegen afscheiding van afvuren ( $C_0$ – $C_4$ ). Het benadrukt vier illustratieve scenario's die eerdere werken onvoldoende specificeren:

A4 (Loopend Voorbeeld): Een "Cron via verwarde adjunct"-aanval ( $M_5 \times C_4$ ). Een aanvaller plakt een kwaadaardige webhook-URL in een e-mail. De agent vat dit samen in het geheugen. Enkele dagen later vraagt de eigenaar de agent om "die dagelijkse gezondheidscontrole in te stellen". De agent haalt de notitie op, synthetiseert een cron-job met de URL van de aanvaller en voert deze uit. De persistentie is het cron-bijdrage; het afvuren vindt plaats in de systeem-cron-daemon, buiten het agent-proces.
A2: Een skill-trojaans paard via groepschat ( $M_3 \times C_2$ ).
A3: Kruiskanaal-exfiltratie via geheugen ( $M_2 \times C_2$ ).
A5: Dotfile-patching ( $M_4 \times C_4$ ).

Belangrijkste Bijdragen: De Provenance-verdediging (D2)

Het artikel stelt een gelaagde verdedigingsstrategie voor, waarbij D2 de kernbijdrage is. D2 verlegt de handhavingsgrens buiten de model-lus, leunend op provenance-tracking en attestatie van actie-instanties.

Kernmechanismen

Artefact-labeling en Propagatie: De runtime onderhoudt een provenance-status ( $\Pi$ ) voor elk artefact (geheugen, vaardigheden, bestanden, tool-aanroepen). Labels ( $\tau$ ) registreren de bron (Kanaal, Prinsipeel, Apparaat). Onbetrouwbare invoer vergroot strikt de provenance-set.
Digest van Actie-instantie: Elke consequente actie $\alpha$ wordt gehasht naar een canonieke digest $\delta(\alpha)$ met behulp van een botsingsresistente hash (SHA-256) over de genormaliseerde actie-bytes (inclusief argumenten en doel). Dit verslaat "parafraase-wasservice" waarbij een model de instructie van een aanvaller herschrijft om de oorsprong te verbergen.
Mediatie-haken: De verdediging vereist volledige mediatie via tien runtime-haken (H1–H10).
- Update-haken (H1–H5): Populeren labels en propageren provenance tijdens ontvangst en creatie.
- Poort-haken (H6–H10): Beslispunten voordat er effecten worden veroorzaakt (bijv. shell-uitvoering, bestandsschrijvingen, planning).
Eenmalige Eigenaar-attestatie: Voor acties met onbetrouwbare provenance vereist de poort een toekenning $g$ van een vertrouwd prinsipeel. Deze toekenning moet overeenkomen met de actie-digest $\delta(\alpha)$ , een uniek nonce bevatten (om replay te voorkomen) en aankomen via een hardware-geattesteerd begeleidingskanaal ( $\Sigma$ ) dat het model niet kan uitzenden.

Geluidheidstheorema

De auteurs leveren een geluidheidstheorema voor D2, uitgaande van zeven runtime-invarianten (Mediatie, Label, Causaal, Kanaal, GrantAuth, Nonce, Hash). Het theorema stelt dat een dispatch alleen is toegestaan als:

Alle bijdragende artefacten in de causale set vertrouwde provenance hebben ( $\Pi_\alpha \subseteq T$ ), OF
Er een geldige, verse, door de eigenaar vertrouwde attestatie bestaat voor de exacte actie-instantie.

Dit ontwerp zorgt ervoor dat zelfs als het model wordt bedrogen om een kwaadaardig commando te genereren, de poort dit zal weigeren tenzij de eigenaar expliciet attestatie geeft voor die specifieke actie-instantie via een veilig kanaal.

Resultaten en Evaluatie

Het artikel claimt geen ingezet productiesysteem, maar biedt een bron-geankerd haalbaarheidsargument en een uitvoerbare referentie-implementatie.

Empirische Proef (A4): In een "rookproef" van 20 single-shot-proeven kreeg een geavanceerd redenerend model de OpenClaw-beveiligingswaarschuwing en de kwaadaardige context. 19/20 modellen gaven een geldige cron.add-tool-aanroep uit die wees naar de URL van de aanvaller, wat aantoont dat contextuele waarschuwingen (D1) onvoldoende zijn om de aanval te voorkomen.
Referentie-implementatie: Een begeleidend artefact op github.com/maloyan/sleeper-channels bevat:
- Een TypeScript-implementatie van de D2-poortbeslissingsfunctie.
- Een statische audit-suite (13 gevallen) die verifieert dat de aangehaalde bronregels in OpenClaw bestaan en overeenkomen met het bedreigingsmodel.
- Een runtime-adapter die haken H1, H2, H3, H6 en H9 implementeert rond het cron-pad.
- Een test-suite van 42 gevallen die beslissingsregels, multi-invoer-wasservice en grant-replay bestrijkt.
Verificatie: De runtime-adapter heeft succesvol aangetoond dat de A4-aanval-aanroep wordt geweigerd vanwege onbetrouwbare provenance, terwijl onschuldige cron-taken die alleen door de eigenaar zijn ingesteld worden toegelaten.

Betekenis en Claims

Het artikel positioneert zichzelf als een positie- en ontwerpartikel dat de bedreigingsklasse van slaperkanalen oplost en een formele specificatie voor verdediging biedt.

Nieuwheid: Het is het eerste werk dat de combinatie van multi-substraat-persistentie en vertraagde, kruisoppervlakte-afvuring behandelt als een verenigde bedreigingsklasse in OS-live agenten.
Plaatsing van Verdediging: Het betoogt dat provenance-signalen buiten de model-lus moeten worden afgedwongen. Leunen op het model om onbetrouwbare invoer te weigeren (D1) is broos tegen adaptieve aanvallen.
Formalisme: Het introduceert een geluidheidstheorema en een canonieke digest van actie-instanties om parafraase-wasservice en replay-aanvallen te verslaan, en adresseert gaten in eerdere gemeenschapsvoorstellen (bijv. upstream-issue [10]) die ontbraken aan empirische onderbouwing en formele handhavingspecificaties.
Bescheidenheid: De auteurs stellen expliciet dat empirische aanvalsuccespercentages, volledige implementatie-effectiviteit en afwegingen tussen nut en kosten worden uitgesteld naar een vooraf geregistreerde vervolgstudie. Het huidige werk vestigt de taxonomie, de formele verdediging en de haalbaarheid van de aanval en verdediging op een specifieke runtime-commit.