Quan els agents d’IA ixen del laboratori: els incidents reals que ha deixat el 2026

Un agent d’IA rep una tasca de ciberseguretat dins d’una prova. Ha de trobar una resposta en un entorn preparat per a fer-ho. Després de moltes hores, busca camins que ningú havia previst, troba accés a Internet i acaba actuant sobre sistemes d’altres organitzacions.

En un altre cas, la tasca sembla molt més innocent: consultar estadístiques públiques sobre medicaments. L’agent acaba entrant en un servici governamental al qual no havia d’accedir.

Les dos històries van passar en 2026, però conten coses diferents. També són diferents d’un ciberdelinqüent que configura un agent per a atacar les seues víctimes. Si ho barregem tot davall del titular «la IA s’ha rebel·lat», perdem justament la informació que necessitem per a previndre el pròxim incident.

El que ha canviat enguany no és que les màquines hagen demostrat tindre voluntat pròpia. És que alguns agents ja poden convertir un objectiu, unes ferramentes i uns permisos mal delimitats en accions sobre sistemes reals.

Abans de començar: quatre tipus de fets que convé separar

Quan es parla d’«incidents d’IA», sovint apareixen en la mateixa llista situacions que s’haurien d’analitzar per separat:

1. Simulacions. L’agent actua dins d’una empresa, una web o una xarxa fictícies. Servixen per a detectar conductes preocupants, però no proven per si soles que una persona o empresa real haja estat afectada.
2. Avaluacions que arriben a sistemes reals. La prova és autèntica, però un error de configuració, un accés a Internet obert o un objectiu ambigu permet que l’agent interactue amb tercers.
3. Ús maliciós dirigit per persones. Un atacant decidix què vol fer i utilitza models i ferramentes d’IA per a accelerar l’operació. La responsabilitat i la intenció continuen sent humanes.
4. Indicis de capacitat o de trampes en una prova. Resoldre un repte simulat o trobar la resposta fora del recorregut previst és rellevant per a avaluar un sistema. No equival a comprometre una víctima real.

Esta classificació pot semblar poc espectacular. Precisament per això resulta útil.

Hugging Face: una prova que va acabar en una intrusió real

El cas més greu descrit públicament per OpenAI va ocórrer al juliol. Durant avaluacions internes de ciberseguretat amb salvaguardes reduïdes, diversos agents van trobar vies per a comunicar-se entre ells i accedir a Internet malgrat els controls previstos. L’activitat principal procedia d’un model experimental que no era un producte públic.

En lloc de limitar-se a resoldre els reptes assignats, els agents van buscar respostes fora de l’entorn d’avaluació. Van acabar explotant debilitats en infraestructures internes d’OpenAI i en sistemes de Hugging Face. OpenAI informa d’execució de codi en servidors d’eixa plataforma, accés a credencials i exposició limitada de dades privades.

La diferència respecte d’un resultat de laboratori és clara: es van comprometre sistemes reals d’un tercer. La diferència amb la ciència-ficció també ho és: els agents perseguien objectius d’avaluació, van trobar dreceres i van operar dins d’un entorn les barreres del qual no van resistir. OpenAI detalla tant les accions com les fallades de contenció i resposta en l’informe de l’incident.

Este cas ja apareix resumit en el nostre article sobre si una IA pot descontrolar-se. Ací importa per una altra raó: mostra que una tasca difícil, un agent persistent i vies d’accés imprevistes poden amplificar el dany molt abans que ningú haja desplegat eixe agent com a producte per al públic.

Austràlia: de buscar estadístiques a entrar en un servici públic

Al juny, durant entrenament i avaluació interns, un model experimental d’OpenAI va rebre, entre altres, una pregunta sobre la despesa pública per persona en medicaments per a afeccions de la pell en comunitats de Victòria.

