Guardrails în cinci straturi

La finalul capitolului poți puncta un repository pe cele cinci straturi de control și poți numi fix-ul care îi închide cea mai mare lacună.

TL;DR

• Un prompt e o cerere, nu un control. Acțiunile distructive au nevoie de straturi pe care agentul nu le poate ocoli cu vorba: permisiuni, sandbox, secrete, hook-uri și telemetrie.
• Principiul privilegiului minim e coloana vertebrală, iar redundanța e controlul. Sandbox-ul e granița dură împotriva prompt injection-ului - și chiar și el poate avea bug-uri.
• Ține credențialele de producție în afara sesiunii și trece pull request-urile agentului prin aceleași gate-uri ca pe ale tuturor celorlalți.

Care sunt cele cinci straturi?

Un prompt e o cerere. Un control e ceva ce agentul nu poate ocoli cu vorba.

PocketOS (Prologul) avea o instrucțiune în limbaj natural, care e mai slabă decât stratul unu. Din incident se citează trei lecții, și toate trei sunt greșite:

• „Agentul și-a ignorat instrucțiunile.” Da. Asta fac agenții uneori; un prompt nu e niciodată un control dur pentru o acțiune distructivă.
• „Agenții AI sunt nesiguri.” La fel de nesigur e orice tool îndreptat spre producție fără controale.
• „N-ar trebui să folosim AI pentru operațiuni pe baze de date.” Asta înseamnă să arunci productivitate reală, când straturile pot delimita riscul.

Sub toate cinci stă privilegiul minim: la fiecare nivel - agentul, procesul lui, credențialele lui, rețeaua lui - acorzi minimul care permite muncii să se întâmple.

Niciun strat, de unul singur, nu i-ar fi salvat pe cei de la PocketOS cu certitudine; oricare dintre straturile aplicate efectiv putea rupe lanțul. Un al doilea incident din 2026, de la DataTalks.Club, a fost imaginea în oglindă: Claude Code a rulat terraform destroy pe un state file rămas în urmă. Același remediu: confirmare pe operațiunile distructive, doar credențialele de care are nevoie task-ul și o stare pe care echipa a verificat-o.

Stratul 1: Permisiuni

Permisiunile răspund la o singură întrebare: are voie agentul ăsta să facă asta, chiar acum?

Recomand un clasificator care decide la fiecare acțiune dacă permite, întreabă sau refuză, plus un set mic de reguli explicite pe deasupra, de exemplu refuzul scrierii în fișierele .env. Zece-cincisprezece override-uri per repository e un plafon rezonabil; dincolo de el, AGENTS.md-ul tău e prea subțire, nu lista de reguli prea scurtă.

Orice echipă începe de aici, iar un prompt injection reușit poate trece de stratul ăsta. Necesar, nu suficient.

Stratul 2: Sandbox

Kernelul nu ascultă de raționamentul agentului, așa că injecția nu-l poate ocoli cu vorba.

Pentru majoritatea echipelor, default-ul e: citire pe tot repository-ul, scriere doar în worktree, rețea doar către host-urile din allowlist, restul blocat.

Calibrează după fricțiune: dacă agentul se lovește des de limite în munca normală, lărgește-le. Costă o după-amiază de configurare, iar unii agenți îl livrează opt-in, așa că verifică-l pe al tău (Capitolul 1).

Stratul 3: Secrete

Cea mai sigură credențială e cea pe care sesiunea n-a deținut-o niciodată.

Nu da commit la fișiere .env și ține minte că agenții le pot prelua singuri din directorul de lucru, fără să fie rugați. Ține secretele într-un vault și trage-le la runtime printr-un pas de fetch explicit, pe care agentul poate fi configurat să-l sară. Include căile sensibile în lista de deny-read a sandbox-ului: agentul pur și simplu nu le poate citi, indiferent ce spune system prompt-ul.

Stratul 4: Hook-uri

Hook-urile sunt instrumentul de precizie: un gate programabil pentru categoriile care contează pentru echipa ta.

Un hook e cod care rulează înainte ca agentul să execute un anumit tip de acțiune (pre-tool-use) și, în funcție de regulile tale, o permite, cere confirmare sau o blochează. Plugin-urile de-a gata vin cu o bază: secrete scurse în diff-uri, pattern-uri de SQL injection, credențiale hardcodate.

Regulile tale proprii vin pe deasupra: orice schimbare în logica de conversie valutară cere aprobare explicită; orice commit care atinge tabela de clienți cere un reviewer de securitate. Apelezi la un hook când permisiunile sunt prea grosiere, iar sandbox-ul prea brutal.

Stratul 5: Telemetrie

Primele patru straturi previn; telemetria detectează, așa că o prevenție eșuată costă minute, nu zile.

