Agenții AI moșteniți: de ce guvernanța nu vede calea prin Agentforce

Agenții AI nu mai sunt doar instrumente pe care o companie le alege și le cumpără. Tot mai des, apar în interiorul platformelor pe care firma le folosește deja — CRM, ITSM, suite de colaborare — activați de o echipă de business, construiți într-o după-amiază și rulând cu permisiunile cuiva. Un exemplu documentat recent în Salesforce Agentforce arată de ce contează: o persoană din afară poate influența un agent intern folosind doar funcții standard, documentate.

Ce s-a întâmplat

Agentforce reacționează de obicei la evenimente printr-un Flow: un caz este creat sau actualizat, iar Flow-ul transmite datele acelui caz în promptul agentului. Separat, Email-to-Case și Web-to-Case transformă mesajele primite de la clienți în cazuri — baza preluării cererilor de suport la companii aeriene, hoteluri și multe alte firme de servicii.

Puse împreună, cele două creează o linie directă de la internetul public la agent:

email public → caz → prompt agent → acțiune agent → comentariu pe caz → răspuns trimis în exterior

Un expeditor neautentificat poate plasa text în fața instrucțiunilor agentului, iar răspunsul agentului iese pe același canal. Nimic nu este configurat greșit în sensul obișnuit; fiecare componentă funcționează așa cum a fost proiectată. Problema a fost documentată de cercetători în august 2026 și este un caz clasic de injecție indirectă de prompt: punctul slab este modul în care aplicația este conectată în jurul modelului, nu modelul în sine.

De ce contează

Dacă acest lanț este doar o neplăcere pentru coada de suport sau o expunere de date depinde de detalii pe care puține echipe de securitate le urmăresc: ce canale de preluare sunt active, ce declanșatoare rulează, ce obiecte pot accesa utilizatorii guest, ce date transmite automatizarea și ce versiune de model apelează de fapt agentul. O evaluare a furnizorului făcută o singură dată, la achiziție, nu vede nimic din toate acestea — agentul nici nu exista atunci. Nici un filtru de prompt nu ajută, pentru că nu știe că un anumit input a venit din emailul unui străin.

Problema crește odată cu adopția. Echipele de business construiesc agenți la fel de ușor ca o prezentare, iar fiecare moștenește accesul creatorului. Agenții creează la rândul lor alți agenți — asistenți de cod care lansează ajutoare, orchestratoare care generează sub-agenți — fiecare cu propriile conexiuni și fără o evaluare proprie. O guvernanță care presupune că un om a cerut fiecare agent este deja depășită. OWASP Agentic Skills Top 10 descrie exact acest lucru în categoria „No Governance": abilitățile care rulează în platforme terțe sunt în mare parte invizibile pentru scannerele externe.

Miza de reglementare este reală. Conform EU AI Act, amenzile ajung la 35 de milioane de euro sau 7% din cifra de afaceri globală pentru practicile interzise și la 15 milioane de euro sau 3% pentru alte încălcări. Istoria GDPR (British Airways, Marriott) arată că autoritățile sancționează organizațiile care nu pot demonstra controlul, nu doar pe cele cu politici imperfecte.

Ce e de făcut

• Inventariați agenții pe care îi aveți cu adevărat. Priviți dincolo de lista IT: configurări de aplicații, permisiuni OAuth, telemetrie de pe endpoint-uri și browser. Numărul real e probabil de câteva ori mai mare.
• Corelați input-urile nesigure cu declanșatoarele agenților. În Salesforce, listați fiecare canal Email-to-Case / Web-to-Case și fiecare Flow care trimite date din cazuri într-un prompt Agentforce. Tratați acele date ca ostile.
• Fiecare agent are nevoie de un proprietar numit și de un ciclu de viață. Alegeți unul la întâmplare — dacă nimeni nu și-l asumă într-o zi, proprietatea nu există.
• Aplicați principiul privilegiului minim, pe baza nevoii reale. Restricționați accesul utilizatorilor guest la obiecte, limitați acțiunile pe care un agent le poate face când e declanșat din exterior și cereți aprobare umană pentru răspunsurile care conțin date din înregistrări.
• Evaluați riscul în context. Aceeași slăbiciune pe un agent de test izolat și pe unul expus clienților nu are aceeași gravitate.
• Păstrați dovezi, nu doar politici. Inventarul, proprietarii, configurările și istoricul evaluărilor sunt ce veți avea nevoie în fața unei autorități.

Evaluările pe hârtie și scannerele din exterior rareori prind astfel de lanțuri, pentru că riscul stă în modul în care funcțiile sunt legate între ele. Este genul de traseu de logică de business pe care echipa noastră de testare de penetrare îl parcurge — urmărind input-ul nesigur dintr-un formular public sau o căsuță de email până la ce poate citi și trimite înapoi un agent intern.

Sursa: The Hacker News — „From Email-to-Case to the Boardroom: How Inherited Agents Break Governance Built for Software" (articol sponsorizat de Reco, 19 oct. 2026). Rezumat și reformulat de 4Tify.