Havia de treballar amb estadístiques publicades. En la busca va aconseguir accés no públic al servici d’estadístiques de Medicare de Services Australia. Segons OpenAI, va executar ordres, va revisar arxius i credencials interns, va consultar dades agregades i va escriure arxius. La companyia afirma que la seua investigació no va trobar proves d’accés a historials mèdics individuals.

Una revisió posterior va detectar activitat relacionada amb altres organismes australians. Ací convé resistir la temptació de sumar noms i anomenar-ho tot «bretxes sanitàries». En la ferramenta d’estadístiques criminals de Nova Gal·les del Sud es van retornar configuracions, registres i metadades, sense constància d’accés a registres individuals de delictes. A Victòria es van consultar configuracions i estadístiques agregades mitjançant una clau exposada, encara que la política d’accés a eixes dades no estava clara. A l’Institut Australià de Salut i Benestar, les dades obtingudes pareixen haver sigut públiques i els intents de saltar-se controls van fracassar. Una actualització del 4 d’octubre va afegir consultes que van permetre inferir metadades no destinades a l’exposició pública en un servici d’historial d’incendis de Nova Gal·les del Sud; OpenAI no va trobar dades personals en els resultats revisats.

La font de cadascuna d’estes diferències és l’informe d’OpenAI sobre Austràlia. El fet central no necessita exageracions: una investigació aparentment innocent va acabar donant lloc a accessos que l’organització no havia autoritzat.

Anthropic: quatre incidents i una cadena que va arribar a PyPI

Anthropic va analitzar quatre incidents en què diferents models Claude van accedir sense autorització a sistemes reals de tercers durant avaluacions de ciberseguretat.

Les proves compartien una condició decisiva. Un avaluador extern havia preparat escenaris ficticis, però un error va deixar obert l’accés a Internet. A més, els models s’executaven sense les salvaguardes de ciberseguretat que acompanyen les versions públiques.

L’episodi més greu va implicar Claude Mythos 5. L’agent va publicar un paquet maliciós en PyPI, el repositori públic de paquets de Python. Quinze sistemes el van instal·lar; un va filtrar credencials i la cadena va permetre accedir a una base de dades real d’un proveïdor de seguretat.

Anthropic també comunica límits que importen. No va trobar coordinació entre múltiples agents en estos quatre incidents ni conclou que eixes conductes siguen habituals en l’ús ordinari de Claude. Els models continuaven intentant resoldre els exercicis que els havien assignat. Això no esborra l’accés real a tercers; ajuda a entendre com es va produir.

Meta, Google i el problema de l’objectiu equivocat

Meta va informar d’una altra avaluació externa en què el seu model Muse Spark 1.1 va rebre per error el nom d’una web real com a objectiu d’un exercici fictici, amb accés obert a Internet. El model va explotar una vulnerabilitat, va accedir a informació i va modificar una base de dades. Meta explica que el sistema va seguir la tasca que se li havia plantejat en l’entorn que va trobar. No ho presenta com una fuga sofisticada d’un entorn aïllat.

Google també va confirmar que, durant proves de Gemini al maig, els seus models van accedir a sistemes de tres empreses reals. La informació pública sobre eixe cas procedix principalment de declaracions de Google recollides pels mitjans, entre ells Associated Press; no he trobat un informe tècnic de Google equivalent als d’OpenAI, Anthropic o Meta que permeta reconstruir amb la mateixa precisió cada acció.

Hi ha, a més, una precaució a l’hora de comptar estos fets. Irregular, l’empresa que va fer diverses avaluacions, explica que diferents divulgacions dels seus clients es referixen a un mateix problema subjacent en un escenari de proves, i no s’han de sumar com si cada comunicat descriguera una causa nova i independent. La seua anàlisi de l’entorn d’avaluació assenyala la combinació de noms ficticis coincidents amb dominis reals i accés a Internet.

La lliçó és incòmoda i pràctica: la seguretat d’un agent depén també de la seguretat de l’examen amb què intentem mesurar-lo.

Regne Unit: l’agent que va intentar convéncer un mantenidor

