La arquitectura nativa para agentes es infraestructura diseñada específicamente para agentes autónomos de IA, no para humanos — abordando las brechas de seguridad, rendimiento y gobernanza que emergen cuando sistemas probabilísticos operan sobre APIs diseñadas para interacción humana determinista y a velocidad humana.

Las organizaciones que despliegan agentes sobre infraestructura heredada enfrentan frecuencias de escritura en base de datos 60 veces mayores y alcances de OAuth ingobernables que convierten cada permiso amplio en una potencial crisis de Shadow AI.

“Si tu sistema asume que quien se autentica es quien actúa, o que el comportamiento del programa es determinista, no has enviado un agente libre de bugs — simplemente has escrito un sistema para un humano que una IA ahora intenta navegar.”

El choque de rendimiento de la arquitectura heredada

Uno de los primeros lugares donde la arquitectura centrada en humanos se rompe es en la capa de base de datos. En un entorno SaaS tradicional, los sistemas a menudo rastrean metadatos como un timestamp de “última visita” o “última actividad” para cada usuario. Para un humano, esto podría actualizarse cada pocos minutos durante una sesión activa.

Sin embargo, cuando los agentes comienzan a golpear estas mismas APIs, las matemáticas cambian. La investigación en plataformas de identidad y autenticación ha demostrado que los agentes pueden disparar estas actualizaciones hasta 60 veces más rápido que un humano. Esto crea picos de latencia rítmicos y artificiales en los sistemas de escritura de base de datos.

Esto no es solo sobre velocidad; es sobre la suposición de la naturaleza del actor. Los agentes no se cansan, no toman descansos para leer la pantalla, y pueden paralelizar tareas de formas que un usuario humano en un navegador nunca podría. Arreglar esto requiere un cambio arquitectónico que reconozca a los agentes como una clase distinta de actor con diferentes patrones de consumo de recursos.

Por qué OAuth y los alcances amplios son un riesgo de seguridad

Durante la última década, OAuth ha sido el estándar de oro para la autorización delegada. Funciona bien cuando un humano concede permiso a una aplicación específica para “Leer tus correos” o “Acceder a tu calendario”. Pero OAuth fue diseñado para programas deterministas. Cuando un desarrollador escribe una integración tradicional, el código es estático. Puedes revisar el código, verificar exactamente qué endpoints de API toca, y sentirte confiado de que el programa se mantendrá en su carril.

Los agentes de IA rompen la suposición de determinismo. Un agente impulsado por un Modelo de Lenguaje Grande (LLM) es probabilístico. No puedes revisar el “código” del proceso de razonamiento de un agente porque cambia con cada prompt y cada bit de contexto que recibe. Darle a un agente un alcance OAuth amplio — como la capacidad de enviar correos electrónicos en nombre de un usuario — es increíblemente peligroso porque el agente podría decidir, basado en un prompt malinterpretado, enviar un correo a toda tu lista de clientes.

La mayoría de los sistemas existentes no permiten el alcance detallado a nivel de atributos que los agentes requieren. Por ejemplo, un alcance centrado en humanos podría ser gmail.send. Un alcance nativo para agentes necesita ser mucho más específico: “Este agente puede enviar correos solo a estos tres destinatarios, solo entre las 9:00 AM y las 5:00 PM, y solo si el cuerpo contiene un ID de proyecto específico.”

El problema del principal versus el actor

En el diseño centrado en humanos, la identidad que se autentica es casi siempre la identidad que actúa. Inicias sesión con tus credenciales, y el sistema trata tus acciones como tuyas. Con los agentes, esta relación se fractura. El agente es el actor, pero el usuario es el principal.

Muchas implementaciones actuales resuelven esto haciendo que el agente “actúe como” el usuario. Este es el peor camino posible para la gobernanza. Cuando un agente usa el token de sesión o la API key de un usuario, el registro de auditoría simplemente muestra que el usuario realizó la acción. No hay distinción en los registros entre un VP de Ventas actualizando manualmente un registro y un agente autónomo haciéndolo a las 3:00 AM.

Para resolver esto, los agentes necesitan su propia identidad soberana — una identidad que está permanentemente vinculada al principal pero sigue siendo independientemente auditable. Esto permite un modelo “en nombre de” donde cada acción en el sistema se registra con contexto completo:

  • ¿Quién tomó la acción? (El ID del Agente)
  • ¿En nombre de quién? (El ID del Usuario)
  • ¿Quién autorizó la sesión? (El Administrador o Principal)
  • ¿Por cuánto tiempo fue válida la autorización? (TTL - Tiempo de Vida)