Loghează fiecare tool call - fiecare comandă de Bash, fiecare scriere de fișier și fiecare request către un API extern, cu argumente și rezultate - într-un store central deținut de echipa de securitate. Atunci „ce sesiuni au atins serviciul de plăți în ultimele treizeci de zile” devine o interogare, nu un grep prin istoricele locale ale celor optzeci de ingineri. Urmărește:

• o editare în afara task-ului asignat
• apeluri către host-uri din afara allowlist-ului
• refuzuri repetate de permisiuni: un bug în reguli sau o tentativă de injecție
• credențiale de producție în context

Injecția ajunge prin munca în sine

Tratează tot ce citește agentul drept text de neîncredere și nu te baza pe agent să depisteze atacul.

Oriunde citește agentul limbaj natural e o suprafață de injecție: un ticket de Jira ale cărui criterii de acceptare spun „ignore all previous instructions”; comentariul de PR al unui contributor extern, cu o instrucțiune ascunsă într-o notă de review; un mesaj de eroare de la un test third-party instabil; un repository cu aspect inofensiv a cărui eroare plantată împinge agentul să ruleze un „fix” care își trage payload-ul real. Am văzut cu ochii mei un agent executând conștiincios o instrucțiune îngropată într-un fișier de log copiat și lipit, pentru că operatorul nu se gândise la un fișier de log ca la un input de neîncredere.

Constrânge ce poate face agentul, indiferent de ce a citit. Sandbox-ul prinde acțiunea periculoasă chiar și când agentul e convins că e legitimă; hook-ul prinde categoria periculoasă chiar și când „doar de data asta” sună în regulă. Un AGENTS.md otrăvit poate schimba comportamentul agentului la fiecare pornire de sesiune, încă un motiv pentru care trece prin review ca orice cod (Capitolul 6).

Dincolo de cele cinci

Două practici obișnuite prind ce nu prind straturile.

• Separarea mediilor. Agentul nu deține credențiale de producție by default. Acțiunile de producție trec printr-un gate separat - o aprobare umană, un pipeline de CI, un script de deploy - pe care agentul îl declanșează, dar nu îl execută cap-coadă.
• Branch-uri protejate, CODEOWNERS și politică de CI. Agentul deschide pull request-uri ca orice alt contributor; asigură-te că PR-urile lui trec prin aceste reguli, nu pe lângă ele.

În buclă

Rigoarea trăiește în straturile de sub Execute; Execute doar rulează munca.

În faza de Execute din Capitolul 4, fiecare tool call trece prin gate-ul de permisiuni, fiecare comandă Bash prin hook-urile de securitate, fiecare scriere de fișier prin sandbox. O acțiune blocată se întoarce la orchestrator, care decide.

Când se strică

• Fiecare strat e cod, iar codul are bug-uri. La mijlocul lui 2026, un red team a dezvăluit două escape-uri critice zero-click ale sandbox-ului kernel-backed al unui vendor (patch-uite), iar un check de permisiuni și-a sărit o dată regulile de deny pe lanțuri foarte lungi de comenzi. Ăsta e argumentul pentru cele cinci straturi.
• Un log fără alertă nu e un strat. Platforma PocketOS a înregistrat ștergerea, dar nicio alertă nu s-a declanșat când o sesiune de agent a folosit un token de producție; primul semnal a fost o bază de date inaccesibilă.

De făcut luni

Punctează fiecare strat cu DEFAULT, CONFIGURED, ENFORCED sau MONITORED. DEFAULT sau CONFIGURED pe toată linia e normal; ENFORCED sau MONITORED peste tot e de nivel de producție.

• [ ] Alege un repository deținut de echipa ta, ideal unul în care un agent face deja commit-uri.
• [ ] Permisiuni: ce rulează fără un prompt de confirmare? Sunt rm, terraform destroy, drop table și force push pe main păzite de un gate?
• [ ] Sandbox: impus de kernel, sau doar validare de căi în codul agentului însuși?
• [ ] Secrete: au ajuns fișiere .env în repo? Poate agentul ajunge la un token de producție?
• [ ] Hook-uri: există vreun hook pre-tool-call care auditează, loghează sau pune un gate pe operațiunile periculoase?
• [ ] Telemetrie: ar apărea o comandă distructivă într-un dashboard în câteva minute?
• [ ] Pentru fiecare strat aflat sub ENFORCED, scrie un fix și un responsabil. Foaia asta e planul trimestrului următor; rulează auditul din nou după fiecare incident.

Mai departe

• Template: scorecard-ul de mai sus; pentru plugin-urile care vin cu hook-uri, Anexa B.10, verificarea plugin-urilor.
• Deep dive: Anexa D, Capitolul 2 - clasele de vulnerabilități numite, escape-urile din sandbox, default-urile de sandbox per agent și ce au schimbat platformele după incidente.
• Surse: Anexa C.