Agents d'IA a l'empresa: com limitar el seu radi d'acció abans que sigui massa tard

Els agents d'intel·ligència artificial ja no es limiten a respondre preguntes. Poden consultar documentació, treballar amb el CRM, modificar codi, executar processos, preparar factures o actuar sobre sistemes corporatius.

Aquesta capacitat aporta velocitat, però també introdueix un nou risc: què passa si un agent interpreta una instrucció maliciosa, utilitza una eina incorrectament o opera amb més permisos dels necessaris?

Les investigacions publicades durant els darrers mesos han posat el focus en amenaces com la injecció indirecta d'instruccions, l'abús d'eines, els permisos excessius, l'enverinament de memòria i el moviment lateral entre agents.

Molts dels casos més mediàtics encara són demostracions de laboratori o vulnerabilitats comunicades de manera responsable, no atacs confirmats contra empreses identificades. Però tots apunten a una mateixa conclusió:

El risc no és només que algú manipuli les instruccions d'un agent. El risc real depèn del que aquest agent pugui fer després.

Un agent d'IA és una nova identitat dins l'empresa

Un agent pot disposar de:

credencials pròpies;
accés a aplicacions corporatives;
connexió amb bases de dades;
eines capaces d'executar accions;
memòria persistent;
accés a Internet;
capacitat per comunicar-se amb altres agents.

Per això, des del punt de vista de la seguretat, convé tractar-lo com una identitat no humana.

No hauria de rebre accés general a la xarxa només perquè forma part d'un procés intern. Tampoc hauria de compartir credencials amb persones, servidors o altres agents.

El principi hauria de ser el mateix que en una arquitectura Zero Trust: no confiar per defecte i autoritzar únicament allò que necessita per completar la seva funció.

El problema no acaba amb el prompt injection

Una injecció d'instruccions pot arribar amagada dins d'un correu, una pàgina web, un document, un tiquet de suport o qualsevol altra font que l'agent processi.

Si l'agent només pot llegir una carpeta concreta, l'impacte potencial serà limitat. Però si també pot consultar informació confidencial, modificar sistemes, executar codi i enviar dades a qualsevol destinació, una mateixa manipulació pot tenir conseqüències molt més greus.

Per tant, la protecció no pot dependre exclusivament de detectar instruccions malicioses. Cal assumir que, en algun moment, l'agent pot equivocar-se o ser manipulat, i preparar l'entorn perquè aquest error quedi contingut.

Cinc controls abans de posar un agent en producció

1. Una identitat pròpia per a cada agent

Cada agent hauria de disposar d'una identitat diferenciada, amb credencials revocables i un propòsit concret.

Això permet saber quin agent ha fet cada connexió, retirar-li l'accés sense afectar altres serveis i evitar credencials compartides impossibles d'auditar.

Quan un agent deixa d'utilitzar-se, la seva identitat i els seus permisos també s'han de retirar.

2. El mínim privilegi com a configuració inicial

Un agent de suport no necessita accedir al sistema financer. Un agent de desenvolupament no hauria de consultar dades de recursos humans. Un agent encarregat de generar informes no necessita modificar la base de dades original.

Els permisos s'han de concedir segons la funció real de l'agent, no segons tot allò que podria arribar a fer.

El model més segur és començar amb l'accés denegat i autoritzar després, de manera explícita, cada recurs necessari.

3. Segmentació i accés només als recursos necessaris

Connectar un agent a tota la xarxa corporativa amplia innecessàriament el seu radi d'acció.

La microsegmentació permet limitar-lo a una aplicació, un servidor o un entorn concret. Si l'agent és manipulat o les seves credencials queden compromeses, aquesta separació dificulta que l'incident es propagui cap a altres sistemes.

L'agent ha de poder arribar al recurs que necessita, no "entrar" a tota la xarxa.

4. Control de les connexions i les destinacions

També cal definir cap a on pot comunicar-se l'agent.

Un procés que només necessita consultar una API corporativa no hauria de poder enviar informació a qualsevol domini d'Internet. Les connexions sortints, les destinacions autoritzades i els punts de sortida formen part del model de seguretat.

Aquest control és especialment important quan l'agent tracta dades personals, informació comercial o documentació interna.

5. Registre i capacitat de contenció

Quan una acció és automatitzada, la traçabilitat és imprescindible.

L'empresa hauria de poder respondre preguntes com:

Quin agent va iniciar la connexió?
Quan ho va fer?
Des de quin dispositiu o entorn?
A quin recurs va accedir?
Quina destinació va utilitzar?
Es pot bloquejar o aïllar ràpidament?