“Sin este nivel de visibilidad, solucionar un ‘agente deshonesto’ se convierte en una tarea forense imposible. No puedes revocar el acceso del agente sin también bloquear al usuario de su propia cuenta.”

Guardarraíles deterministas para actores no deterministas

Si los agentes son inherentemente no deterministas, la arquitectura que los rodea debe ser lo opuesto. No podemos controlar la naturaleza probabilística de cómo piensa un LLM, pero podemos controlar el entorno en el que opera.

Hay tres niveles de alcance que deben implementarse:

1. Alcance a nivel de atributos

Restringir al agente a campos específicos dentro de un registro en lugar del objeto completo. Un agente debería poder actualizar un “Estado de Lead” sin tener permiso para ver el “Valor del Contrato”.

2. Alcance a nivel de contexto

Restringir acciones basadas en factores ambientales como hora, dirección IP o la presencia de un humano en el circuito de aprobación.

3. Autorización justo a tiempo

En lugar de otorgar permisos amplios permanentes, el agente debería existir en un estado de “mínimo privilegio” por defecto. Si necesita realizar una acción elevada, debe solicitar una credencial temporal de corta duración para esa tarea específica.

Ya hemos visto incidentes del mundo real donde agentes de codificación u operaciones han eliminado datos de producción porque se les dio demasiado contexto y demasiados permisos. En muchos casos, el agente simplemente estaba tratando de ser “útil” limpiando lo que percibía como registros redundantes. El desarrollador no envió un bug; simplemente proporcionó a un agente un conjunto de permisos de tamaño humano sin límites adaptados a máquinas.

La visibilidad no es una característica opcional

Para CTOs y campeones internos de IA, el mayor obstáculo para la adopción generalizada de agentes es a menudo la revisión de adquisiciones y seguridad. Los equipos de seguridad tradicionales están, con razón, aterrorizados por los agentes de “caja negra” que tienen acceso de escritura a bases de datos centrales.

Una arquitectura nativa para agentes debe proporcionar un rastro de auditoría determinista. Esto no es solo un registro de llamadas API; es un registro de la cadena de razonamiento. ¿Por qué el agente eligió esta herramienta? ¿Qué autorización tenía en ese milisegundo exacto? ¿Cuándo se concedió esa autorización?

La infraestructura nativa para agentes transforma al agente de un experimento riesgoso a infraestructura empresarial gobernada — una capa operativa que se sienta entre el LLM y tus datos, aplicando RBAC (Control de Acceso Basado en Roles), auditabilidad y permisos por agente.

Del diseño humano al nativo para agentes: el camino a seguir

La transición de la arquitectura centrada en humanos a la arquitectura nativa para agentes es el desafío definitorio para los líderes de operaciones en los próximos 24 meses. Las organizaciones que dependen de API keys amplias y la “esperanza” de que sus agentes se mantengan dentro de los límites previstos están asumiendo un riesgo innecesario.

“Arquitecturar con guardarraíles deterministas — separación de identidad soberana, alcance a nivel de atributos y autorización justo a tiempo — permite a las empresas cosechar las recompensas del trabajo autónomo sin sacrificar soberanía o seguridad.”

Al pasar de “actuar como” a un modelo gobernado de “en nombre de”, las empresas pueden finalmente moverse más allá de la fase piloto y entrar en una verdadera transformación operativa. Después de todo, cuando se trata de la seguridad de tus datos de producción y la integridad de tus registros de clientes, rezar no es una estrategia.

Puntos clave:

  • Las APIs tradicionales asumen un actor humano — velocidad predecible, comportamiento determinista e identidad basada en sesión. Los agentes rompen las tres suposiciones.
  • OAuth es insuficiente — fue diseñado para programas deterministas, no para agentes probabilísticos cuyo razonamiento cambia con cada prompt.
  • Los agentes necesitan identidad soberana — separada de las credenciales del usuario, con auditoría completa de quién actuó, en nombre de quién, y con qué autorización.
  • Tres niveles de alcance — a nivel de atributos, a nivel de contexto y autorización justo a tiempo — son necesarios para la gobernanza de agentes en producción.
  • La visibilidad no es opcional — un rastro de auditoría determinista que incluya la cadena de razonamiento es esencial para la adopción empresarial.

Sigue explorando estos temas en el blog de DojoFullStack. La arquitectura de sistemas autónomos es el futuro del desarrollo de software — y en nuestro blog desglosamos estos conceptos para que puedas implementarlos en tus proyectos.