ROPE: Routed Origin Policy Enforcement

Codice sorgente del nostro articolo:

ROPE: Routed Origin Policy Enforcement against Indirect Prompt Injection di Xinhang Ma, Chaowei Xiao, William Yeoh, Ning Zhang, Yevgeniy Vorobeychik

Abstract

L'iniezione di prompt indiretta (IPI) inserisce istruzioni nel contenuto che un agente LLM che usa strumenti legge, indirizzando l'agente verso chiamate a strumenti dannose. Le difese più forti sono a livello di sistema e sfruttano tecniche come lo screening condizionale degli strumenti basato sul task per impedire l'esecuzione di strumenti dannosi e il controllo del flusso informativo per evitare l'esecuzione di strumenti con parametri non attendibili. Tuttavia, man mano che gli agenti diventano più capaci, gli utenti delegano sempre più all'automazione. Di conseguenza, le sequenze di esecuzione degli strumenti e i valori dei parametri sono sempre più determinati a runtime e non possono essere filtrati in modo affidabile usando informazioni contenute esclusivamente nella query dell'utente senza una significativa perdita di utilità. Presentiamo ROPE (Routed Origin Policy Enforcement), che si fonda su una nozione strutturale di fiducia: un valore può raggiungere uno strumento che modifica lo stato solo se risale in modo infalsificabile all'utente, a una fonte esplicitamente nominata dall'utente o ai record autorevoli dell'utente stesso. L'applicazione è quindi un controllo deterministico dell'origine su un insieme sottoposto ad audit di parametri sensibili degli strumenti, e l'unico affidamento su un modello linguistico coinvolge esclusivamente la richiesta attendibile dell'utente, fuori dalla portata dell'attaccante. Il nostro approccio ammette due garanzie dimostrabili: 1) a ogni passo di una traiettoria, nessun valore la cui unica origine sia contenuto scrivibile dall'attaccante raggiunge un parametro protetto dall'origine, e 2) nessuna riformulazione di un'iniezione modifica una decisione di ammissione. Attraverso un'ampia valutazione sperimentale, mostriamo che su quattro modelli agente in suite di agenti open-ended, ROPE mantiene il tasso di successo dell'attacco all'1,6–2,6% conservando l'82–100% dell'utilità pulita non difesa, superando significativamente le difese a livello di sistema allo stato dell'arte in termini di utilità e raggiungendo una sicurezza comparabile o migliore su workflow dinamici complessi. Inoltre, mostriamo che ottimizzare l'iniezione contro ROPE è in gran parte inefficace, mentre gli attacchi a lungo orizzonte che sconfiggono le precedenti difese a livello di sistema ottengono un tasso di successo pari a zero nel nostro caso.

Struttura del repository

Configurazione

Python 3.12 con openai, pydantic, jsonschema, pyyaml (e google-genai per il percorso Gemini nativo). Dalla radice del repository:

export PYTHONPATH=$PWD/autodojo/src:$PWD/src

Riprodurre i numeri riportati dai log inclusi (nessun accesso API necessario)

cd runs
python aggregate.py         # CU / UA / ASR per suite + totali (entrambi i benchmark)
python adaptive_rope.py     # statico vs adattivo, CU/UA/ASR (attacco AutoDojo, entrambi i benchmark)
python longhorizon_rope.py  # lungo orizzonte (AgentLAB Task-Injection)
python ablation.py          # ablazione della policy: sempre-completamente-specificato / sempre-azione-aperta
python router.py            # router più economici, con e senza clamp di applicazione
python failures.py          # censimento dei fallimenti: ogni successo di attacco residuo + fallimenti di task puliti
python buckets.py           # tabelle per categoria (bucket di sotto-specifica)
python router_deviation.py  # conteggi per-router di allentamento/irrigidimento rispetto al floor sottoposto ad audit

Ogni script ricalcola la propria tabella dai log e la stampa; nessuno contiene valori attesi. buckets.py e router_deviation.py richiedono PYTHONPATH impostato come sopra (leggono le definizioni delle suite e gli ambiti memorizzati in cache); gli altri leggono solo i log JSON inclusi.

runs/<model>/<suite>/user_task_*/, runs/ablation/<policy>/<suite>/user_task_*/ e runs/router/<router>[-clamp]/<suite>/user_task_*/ contengono ciascuno un JSON per cella valutata: none/ (pulito), important_instructions/ (attacco statico), autodojo/ (attacco adattivo) e agentlab_longhorizon/ (attacco a fasi a lungo orizzonte).

Correzioni di punteggio. Tre oracoli di benchmark non sono validi per le difese che bloccano l'esecuzione. runs/corrections.py gestisce le tre riscorature basate sugli effetti — slack IT5, dailylife IT7, github IT1 — e gli aggregatori le applicano; il docstring di ciascun modulo documenta l'artefatto e la correzione. CU e UA non vengono mai toccati.

Eseguire la difesa

# configurazione del risultato principale (router opus in cache, corrispondenza rigorosa, senza clamp):
python -m rope.run_eval --suite github --attack important_instructions
python -m rope.run_eval --suite github --attack none            # utilità pulita
python -m rope.run_eval --suite github --defense passthrough    # baseline senza difesa

# router più economici dallo studio sui router, opzionalmente con clamp al floor sottoposto ad audit:
python -m rope.run_eval --suite github --router gemini-3-flash --clamp

# router live (ricalcola l'ambito a runtime con qualsiasi modello compatibile OpenAI):
python -m rope.run_eval --suite github --router live --router-model openai/gpt-4o-mini --clamp

# attacco adattivo: replay delle iniezioni ottimizzate AutoDojo in cache
AUTODOJO_CACHE=$PWD/autodojo/variant_generation/variants/github/openai/gpt-4o-mini/routed/injections.json \
  python -m rope.run_eval --suite github --attack autodojo

# attacco a lungo orizzonte: replay delle tracce in cache di AgentLAB (vedi agentlab/README.md)
python agentlab/run_eval.py --suite banking --user-task user_task_0 --injection-task injection_task_0

Variabili d'ambiente: OPENROUTER_API_KEY (modello agente e router live; tutte le esecuzioni riportate chiamano i modelli agente tramite OpenRouter), ROPE_AGENT_MODEL (default openai/gpt-4o-mini), ROPE_PIPELINE_TAG per etichettare i log di esecuzione (deve contenere un nome di modello AgentDojo affinché i template di attacco si risolvano).

I router in cache rendono la difesa completamente deterministica e senza API sul lato routing: opus copre tutte e sei le suite; gemini-3-flash e gpt-oss-20b coprono le suite AgentDyn (l'ambito dello studio sui router). Per valutare il proprio router, mettilo in cache una volta e riutilizzalo come uno integrato:

python -m rope.cache_router --router my-router --router-model <llm-id> --suite github
python -m rope.run_eval     --router my-router --suite github --attack important_instructions

Ringraziamenti

Questo repository integra o si basa su: AgentDojo e AgentDyn (suite di benchmark), AutoDojo (attacco adattivo) e AgentLAB (benchmark a lungo orizzonte e tracce di attacco Task-Injection). Vedi i rispettivi articoli per i dettagli.

Riferimenti

Se trovi utile questo lavoro, apprezziamo una citazione:

@article{rope,
  title={ROPE: Routed Origin Policy Enforcement against Indirect Prompt Injection},
  author={Ma, Xinhang and Xiao, Chaowei and Yeoh, William and Zhang, Ning and Vorobeychik, Yevgeniy},
  journal={arXiv preprint arXiv:2608.27496},
  year={2026}
}