Agentes de IA en la empresa: cómo limitar su radio de acción antes de que sea tarde

Los agentes de inteligencia artificial ya no se limitan a responder preguntas. Pueden consultar documentación, trabajar con el CRM, modificar código, ejecutar procesos, preparar facturas o actuar sobre sistemas corporativos.

Esa capacidad aporta velocidad, pero también introduce un riesgo nuevo: ¿qué ocurre si un agente interpreta una instrucción maliciosa, usa una herramienta de forma incorrecta u opera con más permisos de los necesarios?

Las investigaciones publicadas en los últimos meses han puesto el foco en amenazas como la inyección indirecta de instrucciones, el abuso de herramientas, los permisos excesivos, el envenenamiento de memoria y el movimiento lateral entre agentes.

Muchos de los casos más mediáticos siguen siendo demostraciones de laboratorio o vulnerabilidades comunicadas de forma responsable, no ataques confirmados contra empresas identificadas. Pero todos apuntan a la misma conclusión:

El riesgo no es solo que alguien manipule las instrucciones de un agente. El riesgo real depende de lo que ese agente pueda hacer después.

Un agente de IA es una nueva identidad dentro de la empresa

Un agente puede disponer de:

credenciales propias;
acceso a aplicaciones corporativas;
conexión con bases de datos;
herramientas capaces de ejecutar acciones;
memoria persistente;
acceso a Internet;
capacidad de comunicarse con otros agentes.

Por eso, desde el punto de vista de la seguridad, conviene tratarlo como una identidad no humana.

No debería recibir acceso general a la red solo porque forma parte de un proceso interno. Tampoco debería compartir credenciales con personas, servidores u otros agentes.

El principio debería ser el mismo que en una arquitectura Zero Trust: no confiar por defecto y autorizar únicamente lo que necesita para cumplir su función.

El problema no acaba en el prompt injection

Una inyección de instrucciones puede llegar escondida en un correo, una página web, un documento, un ticket de soporte o cualquier otra fuente que el agente procese.

Si el agente solo puede leer una carpeta concreta, el impacto potencial será limitado. Pero si además puede consultar información confidencial, modificar sistemas, ejecutar código y enviar datos a cualquier destino, una misma manipulación puede tener consecuencias mucho más graves.

Por tanto, la protección no puede depender exclusivamente de detectar instrucciones maliciosas. Hay que asumir que, en algún momento, el agente puede equivocarse o ser manipulado, y preparar el entorno para que ese error quede contenido.

Cinco controles antes de poner un agente en producción

1. Una identidad propia para cada agente

Cada agente debería tener una identidad diferenciada, con credenciales revocables y un propósito concreto.

Esto permite saber qué agente ha hecho cada conexión, retirarle el acceso sin afectar a otros servicios y evitar credenciales compartidas imposibles de auditar.

Cuando un agente deja de usarse, su identidad y sus permisos también deben retirarse.

2. El mínimo privilegio como configuración inicial

Un agente de soporte no necesita acceder al sistema financiero. Un agente de desarrollo no debería consultar datos de recursos humanos. Un agente que genera informes no necesita modificar la base de datos original.

Los permisos deben concederse según la función real del agente, no según todo lo que podría llegar a hacer.

El modelo más seguro es empezar con el acceso denegado y autorizar después, de forma explícita, cada recurso necesario.

3. Segmentación y acceso solo a los recursos necesarios

Conectar un agente a toda la red corporativa amplía innecesariamente su radio de acción.

La microsegmentación permite limitarlo a una aplicación, un servidor o un entorno concreto. Si el agente es manipulado o sus credenciales quedan comprometidas, esa separación dificulta que el incidente se propague a otros sistemas.

El agente debe poder llegar al recurso que necesita, no "entrar" en toda la red.

4. Control de las conexiones y los destinos

También hay que definir hacia dónde puede comunicarse el agente.

Un proceso que solo necesita consultar una API corporativa no debería poder enviar información a cualquier dominio de Internet. Las conexiones salientes, los destinos autorizados y los puntos de salida forman parte del modelo de seguridad.

Este control es especialmente importante cuando el agente trata datos personales, información comercial o documentación interna.

5. Registro y capacidad de contención

Cuando una acción es automatizada, la trazabilidad es imprescindible.

La empresa debería poder responder preguntas como:

¿Qué agente inició la conexión?
¿Cuándo lo hizo?
¿Desde qué dispositivo o entorno?
¿A qué recurso accedió?
¿Qué destino utilizó?
¿Se puede bloquear o aislar rápidamente?

