← Tornar a tots els articles
Reptes

El dia que el teu agent va tenir eines, el prompt injection va passar a ser un problema d'operacions

Per Marc Molas·17 de juliol del 2026·7 min de lectura

Un chatbot que enganyen perquè escrigui un poema sobre la teva competència és una captura de pantalla a les xarxes. Un agent que enganyen perquè enviï la teva base de dades de clients a un desconegut és una notificació de bretxa de seguretat. La diferència entre aquests dos incidents és una sola decisió d'arquitectura: has donat eines al model.

Vinc d'operacions enterprise, on vam passar anys construint mínim privilegi, controls de sortida i traces d'auditoria al voltant de cada compte de servei. El que veig ara, revisant desplegaments d'agents, és que aquests mateixos controls es perdonen sense discussió a la identitat més nova i menys predictible de la xarxa — perquè la demo de l'agent va funcionar, i ningú no va tornar a revisar el threat model entre la demo i producció. Ja hem escrit sobre què passa quan no hi ha ningú al teclat; aquest post va del radi d'explosió d'aquesta identitat quan se li connecten eines.

La indústria ja ha posat nom al patró, i ja tenim la prova que és real. Val la pena prendre's seriosament totes dues coses.

La lethal trifecta: dades privades, contingut no fiable, un canal de sortida

El juny de 2025, Simon Willison va posar nom al patró que converteix un agent en una màquina d'exfiltració — la lethal trifecta: accés a dades privades, exposició a contingut no fiable i capacitat de comunicar-se amb l'exterior. Dues de les tres són manejables. Les tres juntes volen dir que un sol document, correu o pàgina web enverinats pot ordenar al teu agent que reuneixi dades sensibles i les tregui fora — sense cap vulnerabilitat al teu codi, sense credencials compromeses, sense que cap usuari cliqui res.

La raó per la qual això és estructural i no un bug: un LLM no té cap frontera fiable entre instruccions i dades. Tot el que entra a la finestra de context és, per al model, instrucció en potència. Trenta anys de defenses contra injecció — consultes parametritzades, codificació de sortides — assumeixen que pots separar el canal d'ordres del canal de dades. Dins del context d'un transformer, no pots. OWASP situa el prompt injection com a risc #1 del seu LLM Top 10 des que la llista existeix, i la raó és aquesta.

Per això «hem endurit el system prompt» no és un control de seguretat. L'entrenament en jerarquia d'instruccions i els classificadors d'injecció abaixen la taxa d'èxit de l'atac; cap no la porta a zero. Davant d'un atacant que pot iterar sense cost contra el teu agent de cara al públic, un filtre que atura el 99% dels intents és un retard, no una defensa.

EchoLeak en va ser la prova: zero clics, CVSS 9,3

Si la trifecta sona teòrica, EchoLeak (CVE-2025-32711) va tancar la discussió. Divulgada per Aim Security el juny de 2025 i puntuada amb un 9,3, era una cadena d'exfiltració sense clics contra Microsoft 365 Copilot: un correu manipulat amb instruccions ocultes esperava a la safata d'entrada de la víctima fins que Copilot el processava durant l'ús normal, moment en què l'assistent recuperava altre contingut privat del context de l'usuari i el filtrava cap enfora a través de recursos autodescarregats. Sense interacció de l'usuari. Sense malware. La trifecta, muntada sobre un dels productes d'IA amb més enginyeria al darrere de tot el mercat — Copilot llegeix el teu correu (dades privades + contingut no fiable) i renderitza sortida enriquida (canal de sortida).

Microsoft ho va apedaçar al servidor i no es va confirmar cap explotació real. Però la lliçó no va d'un producte. Va que un fabricant a qui no falta pressupost de seguretat va desplegar la trifecta a centenars de milions de llocs de treball, i l'arranjament va exigir redissenyar fronteres de confiança, no retocar un prompt. Vam veure la mateixa classe d'atac des del costat del hiring quan una bio de LinkedIn amb una recepta de flam incrustada va travessar de punta a punta un pipeline automatitzat de selecció — un altre domini, mateixa causa arrel: text no fiable tractat com a instrucció fiable.

No pots filtrar l'atac, així que acotes la conseqüència

Quan acceptes que alguna injecció acabarà passant, la pregunta d'enginyeria canvia de «com detecto atacs» a «què pot fer l'agent quan estigui compromès». Aquesta pregunta la gent d'operacions ja l'ha respost abans — és el model assume-breach, aplicat a un component que està dissenyat per seguir les instruccions de la seva entrada. Els controls, en l'ordre en què jo els implementaria:

