.png)
November 6, 2026
|
5 minutos de lectura
Gobernanza de agentes de IA: los cinco pilares que se construyen, no se redactan
.png)
Diseñado para la velocidad: ~ 10 ms de latencia, incluso bajo carga
¡Una forma increíblemente rápida de crear, rastrear e implementar sus modelos!
- Gestiona más de 350 RPS en solo 1 vCPU, sin necesidad de ajustes
- Listo para la producción con soporte empresarial completo
Qué se está gobernando realmente con los agentes
Jane, una ingeniera de soporte, escribe una frase en un copiloto de soporte: prepara un resumen de reembolso para el ticket #4521. El copiloto se lo pasa a un agente planificador, que llama a un agente de investigación (ticket de Zendesk, error de Jira vinculado) y a un agente de facturación (registro de pago de Stripe). Una sola solicitud humana genera seis llamadas máquina a máquina, la mayoría realizadas por software que decidió por su cuenta llamar a más software.
Esa cadena (usuario → aplicación → agente → subagente → herramienta MCP) es la ruta de llamadas de agentes, y es lo que la gobernanza de agentes debe controlar. Todo modelo de acceso empresarial se basa en tres supuestos: un usuario está al frente de la solicitud, lo que realiza la llamada es ese usuario y el alcance es aquello que el usuario consintió. Al llegar al tercer salto, los tres supuestos son falsos, por lo que tres preguntas dejan de tener respuesta:
- ¿Para quién es esta llamada? El usuario se autenticó tres saltos atrás. ¿Sigue su identidad en la solicitud o la reemplazó una cuenta de servicio?
- ¿Quién la está realizando? Un token de portador (bearer token) demuestra la posesión de una credencial, no cuál de sus doscientos agentes la sostiene.
- ¿Qué tiene permitido hacer? Un token emitido para el primer destinatario de la llamada tiene privilegios excesivos para cada destinatario posterior.
Responder a estas tres preguntas en cada salto con pruebas evidencia es lo que significa la gobernanza de IA basada en agentes: cinco sistemas, no un párrafo sobre uso responsable.
El agente es un tercer tipo de entidad (principal)
La mayoría de los equipos recurren a uno de dos atajos: permitir que el agente reenvíe el token del usuario o darle una cuenta de servicio compartida. Ambos son incorrectos, porque un agente no es ninguna de las dos cosas.
Dar a cada agente su propia identidad verificable es la decisión de la que depende todo lo demás. Permite obtener atribución, porque el receptor puede saber qué agente llamó; política por agente, porque el copiloto de Jane que lee Jira y su agente de ingeniería que escribe en él son entidades diferentes aunque ambos actúen en nombre de Jane; y ausencia de agentes anónimos, porque una herramienta a la que solo se puede acceder mediante una identidad registrada convierte al registro en el punto de aplicación de políticas.
La urgencia no es glamurosa: las identidades de máquinas ya superan en número a los usuarios humanos en la mayoría de las empresas por más de 40 a 1, y los agentes se multiplican más rápido de lo que lo hicieron las cuentas de servicio: cualquiera con un framework y una API key puede crear uno.
Los cinco pilares
La gobernanza completa consta de cinco capacidades en bucle. Las dos primeras se ejecutan antes de que un agente realice una sola llamada, las dos intermedias en cada llamada y la última de forma continua, retroalimentando a la segunda.
El Pilar 4 es donde la gobernanza entra en contacto con la infraestructura técnica. En cada salto, el gateway resuelve al emisor, comprueba si este agente puede llamar a este objetivo y actuar en nombre de este usuario, emite un nuevo token limitado exactamente al siguiente destinatario, ejecuta barreras de protección (guardrails), reenvió y registra. Tres propiedades se obtienen de forma directa: atribución por salto, tokens de mínimo privilegio (uno filtrado solo sirve para un destinatario y un alcance) y revocación centralizada.
Por qué el gateway y no el IdP
Cada pilar podría residir en una herramienta diferente. Lo que mantiene unido al modelo es la aplicación de políticas en un gateway en la ruta de la llamada: el único componente que ve cada salto independientemente del framework o la nube, transmite la identidad hacia adelante, reduce la autoridad en cada paso y es neutral con respecto a la plataforma. Entra gobierna los agentes de Entra, Okta gobierna las aplicaciones de Okta, Bedrock gobierna los agentes de Bedrock; el gateway gobierna la ruta a través de todos ellos, que es donde reside el riesgo, un punto que desarrollamos en governing AI agents across multiple platforms. Un proveedor de identidad sin un gateway emite credenciales perfectas que luego se reenvían de forma promiscua; un registro sin un gateway es mera documentación.
Dónde se equivocan los equipos
Tratar el registro como una hoja de cálculo. Un registro que los agentes pueden ignorar solo inventaría los agentes que ya se conocían. Tiene efectividad cuando actúa como punto de control obligatorio: sin identidad registrada, no hay llamada.
Reenviar un token potente a todas partes. La forma más rápida de hacer que las llamadas funcionen y la ruta más rápida hacia una brecha de seguridad. Los agentes pueden ser manipulados mediante prompt injection para hacer un uso indebido de cualquier credencial que posean, por lo que esta nunca debe ser más amplia de lo que requiere la siguiente llamada.
Revisar cuentas en lugar de cadenas. Tres agentes en un flujo de compras (uno crea registros de proveedores, uno lee datos bancarios de proveedores y otro inicia pagos) parecen aceptables de forma individual. Encadenados, forman una ruta de pago que ningún revisor habría aprobado: una separación de funciones recreada por software.
Asumir que el alcance de un agente es estático. Un agente de finanzas al que se le concede un nuevo módulo ERP puede comenzar a actuar sobre datos que su alcance nunca cubrió, no por un defecto, sino porque adaptarse es lo que hacen los agentes. El comportamiento debe compararse con la autoridad definida de forma continua, no trimestralmente.
La parte difícil: dos respuestas a "¿quién hizo esto?"
Cuando el agente de investigación lee los tickets de Jira de Jane, la respuesta honesta a quién hizo esto es tanto Jane como el agente de investigación. Omita cualquiera de los dos y perderá información real. Hay dos formas de incluir esto en un token, y la elección determina si se dispone de un rastro de auditoría válido.
Para los agentes, casi siempre se requiere delegación. El token delegado mantiene al usuario como sub y nombra al actor en act; las llamadas encadenadas anidan las notificaciones (claims), siendo la más externa el actor más reciente:
Dos notificaciones complementarias se reparten el trabajo. may_act es el control orientado al futuro (¿puede este actor actuar en nombre de este sujeto?), que se comprueba antes de emitir el token. act registra quién actuó realmente. Se debe autorizar en función del actor actual más el sujeto y la política; mantenga la cadena anidada para análisis forenses.
El mecanismo subyacente es el intercambio de tokens. El RFC 8693 lo define: presente un token de sujeto y opcionalmente un token de actor, y reciba un nuevo token limitado a una audiencia objetivo. Los proveedores lo denominan On-Behalf-Of (en nombre de). Vale la pena memorizar una propiedad: un intercambio nunca amplía la autoridad. El token emitido concede la intersección de lo que el usuario puede hacer, lo que el agente puede hacer y lo que el objetivo acepta, por lo que cada salto está más restringido que el anterior. Entre dominios de confianza, la concesión ID-JAG del IETF (Cross App Access de Okta) toma el control, emitiendo una concesión de corta duración en su IdP que el propio servidor de autorización del objetivo canjea.
Cómo funciona esto en TrueFoundry
TrueFoundry mapea los cinco pilares en componentes del producto. Ser claro sobre lo que existe hoy en día importa más que presentar una tabla aparentemente completa, por lo que la disponibilidad se indica con transparencia.
El registro
Cada agente obtiene una entrada, independientemente de dónde se ejecute: Bedrock, Vertex, LangGraph, un servicio HTTP personalizado, un agente A2A o un copiloto en el SaaS de un tercero. Nada se desplaza, nada se reescribe.
El registro es un asistente de cuatro pasos: Metadata, Agent Identity, Config y Access Control.
Identidad
El paso dos determina cómo el agente demuestra quién es. Respaldado por TrueFoundry significa que TrueFoundry emite y firma el token, la opción predeterminada adecuada para los agentes que ejecuta usted mismo. Respaldado por proveedor de identidad significa que el agente presenta un token de Okta, Entra, cualquier proveedor OIDC o un punto de enlace SPIFFE/SPIRE, con valores de notificaciones (claims) mapeados al agente.
El paso de Config determina si el Agent Gateway se sitúa en la parte frontal. Proxy via Gateway significa que las emisores de llamadas acceden a una URL de TrueFoundry y el gateway autentica, aplica políticas y reenvía. Embedded significa solo gobernanza: una identidad y concesiones, sin proxy entrante. Así es como se gobierna un copiloto dentro de un producto de terceros: no puede controlar su entrada principal, pero sus llamadas salientes siguen pasando por sus gateways.
Control de acceso de agentes
El acceso se basa en listas de permitidos (allow-lists); no existe una configuración de denegación implícita, porque la ausencia de permiso constituye la denegación. Los colaboradores pueden ser un usuario, un equipo u otro agente, con roles de Agent Manager (ver y editar) o Agent Access (invocar y permitir que actúe en su nombre). El propietario (Owner) es un campo opcional independiente que debe ser un equipo: el punto ancla de la responsabilidad.
Tenga en cuenta lo que hace esa lista: define tanto quién puede llamar al agente como en nombre de quién puede actuar el agente. Concederlo al equipo integrado "everyone" otorga al agente un alcance de delegación para todo el tenant, más amplio de lo que la mayoría de los agentes necesitan.
La otra dirección funciona de forma idéntica: añada el agente como colaborador en cada servidor MCP o modelo, sujeto agent:<name>, en el mismo selector que los usuarios y equipos.
Para restringir un agente a un subconjunto de herramientas de un servidor, configure ese subconjunto como un Virtual MCP Server y concédale acceso a este en su lugar; la delimitación de herramientas por agente en la concesión estará disponible próximamente.
Barreras de protección (guardrails) en cada salto
El control de acceso determina si se produce una llamada. Las barreras de protección (guardrails) determinan qué puede contener y son indiferentes a quién realiza la llamada. Los agentes aumentan el riesgo por una razón: un chatbot con una respuesta incorrecta resulta embarazoso; un agente con una respuesta incorrecta actúa en consecuencia. Cada resultado de una herramienta vuelve a entrar en el contexto del modelo y puede transportar una inyección, por lo que las entradas deben verificarse incluso cuando el usuario sea de confianza.
Una línea base práctica: redacción de PII y detección de prompt-injection en la entrada del LLM, detección de secretos en la salida, desinfectador de SQL y linter de seguridad de código antes de la herramienta, y redacción posterior a la herramienta. Inicie cada regla en modo Audit y luego promuévala: un salto bloqueado puede hacer fallar una cadena completa.
Auditoría
Dado que la aplicación de políticas y la observación ocurren en el mismo lugar, el rastro es completo por diseño. Cada traza registra qué agente realizó la llamada y en nombre de qué usuario actuó: las dos partes del problema de las dos respuestas.
Cada guardrail ejecutado aparece como su propio span: qué verificó, si pasó, qué encontró o redactó. Las solicitudes bloqueadas también se registran: un salto denegado es una prueba, no un vacío de información.
Por encima de las trazas, un panel de control único cubre cada agente registrado independientemente de dónde se ejecute: recuento de solicitudes, percentiles de latencia, tasas de error y uso a lo largo del tiempo. La detección de desviaciones (drift) y las alertas de anomalías se basan en esto y estarán disponibles próximamente.
Un ejemplo práctico
Gobernar el copiloto de resumen de reembolsos del inicio de este artículo.
Registrar los agentes. Los agentes planificador, de investigación y de facturación reciben una entrada con una descripción y un equipo Owner. El copiloto del proveedor se registra como Embedded: sin URL, solo gobernanza, pero sus llamadas salientes ahora están gobernadas.
Asignar una identidad a cada uno. Respaldada por TrueFoundry para los tres que ejecuta usted mismo; el copiloto embebido apunta a su IdP, con el valor de la notificación (claim) mapeado.
Conceder el mínimo privilegio en ambas direcciones. En el agente de investigación, añada el equipo de soporte con Agent Access: tanto quién puede me invocarlo como en nombre de quién puede actuar. Luego añada agent:research-agent como colaborador en los servidores MCP de Zendesk y Jira, y en ninguno más. El de facturación obtiene Stripe. Ninguno accede a las herramientas del otro, porque la ausencia de concesión devuelve un 403.
Transmitir la identidad en cada llamada. Una llamada delegada lleva dos bearer tokens: el usuario en Authorization y el agente en x-tfy-agent-authorization. Cada agente intercambia su propia cabecera de agente y pasa el token del usuario a través de ella, de modo que el gateway comprueba cada salto con respecto al agente que realmente lo realiza.
Activar barreras de protección (guardrails) y supervisar. Adjunte detección de prompt-injection a los modelos y redacción posterior a la herramienta a los servidores, luego confirme en Request Traces que una llamada de research-agent muestra a research-agent como emisor y a Jane como el usuario en cuyo nombre actuó.
Una limitación real: hoy en día, el token del usuario pasa a través junto a la cabecera del agente en lugar de ser intercambiado por un nuevo token limitado a la audiencia objetivo en cada salto. El intercambio completo por salto estará disponible próximamente.
Aspectos clave a tener en cuenta
Un agente no puede completar un flujo de código de autorización de OAuth2. No hay un humano para aprobar la pantalla de consentimiento y el token pertenecería a esa persona de todos modos. Dicho servidor devuelve MCP server authentication required para un token de agente incluso cuando el agente es un colaborador. Utilice credenciales de cliente (client credentials) en su lugar.
Los guardrails de salida se omiten en respuestas en streaming. Necesitan la respuesta completa para evaluar, por lo que para los pasos del agente cuya salida alimenta la llamada a una herramienta, es preferible utilizar stream: false.
El token del agente es el agente. Manténgalo fuera del control de versiones y de cualquier elemento que el modelo pueda leer. Un agente al que se le puede manipular mediante prompts para que revele su propio token puede ser suplantado.
Lecturas relacionadas
- Governing AI Agents Across Multiple Platforms: cuando la gobernanza se detiene en el límite de la plataforma
- Graph Engineering for AI Agents: evaluación del nodo frente a la gobernanza de las conexiones
- MCP Access Control with an MCP Gateway: permisos a nivel de herramienta y de servidor
- RBAC vs ABAC for AI Agents: el modelo de acceso subyacente a las concesiones
- Building an AI Governance Framework: el marco general de políticas
Conclusión
La mayoría de los escritos sobre la gestión de agentes de IA en la empresa tratan la gobernanza como un ejercicio de redacción: definir el uso aceptable, asignar un comité, publicar la norma. Nada de esto sobrevive al tercer salto de una ruta de llamada, donde la pregunta no es si una acción fue adecuada, sino si su infraestructura puede determinar quién la realizó.
Los cinco pilares son útiles precisamente porque cada uno nombra un sistema en lugar de un principio. El descubrimiento es un escáner. El registro es una base de datos que el gateway se niega a omitir. La autenticación consiste en dos credenciales en una solicitud. La autorización es una concesión que devuelve un 403 cuando no existe. La auditoría es una traza en la que figuran tanto el agente como el usuario. Construya esos sistemas y la pregunta difícil (quién hizo esto y en nombre de quién) tendrá una respuesta comprobable.
TrueFoundry AI Gateway ofrece una latencia de entre 3 y 4 ms, gestiona más de 350 RPS en una vCPU, se escala horizontalmente con facilidad y está listo para la producción, mientras que LitellM presenta una latencia alta, tiene dificultades para superar un RPS moderado, carece de escalado integrado y es ideal para cargas de trabajo ligeras o de prototipos.
Diseñado para la velocidad: ~ 10 ms de latencia, incluso bajo carga
Try now.
Inscríbase
¿Cómo se puede evitar que los costos de GenAI se disparen a gran escala?
Gartner Hype Cycle for Platform Engineering 2026
One Layer of Control for All AI
Tabla de contenido
Controle, implemente y rastree la IA en su propia infraestructura
Summarize with
Descubra más
No se ha encontrado ningún artículo.
.png)
.png)
.png)
No se ha encontrado ningún artículo.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.webp)
.webp)
.png)
.png)
Preguntas frecuentes
¿Qué es la gobernanza de agentes de IA?
El conjunto de controles que permiten responder a cinco preguntas sobre cada agente en cualquier momento: qué agentes existen, quién es responsable, a qué puede acceder cada uno, en nombre de quién actúa y qué hizo realmente. En la práctica: un registro, una identidad por agente, permisos de mínimo privilegio por destino, delegación que mantiene al usuario a lo largo de los saltos y una pista de auditoría por salto con un interruptor de emergencia.
¿En qué se diferencia la gobernanza de agentes de la gobernanza de cuentas de servicio?
Una cuenta de servicio hace lo que dice su configuración y se revisa de forma periódica. Un agente interpreta un objetivo, elige sus propias herramientas y encadena llamadas, de modo que su comportamiento se desvía de su autoridad definida entre una revisión y otra. La gobernanza de agentes añade reglas de delegación, atribución por salto de la cadena de actores y comparación continua del comportamiento con el alcance declarado.
¿Necesito un registro de agentes de IA si mi proveedor de identidad ya emite identidades de agente?
Sí, si sus agentes cruzan plataformas. Entra gobierna los agentes de Entra, Okta gobierna las aplicaciones de Okta, Bedrock gobierna los agentes de Bedrock, y ninguno gobierna un agente que empieza en uno y llama a otro. Un registro junto con un gateway ofrece un único inventario y un único punto de aplicación para todos ellos.
¿Puedo desplegar TrueFoundry en mi propia VPC o en on-prem?
Sí. TrueFoundry se ejecuta en su VPC, on-prem, en entornos air-gapped o híbridos, de modo que los prompts y las respuestas nunca salen de su dominio, incluso cuando enruta entre muchos proveedores.
¿Admite TrueFoundry MCP y agentes de IA en general?
Sí. Incluye un MCP Gateway, un Agent Gateway y un MCP & Agents Registry con control de acceso a nivel de herramienta. Los agentes creados con LangGraph, CrewAI, AutoGen o un framework propio pueden gobernarse de forma centralizada.
¿Se integra con mi pila de observabilidad existente?
Sí. La pasarela es compatible con OpenTelemetry y se integra con Grafana, Datadog, Prometheus o tu pila preferida. Rastrea cada solicitud desde la instrucción (prompt) hasta la ejecución de la herramienta y el modelo, así obtienes un registro unificado sin tener que reemplazar lo que ya tienes en funcionamiento.
