¿Pero de verdad sabemos qué hacen nuestros agentes?

Empecemos con lo crudo: los sistemas de agentes autónomos en AI no son juguetes. Ni tampoco simples scripts inofensivos chupando datos por ahí. En un reciente análisis, se cita el fiasco de Anthropic donde un sistema llamado Claude fue convertido en arma de espionaje porque sus herramientas no estaban sujetas a control. Le dieron acceso libre a escáneres, exploradores de vulnerabilidades, parsers de datos… cualquier cosa que un atacante pudiera necesitar para hacer la puñeta.

La solución que se repite en directivas de SAI como la NIST o el marco de Google (SAIF) insiste en un principio que más parece sentido común: *trata a cada agente como un usuario poderoso, con identidad propia y responsabilidades claras*. Sí, “identidad propia”. Esto significa ni más ni menos que cada agente debe funcionar con una cuenta personal que refleje un usuario real, con el acceso exacto que necesita, nada más. Nada de identidades sin rostro con permisos de “superhéroe que lo puede todo”. De lo contrario, la cosa se va de las manos y terminas con agentes que cruzan límites territoriales, roles y datos sin que nadie sepa ni por qué ni para qué.

¿La pregunta para el CEO? ¿Puede mostrar hoy un listado claro de agentes, con sus permisos, limitaciones y alcances tan ordenado como una nómina de empleados? Porque si la respuesta es no, estamos dejando la puerta abierta para que te metan un gol en cualquier momento. Ni intentes darle largas.

Atar en corto las herramientas y cadenas de mando: ¿Quién aprueba qué?

El sentido común dice que un agente no debería poder lanzarse a manejar todas las herramientas que le dé la gana. ¿Y si lo hace? El hackeo de Anthropic demuestra que cuando un adversario conecta su agente a una variedad flexible de herramientas no reguladas, el desastre es cuestión de tiempo. Cuestionar esto es básico.

Aquí entra una idea brillante: mira el conjunto de herramientas y recursos que tu agente puede manipular como una cadena de suministro crítica a la que se le pone un tag, una letrina y un guardia con pistola lista para disparar. No puedes andar dejando que nuevos componentes se añadan sin pasar por revisión, sin tener un responsable firmante que dé el visto bueno. Nada de “que la máquina haga”. La automatización sin control va a ser tu perdición. Si no hay una política clara que lo permita, esa concatenación automática de herramientas debe estar prohibida.

Piénsalo: si no sabes quién dio luz verde para que un agente use un nuevo módulo de datos o comando, estás navegando a ciegas en aguas infestadas de tiburones que, en este caso, no son imaginarios. Para efectos prácticos, es OWASP diciendo “ojo, exceso de autonomía mata”. Y la legislación europea, con su AI Act, no se anda con chiquitas: esto es parte del arte 15 donde tienes que diseñar para evitar abusos y hacer que sistemas como estos sean blindados frente al hacker de turno.

Pregúntate: ¿en tu empresa, quién firma cuando un agente recibe una nueva herramienta o acceso ampliado? ¿Lo sabes? ¿Hay trazabilidad para ese visto bueno? Si la respuesta es “no lo sé” o “confío”, mal asunto.

Olvídate del “hágalo bonito con prompts”: credenciales atadas a tareas, no modelos

Esto suena tonto, pero es un error recurrente: darle a un modelo acceso generalizado y esperar que se porte bien porque “los prompts lo mantienen a raya”. Spoiler: el prompt solo da ordenes; no pone límites reales. La realidad que marcan SAIF y NIST es la contraria: cada permiso debe estar atado a la herramienta y tarea concreta, rotarse con frecuencia y quedar registrado para auditoría.

Un agente financiero, por ejemplo, que pueda leer pero no manipular ciertas cuentas sin aprobación del CFO, es el modelo ideal. No un agente que tiene la llave maestra y que uno espera que sea “educado” usando instrucciones verbalmente corteses.

¿Puedes hoy revocar el permiso de un agente sin tener que reescribir la arquitectura completa del sistema? Si la respuesta es no, te estás hundiendo con anclas.

Datos hostiles y memoria sospechosa: ¿Qué entra en nuestro sistema?

El problema número uno de seguridad en agentes AI no es que fallen por fallar, sino que entran por la puerta de atrás con datos envenenados a propósito. ¿Una web mellada? ¿Un PDF trampa? ¿Un correo infectado? Todo eso se cuela y hace un desastre.