Els registres no eviten tots els incidents, però permeten investigar-los, delimitar-ne l'abast i actuar amb més rapidesa.

Com hi encaixa ConnectaSec

ConnectaSec pot ajudar a limitar el radi d'acció dels agents a escala de xarxa i d'accés, aplicant els mateixos principis Zero Trust que s'utilitzen per protegir persones, dispositius i càrregues de treball.

Això inclou:

accés denegat per defecte;
polítiques d'accés per recurs;
microsegmentació;
connexions sortints sense exposar ports a Internet;
gateway dedicat per client;
possibilitat d'escollir el punt de sortida del trànsit;
registre de connexions i traçabilitat;
capacitat de contenir accessos sense obrir tota la xarxa.

ConnectaSec no inspecciona els prompts ni substitueix la seguretat interna de l'agent. Tampoc reemplaça la gestió de secrets, els permisos de les aplicacions, les aprovacions humanes o els controls propis del model d'IA.

La seva funció és complementària: reduir fins on pot arribar l'agent si comet un error, rep una instrucció maliciosa o veu compromesa la seva identitat.

Cinc casos d'ús

Agent de suport connectat al CRM

Necessita: consultar fitxes de clients i crear o actualitzar tiquets.

No hauria de poder: accedir a facturació, recursos humans, infraestructura o còpies de seguretat.

Sortides permeses: CRM, plataforma de suport i serveis estrictament necessaris.

Cal auditar: consultes massives, exportacions, canvis de dades i connexions fora de l'horari habitual.

Agent de desenvolupament

Necessita: consultar repositoris, obrir incidències i executar processos controlats d'integració.

No hauria de poder: accedir directament a producció, descarregar secrets generals o modificar infraestructures fora del seu projecte.

Sortides permeses: repositoris, eines de desenvolupament i serveis aprovats.

Cal auditar: modificacions de codi, execucions, canvis de permisos i intents d'accés a altres entorns.

Agent financer

Necessita: llegir factures, preparar conciliacions o generar informes.

No hauria de poder: autoritzar pagaments, modificar comptes bancaris o exportar bases de dades completes sense aprovació.

Sortides permeses: ERP, repositori documental i serveis financers autoritzats.

Cal auditar: accés a dades sensibles, exportacions, canvis de beneficiaris i accions que requereixen validació humana.

Agent d'operacions o SRE

Necessita: consultar telemetria, revisar alertes i proposar accions correctives.

No hauria de poder: executar ordres destructives o desplegar canvis crítics sense una aprovació explícita.

Sortides permeses: monitoratge, repositoris operatius i entorns delimitats.

Cal auditar: ordres executades, escalades de privilegis, canvis de configuració i comunicacions amb sistemes externs.

MSP amb agents per a diversos clients

Necessita: operar processos repetitius per a cada organització.

No hauria de poder: reutilitzar una identitat entre clients ni moure dades d'un entorn a un altre.

Sortides permeses: els recursos i gateways corresponents a cada client.

Cal auditar: separació entre clients, identitat utilitzada, canvis de política i accions administratives.

Checklist abans d'activar un agent d'IA

Abans de posar-lo en producció, convé comprovar:

Té una identitat pròpia?
Les seves credencials es poden revocar?
Disposa només dels permisos imprescindibles?
Pot accedir únicament als recursos necessaris?
Està separat de la resta de la xarxa?
Les seves connexions sortints estan controlades?
Les accions sensibles requereixen aprovació humana?
Es registra qui accedeix, quan i a quin recurs?
Existeix un procediment per bloquejar-lo o contenir-lo?
La seva memòria i les fonts que consulta es revisen?
S'han provat escenaris d'error o manipulació?
Hi ha una persona responsable del seu cicle de vida?

La pregunta correcta

La pregunta ja no és només si una empresa utilitzarà agents d'IA.

La pregunta és:

Quan un agent s'equivoqui o sigui manipulat, fins on podrà arribar?

Una arquitectura Zero Trust no elimina tots els riscos associats a la intel·ligència artificial. Però pot convertir un accés general i difícil de controlar en un conjunt de connexions limitades, segmentades i auditables.

Si la teva empresa està desplegant agents d'IA, ConnectaSec pot ajudar-te a revisar-ne la segmentació, els accessos i les connexions abans de posar-los en producció.

El model de preu parteix de 5 €/mes per usuari, amb fins a 5 dispositius inclosos, més gateway dedicat des de 40 €/mes.