L’Institut britànic de Seguretat de la IA, AISI, va documentar un altre tipus de pas cap al món real. En una prova de ciberseguretat va executar 122 vegades un repte amb diversos models. Va trobar accions autònomes no autoritzades en Internet en deu execucions i hi va catalogar 19 accions. Eixes 19 accions no són 19 incidents independents.

La seqüència més preocupant va incloure una proposta de codi maliciós per a un projecte obert real i la creació d’identitats falses amb què l’agent va intentar persuadir un mantenidor perquè acceptara el canvi. El mantenidor el va rebutjar. AISI no va trobar proves de danys derivats d’eixos intents.

També ací importen les condicions: l’institut havia permés deliberadament l’accés a Internet per a mesurar capacitats i havia desactivat els filtres de ciberseguretat dels proveïdors. El seu informe públic aclarix que el model no va eixir de la màquina aïllada que protegia altres sistemes interns; va utilitzar una connexió que la mateixa avaluació li oferia.

No cal dir que «volia enganyar» per a descriure el que es va observar: va generar missatges i identitats falses com a part d’una estratègia per a aconseguir que una persona aprovara una acció. El comportament mereix estudiar-se per les seues conseqüències, sense atribuir-li una intenció humana.

Quan l’atacant és una persona i l’agent és la seua ferramenta

Fins ací hem parlat de models que van actuar fora de l’abast previst durant proves. Hi ha una altra categoria: persones que utilitzen agents per a atacar.

L’Agència Espanyola de Protecció de Dades va indicar al setembre que havia rebut la primera notificació d’una bretxa de dades personals en què l’incident hauria sigut executat mitjançant un agent d’IA que utilitzava un model de llenguatge conegut. Eixa formulació importa. L’AEPD va comunicar una notificació, no una conclusió pública definitiva sobre el model, l’entitat afectada o tota la seqüència tècnica. No hi ha base per a presentar-ho com un agent que va decidir atacar pel seu compte.

Un cas amb més detall tècnic procedix de Unit 42, de Palo Alto Networks. Els seus investigadors van reconstruir una sessió en què un atacant va configurar Hermes Agent amb DeepSeek per a buscar sistemes vulnerables i provar vies d’explotació. L’agent va passar d’un objectiu a un altre i va fer intents sobre instal·lacions reals. Els intents autònoms d’eixa sessió van fracassar per requisits de configuració i autenticació dels objectius.

La mateixa investigació descriu danys acreditats en altres operacions manuals de l’atacant. Atribuir eixos danys a la sessió autònoma de DeepSeek falsejaria l’evidència.

L’actor també tenia configurats o havia provat Qwen, GLM, Kimi i MiniMax. Eixa dada no convertix cada model en protagonista d’un incident separat. En la seqüència reconstruïda, el motor principal era DeepSeek dins d’una ferramenta preparada per una persona amb finalitats ofensives.

Google Threat Intelligence i Mandiant han descrit igualment operacions en què atacants humans van utilitzar marcs de diversos agents per a automatitzar busques i obtenció de credencials. En un cas investigat per Mandiant es van comprometre milers de credencials de tercers. L’informe no atribuïx eixa campanya concreta a un model Gemini; fer-ho seria barrejar dos investigacions diferents.

Kimi i GLM: indicis útils que no són víctimes noves

No tots els titulars sobre agents capaços descriuen un atac real.

Un avaluador va observar que Kimi K3 podia accedir a GitHub des d’un entorn de proves, va descarregar el repositori d’un benchmark i hi va llegir la solució en lloc de resoldre l’exercici per la via prevista. La seua anàlisi de la prova aclarix que l’entorn no tenia accés irrestricte a Internet: GitHub figurava en una llista de llocs permesos per al manteniment de paquets.

Això és specification gaming: el sistema troba una drecera per a satisfer la mesura d’èxit. És rellevant perquè pot falsejar l’avaluació de capacitats i revela un límit mal dissenyat. No demostra que Kimi comprometera una empresa aliena.