Mínim privilegi per eina, no per agent. L'agent en conjunt no rep cap scope; el rep cada crida a eina. La tool de retrieval porta un token de només lectura acotat a les col·leccions que aquest usuari pot veure. La de correu només envia a dominis interns. La de base de dades fa servir un rol que no pot tocar taules amb PII. Quan enganyin l'agent — i compta que passarà — les instruccions injectades hereten aquests límits, i «exfiltra la taula de clients» falla per permisos com qualsevol altra consulta no autoritzada.

Una porta humana a les accions irreversibles. Enviar correu extern, moure diners, esborrar registres, mergejar codi: aquestes crides retornen una aprovació pendent, no un resultat. El revisor veu una descripció d'una línia abans que s'executi. És avorrit — i converteix una bretxa en una petició denegada.

Execució en sandbox. Si l'agent escriu i executa codi, aquell codi corre en un contenidor d'un sol ús, sense credencials a l'entorn i amb una llista blanca de sortida. La llista blanca ataca directament la tercera pota de la trifecta: un agent que només arriba a les teves pròpies APIs no té enlloc on exfiltrar res. El filtratge de sortida és higiene de xarxa des del 2005, i neutralitza la capacitat més perillosa d'un agent compromès.

Marca l'input no fiable. Registra quines parts del context han vingut de fora — pàgines web, correu entrant, fitxers pujats — i restringeix quines crides a eines les poden seguir. Hi ha diverses propostes de recerca que ho formalitzen (patrons de doble LLM, separació de flux de control i de dades); fins i tot una versió tosca, com refusar crides d'alt privilegi en torns dominats per contingut web descarregat, talla les cadenes d'atac més fàcils.

El teu registre d'eines és una cadena de subministrament

El Model Context Protocol va fer componibles les eines — una bona notícia — i de passada va crear una classe de dependència nova que cap escàner no cobreix. Un servidor MCP és codi remot en què el teu agent confia — i el seu text de descripció entra a la teva finestra de context, cosa que vol dir que un servidor maliciós o compromès pot injectar instruccions a través de les mateixes metadades abans que es cridi cap eina.

Tracta el registre com un gestor de paquets, perquè és el que és: fixa versions dels servidors, revisa què ha canviat en actualitzar, i fes servir una llista blanca de servidors que hagis llegit en lloc d'instal·lar el que suggereixi el directori. L'ecosistema npm ja ens va ensenyar què passa quan la confiança en un registre es dona per feta. No hi ha cap motiu per reaprendre-ho amb components que sostenen credencials vives.

Què faria aquest trimestre si fos el teu CTO

  1. Fes el mapa de la teva trifecta. Per a cada agent: quines dades privades pot llegir, quin contingut no fiable arriba al seu context, quins canals de sortida existeixen. Qualsevol agent que reuneixi les tres és la teva prioritat — elimina la pota de la qual puguis prescindir.
  2. Rota les credencials de l'agent a tokens acotats per eina. Si el teu agent s'autentica amb res que s'assembli a una clau d'administrador, aquesta és la feina de la setmana que més importa.
  3. Posa una porta d'aprovació a cada eina irreversible. Enviaments externs, escriptures a producció, pagaments. Mesura quantes vegades denega la porta — aquest número són els incidents que hauries tingut si no existís.
  4. Afegeix una llista blanca de sortida a qualsevol entorn on corri codi generat per l'agent.
  5. Audita els teus servidors MCP i les descripcions de les tools com a dependències de tercers: fixades, revisades, en llista blanca.

L'excepció honesta: la majoria de desplegaments d'agents no s'enfrontarà mai a un atacant real, i una eina interna sense contingut extern al context pot funcionar amb controls més lleugers — ajustar el control a l'exposició és la feina, no la paranoia màxima a tot arreu. Però «ja hi afegirem seguretat quan importi» té un mode de fallada, i EchoLeak mostra quin aspecte té: severitat 9,3 i zero clics.

El model seguirà instruccions que no hauria de seguir. Això no és un defecte que s'apedaça; és la hipòtesi de treball al voltant de la qual es fa enginyeria — igual que fem enginyeria al voltant del fet que els humans cliquen enllaços de phishing. Els agents no necessiten filtres més llestos. Necessiten els controls avorrits i provats sota els quals ja opera qualsevol altre sistema amb entrades no fiables.


Si estàs posant agents en producció i vols que neixin dins d'aquestes fronteres des del primer dia, això és el que fan els nostres AI Operators.

Preparat per construir el teu equip d'enginyeria?

Parla amb un partner tècnic i desplega desenvolupadors validats per CTOs en 72 hores.