Containment structural pentru pipeline-uri LLM multi-agent
Un agent Validator compromis lasă să treacă 100% din aprobările malițioase. Execuția rămâne curată oricum.
Containment structural pentru pipeline-uri LLM multi-agent
Un agent Validator compromis lasă să treacă 100% din aprobările malițioase. Execuția rămâne curată oricum. Acesta e rezultatul contra-intuitiv dintr-un paper arxiv din septembrie 2026 care studiază propagarea atacurilor într-un pipeline LangGraph cu patru agenți (2609.17648) — și redefinește modul în care echipele de engineering ar trebui să gândească siguranța agenților.
Setup-ul e familiar oricui livrează agentic RAG: Supervisor planifică, Researcher extrage, Validator judecă, Executor acționează. Autorii weaponizează doi vectori — otrăvirea memoriei partajate și indirect prompt injection prin aprobări falsificate în documentele extrase. Apoi măsoară ce ajunge efectiv la tool-uri.
De ce straturile de judgment eșuează singure
Lucrarea introduce Judgment Bypass Rate (JBR), fracția din inputurile adversariale pe care Validator-ul le aprobă eronat. Sub indirect prompt injection, JBR urcă la 100%: fiecare tag „APPROVED” falsificat dintr-un chunk extras convinge Validator-ul. Asta oglindește pattern-ul documentat în ENISA 2024 Threat Landscape for AI, unde guardrail-urile bazate pe LLM se degradează abrupt odată ce atacatorul controlează contextul din amonte.
Unde lucrarea contrazice ortodoxia este Unsafe Action Rate. Cu autorizare structurală — tokeni semnați legați de task plus un policy oracle independent între Validator și Executor — Unsafe Action Rate scade la 0% chiar și la JBR = 100%. Executor-ul refuză acțiunile pe care oracle-ul nu le-a semnat pentru acel task ID specific, așa că un Validator deturnat produce zero daune downstream.
executor_policy:
require_signed_token: true
token_scope: task_id
oracle_endpoint: https://policy.internal/verify
reject_on_mismatch: true
audit_log: /var/log/agents/exec_deny.log
E același principiu pe care NIST îl numește capability confinement în profilul său AI 600-1 pentru AI generativ: componentele din aval nu trebuie să aibă încredere în judgmentul componentelor din amonte — trebuie să verifice o dovadă criptografică legată de task-ul curent.
Observer-ul și ce aduce
A doua contribuție e stratul Observer, un monitor pasiv care scorează trace-urile conversației pentru semnături de hijack. Deployment-ul naiv produce un false-positive rate de 49% — inutilizabil pentru on-call. Calibrat pe telemetria pipeline-ului, același Observer scade la 7% FPR păstrând detecția intactă.
Citite împreună, cele două rezultate spun o poveste clară de engineering: judgment-ul e o țintă moale, autorizarea e una dură. Echipele care investesc efort în prompt-uri de Validator mai puternice patch-uiesc stratul greșit. Pilonul AEGIS a susținut asta încă din primele noastre lucrări despre riscul topologiei agenților — proprietatea de siguranță stă în cablaj, nu în weights.
Unde se poziționează CAI Technology în privința asta
Construim cu presupunerea că orice agent va fi compromis la un moment dat, și proiectăm granița de execuție în consecință. Fiecare acțiune pe care stratul nostru de orchestrare IRIS o emite poartă un token legat de task, verificat de un oracle out-of-band înainte de orice apel de tool. Observer-ul rulează în shadow mode două săptămâni per deployment cât calibrăm pe trafic real — un FPR de 49% ne-ar arde SOC-ul într-o zi. Obligațiile de acuratețe și securitate cibernetică din Articolul 15 al EU AI Act (EUR-Lex) vor face asta table stakes până în 2027; echipele care livrează workload-uri agentice ar trebui să se miște acum.
Vrei să vezi pattern-ul token-and-oracle aplicat pe pipeline-ul tău? Începe cu briefing-ul nostru de engineering AEGIS.