Los registros no evitan todos los incidentes, pero permiten investigarlos, delimitar su alcance y actuar con más rapidez.

Cómo encaja ConnectaSec

ConnectaSec puede ayudar a limitar el radio de acción de los agentes a escala de red y de acceso, aplicando los mismos principios Zero Trust que se usan para proteger a personas, dispositivos y cargas de trabajo.

Esto incluye:

acceso denegado por defecto;
políticas de acceso por recurso;
microsegmentación;
conexiones salientes sin exponer puertos a Internet;
gateway dedicado por cliente;
posibilidad de elegir el punto de salida del tráfico;
registro de conexiones y trazabilidad;
capacidad de contener accesos sin abrir toda la red.

ConnectaSec no inspecciona los prompts ni sustituye la seguridad interna del agente. Tampoco reemplaza la gestión de secretos, los permisos de las aplicaciones, las aprobaciones humanas o los controles propios del modelo de IA.

Su función es complementaria: reducir hasta dónde puede llegar el agente si comete un error, recibe una instrucción maliciosa o ve comprometida su identidad.

Cinco casos de uso

Agente de soporte conectado al CRM

Necesita: consultar fichas de clientes y crear o actualizar tickets.

No debería poder: acceder a facturación, recursos humanos, infraestructura o copias de seguridad.

Salidas permitidas: CRM, plataforma de soporte y servicios estrictamente necesarios.

Hay que auditar: consultas masivas, exportaciones, cambios de datos y conexiones fuera del horario habitual.

Agente de desarrollo

Necesita: consultar repositorios, abrir incidencias y ejecutar procesos controlados de integración.

No debería poder: acceder directamente a producción, descargar secretos generales o modificar infraestructuras fuera de su proyecto.

Salidas permitidas: repositorios, herramientas de desarrollo y servicios aprobados.

Hay que auditar: modificaciones de código, ejecuciones, cambios de permisos e intentos de acceso a otros entornos.

Agente financiero

Necesita: leer facturas, preparar conciliaciones o generar informes.

No debería poder: autorizar pagos, modificar cuentas bancarias o exportar bases de datos completas sin aprobación.

Salidas permitidas: ERP, repositorio documental y servicios financieros autorizados.

Hay que auditar: acceso a datos sensibles, exportaciones, cambios de beneficiarios y acciones que requieren validación humana.

Agente de operaciones o SRE

Necesita: consultar telemetría, revisar alertas y proponer acciones correctivas.

No debería poder: ejecutar órdenes destructivas o desplegar cambios críticos sin una aprobación explícita.

Salidas permitidas: monitorización, repositorios operativos y entornos delimitados.

Hay que auditar: órdenes ejecutadas, escaladas de privilegios, cambios de configuración y comunicaciones con sistemas externos.

MSP con agentes para varios clientes

Necesita: operar procesos repetitivos para cada organización.

No debería poder: reutilizar una identidad entre clientes ni mover datos de un entorno a otro.

Salidas permitidas: los recursos y gateways correspondientes a cada cliente.

Hay que auditar: separación entre clientes, identidad utilizada, cambios de política y acciones administrativas.

Checklist antes de activar un agente de IA

Antes de ponerlo en producción, conviene comprobar:

¿Tiene una identidad propia?
¿Sus credenciales se pueden revocar?
¿Dispone solo de los permisos imprescindibles?
¿Puede acceder únicamente a los recursos necesarios?
¿Está separado del resto de la red?
¿Sus conexiones salientes están controladas?
¿Las acciones sensibles requieren aprobación humana?
¿Se registra quién accede, cuándo y a qué recurso?
¿Existe un procedimiento para bloquearlo o contenerlo?
¿Se revisan su memoria y las fuentes que consulta?
¿Se han probado escenarios de error o manipulación?
¿Hay una persona responsable de su ciclo de vida?

La pregunta correcta

La pregunta ya no es solo si una empresa usará agentes de IA.

La pregunta es:

Cuando un agente se equivoque o sea manipulado, ¿hasta dónde podrá llegar?

Una arquitectura Zero Trust no elimina todos los riesgos asociados a la inteligencia artificial. Pero puede convertir un acceso general y difícil de controlar en un conjunto de conexiones limitadas, segmentadas y auditables.

Si tu empresa está desplegando agentes de IA, ConnectaSec puede ayudarte a revisar su segmentación, sus accesos y sus conexiones antes de ponerlos en producción.

El modelo de precio parte de 5 €/mes por usuario, con hasta 5 dispositivos incluidos, más gateway dedicado desde 40 €/mes.