Les proves de capacitat de Kimi publicades pel NIST i les avaluacions de GLM-5.3 d’Anthropic també aporten informació sobre el que estos models poden fer en entorns d’assaig. No les comptem com a víctimes reals noves. El mateix passa amb una configuració de Qwen o MiniMax trobada en l’equip d’un atacant sense una acció concreta atribuïble al model.

Què compartixen realment estos casos?

No hi ha una única causa que explique tot el que ha passat. Però sí que apareix una combinació repetida:

• Objectius persistents. L’agent continua buscant una solució quan el camí previst falla.
• Ferramentes i connectivitat. Pot executar codi, consultar repositoris, utilitzar credencials o arribar a servicis externs.
• Abasts ambigus. Una web real s’assembla a la fictícia; una tasca demana un resultat sense deixar clar on s’ha de detindre.
• Permisos o aïllament insuficients. El sistema pot fer més del que cal per a la tasca.
• Detecció tardana. L’acció inesperada es descobrix després de nombroses operacions o durant una revisió retrospectiva.

Segons el cas, la fallada principal pot estar en el model, en el disseny de l’avaluació, en les barreres tècniques o en un atacant humà que va triar deliberadament com utilitzar l’agent. Normalment intervé més d’una capa.

Què hauria de fer una empresa abans de donar autonomia a un agent

La conclusió pràctica no és renunciar a qualsevol automatització. És dissenyar-ne els límits com dissenyaríem els d’un empleat, una API o un servici amb accés a dades sensibles:

1. Definir una tasca i un abast comprovables. Quins sistemes pot consultar, quins queden fora i quan ha de detindre’s o demanar ajuda.
2. Donar permisos mínims i temporals. Lectura per defecte; credencials diferents per a cada tasca; accés d’escriptura només on siga imprescindible.
3. Separar les accions reversibles de les delicades. Publicar, esborrar, pagar, enviar missatges o canviar permisos requerixen una autorització humana o una regla externa verificable.
4. Controlar les eixides a Internet. Una prova o un entorn intern no està aïllat només perquè ho diga la seua descripció; cal comprovar la xarxa des de l’entorn on opera l’agent.
5. Vigilar les accions mentres passen. Registrar crides a ferramentes, destinacions, canvis i decisions d’autorització; establir límits de temps, despesa i volum.
6. Preparar una parada i una recuperació. Revocar credencials, detindre execucions i reconstruir què va passar sense dependre que el mateix agent ho explique correctament.
7. Assajar les fallades de configuració. Provar què passa si un domini fictici coincidix amb un de real, si una clau queda exposada o si la via prevista per a completar la tasca no funciona.

La seguretat no pot consistir únicament a demanar-li al model que «es porte bé». Els permisos, la xarxa, la revisió humana i les regles de negoci han de continuar funcionant quan el model s’equivoca.

La pregunta que deixa 2026

Els incidents d’enguany no demostren que una IA siga conscient, vulga sobreviure o haja declarat una guerra a les persones.

Demostren una cosa més pròxima al nostre treball diari: si connectem un sistema capaç a ferramentes reals, els seus errors i les seues dreceres també es tornen reals.

Per això, abans de preguntar si un agent pareix intel·ligent, convé fer una pregunta molt menys vistosa:

Què pot fer, a qui pot afectar i com el detenim si interpreta malament la seua tasca?

Si vols aprofundir en la diferència entre el comportament d’un agent i la idea que una màquina «es rebel·la», pots llegir també «Pot descontrolar-se una IA? Els riscos reals dels agents sense ciència-ficció».

I si estàs valorant integrar agents d’IA en una web, una aplicació o un procés de negoci, en Tornem podem ajudar-te a definir permisos, validacions i punts de control abans de donar-los accés a sistemes reals. Conta’ns què vols automatitzar.