Imaginá que tu empresa opera doscientos agentes de IA. Coordinan reuniones, procesan facturas, responden clientes, despliegan código y administran inventario. Se conectan a herramientas mediante MCP, colaboran con otros agentes y ejecutan acciones sobre sistemas reales.
La pregunta importante no es cuántos agentes podés desplegar. Es quién controla lo que hacen cuando el trabajo atraviesa varias herramientas, identidades y permisos.
¿Hacia dónde se mueve el trabajo con agentes?
Estamos pasando de personas que usan herramientas de IA a agentes que operan de forma continua. MCP ya tiene miles de implementaciones publicadas y pasó a la gobernanza de Linux Foundation. Las plataformas principales están construyendo runtimes para agentes, mientras empresas como Uber y Google Cloud reportan decenas de miles de tasks y millones de tool calls.
No es una posibilidad futura. La infraestructura ya se está desplegando. El problema es que la capacidad crece más rápido que los controles.
¿Qué falla cuando los agentes interactúan a escala?
Una llamada aislada tiene un límite de confianza relativamente claro. Una cadena compuesta no. Un agente llama a otro, que consulta un MCP server, que invoca una herramienta con acceso a una base de datos. Cada salto toma una decisión de autorización, pero casi ningún sistema evalúa la acción completa de punta a punta.
Los permisos se acumulan. Si un agente accede al correo y puede invocar a otro con acceso al repositorio, la composición termina habilitando capacidades que nadie aprobó como conjunto. Con cientos de agentes, el grafo de permisos deja de ser comprensible para una revisión manual.
La atribución se pierde. Cuando una cadena envía un correo, modifica una tabla o despliega código, hace falta saber qué instancia actuó, por pedido de quién, con qué herramientas y bajo qué política. Una cuenta de servicio compartida no puede responderlo.
La supply chain cambia mientras se usa. Cada MCP server y cada skill es una dependencia. Puede modificar descripciones, incorporar nuevas herramientas o quedar comprometida después de la revisión inicial. El análisis estático de un momento no alcanza para un ecosistema que muta todos los días.
¿Qué significa zero trust para un agente de IA?
Significa no confiar por defecto en una herramienta, un server o un agente par, y verificar cada invocación mientras ocurre. Conectarse a un MCP server no debería habilitar todas sus herramientas. La autorización tiene que poder limitarse por agente, herramienta, acción y parámetros.
El comportamiento depende del prompt, las herramientas y el contexto. Cualquiera de esas piezas puede cambiar. Por eso el control en runtime no es una capa opcional. Tiene que detectar desvíos, hacer cumplir políticas y conservar evidencia de cada decisión.
La confianza entre agentes también debe ser explícita. A2A mejora la identificación y el intercambio entre agentes, pero la existencia de un protocolo no reemplaza una política que determine qué puede hacer cada participante dentro de una task concreta.
¿Qué infraestructura hace falta?
Primero, identidad por instancia y delegación verificable. Segundo, autorización por invocación, no solo por conexión. Tercero, políticas que inspeccionen la acción antes de ejecutarla. Cuarto, evidencia que registre actor, herramienta, argumentos, resultado y decisión. Finalmente, monitoreo continuo de las dependencias que componen el entorno.
Ese es el espacio en el que estoy construyendo Oktsec: controles diseñados para agentes que operan sobre sistemas reales, no adaptaciones superficiales de una checklist de AppSec.
La seguridad de agentes todavía está en una etapa temprana. Las decisiones que tomemos ahora van a definir qué se considera una implementación aceptable cuando estos sistemas sean infraestructura cotidiana.