Las guías de seguridad como OWASP insisten en separar estrictamente los datos del sistema de las instrucciones propias del agente. Mejor aún, trata todo contenido externo como enemigo hasta que alguien certificado lo declare seguro. Esto incluye un sistema careado: cada fuente externa debe ser revisada, etiquetada y aprobada, cada fragmento de información debe llevar su sello de procedencia y nada entra en la memoria persistente sin filtro.

¿Tienes un inventario transparente de todas las fuentes externas que alimentan a tu agente? ¿Y sabes quién aprobó cada una? No te hagas humo, porque ignorar esto te lleva directo al desastre de manipulación vía prompt injection o similar.

Sacar datos, pero sin liarla: validar todo output, ni un paso en falso

¿Qué pasa cuando un agente genera código para explotar sistemas o divulga credenciales? Pues que si esa salida resulta accionable sin revisión humana o un sistema de validación, es un suicidio corporativo.

Fue lo que pasó con Anthropic: salidas directas que ejecutaban acciones nocivas sin control. OWASP y los mejores sistemas de seguridad de browsers se aseguran que nada escape sin verificar, que se validen salidas antes de que toquen sistemas reales o clientes.

¿Dónde está ese checkpoint en tu empresa? ¿Dónde se decide si el output de un agente es seguro antes de actuar? Si no puedes responder con claridad, vuelve a la casilla uno.

¿Y la data privada? Protegiendo el corazón del sistema

No sirve de nada tener un montón de reglas si cuando los agentes interactúan con datos sensibles, estos pueden divulgarlos sin cortapisas. De eso va la protección de datos en tiempo de ejecución: diseñar sistemas que tengan “seguridad por defecto”, donde datos sensibles se enmascaren o tokenicen y solo se puedan revelar con estrictos controles.

Ni hablar del cumplimiento normativo — GDPR, AI Act —, los cuales exigen que cualquier contacto con datos regulados sea monitorizado, controlado al detalle y que el sistema registre cada «desenmascaramiento». Si un agente queda comprometido, el daño queda limitado solo a lo que la política permite.

¿Tu arquitectura impone estas limitaciones o confías en promesas de papel?

¿Y si algo falla? Evaluación continua y auditar como si no hubiera un mañana

Si piensas que hacer una única prueba al implementar tu agente es suficiente, me temo que estás más perdido que nunca. La investigación de Anthropic subraya que hay “agentes durmientes”, riesgos que solo salen cuando menos lo esperas.

Esto obliga a un monitoreo constante, con equipos dedicados a romper agentes semanalmente para descubrir sus puntos débiles. Todo evento se registra, se analiza y se transforma en test de regresión para que estos fallos no se repitan.

Además, la trazabilidad: inventario vivo donde se guardan todos los agentes, plataformas, scopes, herramientas, aprobaciones y todo movimiento que impacte su comportamiento. Un auditor debería poder reconstruir fácilmente la cadena de decisiones detrás de cualquier acción de agente.

¿Quién se encarga de romper tus agentes cada semana? ¿Utilizan sus hallazgos para endurecer tus políticas? Si no tienes respuesta, ni te molestes.

Más allá del agente: piensa en el sistema entero, incluyendo amenazas sociales

Para rematar, un punto al que muchos no quieren mirar pero que es el meollo del problema. Las amenazas no atacan solo modelos o agentes aislados; atacan sistemas complejos. Por eso hay frameworks como MITRE ATLAS, que analizan tácticas y técnicas usadas por grupos de amenazas concretos (¿alguien dijo GTG-1002?) para comprometer sistemas enteros.

¿Crees que tienes un problema de AI o uno de seguridad corporativa en general? Por aquí va la respuesta. Tratar a un agente como un usuario poderoso y mantenerlos dentro de fronteras claras es la única forma de mantener algún control.

No es magia ni un chaleco antibalas que detenga todo, pero sí el único camino sensato para que esta pesadilla de agentes autónomos no acabe con tu reputación y tu negocio. El reto para CEOs y directivos no es “¿tenemos buenas barreras AI?”, sino si pueden mostrar evidencias reales y no excusas. ¿Tú las tienes?

¿Quieres dejar que tu IA haga lo que le dé la gana, o vas a ponerle un corsé de verdad? La pregunta ya no es si, sino cuándo. ¿Y tú?

Por Helguera

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *