Control de acceso para agentes de IA: privilegio mínimo para cada agente

¿Qué es el control de acceso para agentes de IA?

El control de acceso para agentes de IA es el conjunto de políticas que decide si un emisor determinado puede acceder a un recurso específico. Responde a la pregunta "¿está permitido?", mientras que los guardrails responden a "¿qué contiene?".

Vale la pena tener clara esta distinción, ya que ambos controles fallan de formas distintas y es necesario contar con ambos.

• Control de acceso es el portero en la entrada. Comprueba si este agente, usuario o equipo tiene permiso para llamar a este modelo o a esta herramienta MCP en absoluto.
• Los guardrails son el detector de metales. Una vez que se permite el paso de una llamada, inspeccionan el prompt, la salida y los argumentos de la herramienta en busca de inyecciones, información de identificación personal (PII), secretos u operaciones inseguras.

Un agente puede estar totalmente autorizado para llamar a su servidor MCP de base de datos y, aun así, ser engañado para enviar una consulta destructiva. El control de acceso dio el visto bueno al servidor, y solo un guardrail en los argumentos detecta lo que la consulta hace realmente. Sin embargo, si el acceso es demasiado amplio, dependerá totalmente del detector de metales. El principio de menor privilegio es lo que mantiene reducido el número de llamadas permitidas desde el principio.

Los dos niveles de control de acceso en TrueFoundry

TrueFoundry aplica el acceso en dos niveles, y comprender esta división es la mayor parte del trabajo.

Roles a nivel de recurso (colaboradores)

Se añade un usuario, equipo o cuenta virtual como colaborador directamente en un recurso y se selecciona un rol que limite su acceso únicamente a ese recurso. Los roles son específicos para cada tipo de recurso:

Aquí es donde reside el principio de menor privilegio. Conceda a un agente acceso de agente solo a los servidores MCP que necesite para su trabajo, asigne a un equipo el rol de usuario en la cuenta del modelo al que tiene permiso para llamar y añada un aprobador de servidor MCP cuando una herramienta requiera autorización antes de ejecutarse. No es necesario crear roles personalizados para nada de esto.

Roles a nivel de inquilino (tenant)

Los roles a nivel de inquilino se aplican a todo el inquilino y se configuran en Acceso, y luego en Roles. Gobiernan acciones en todo el inquilino, como la creación de recursos, la gestión de usuarios y la enumeración de todos los recursos de un tipo. TrueFoundry incluye dos: Administrador, que tiene control total y debe limitarse a un pequeño grupo de personas, y Miembro, que por defecto no tiene acceso a nada y al que se le debe conceder acceso a los recursos de forma explícita. Cuando esas dos opciones son demasiado amplias o demasiado limitadas, puedes crear un rol personalizado.

‍

Los roles pueden asignarse tanto a equipos como a usuarios individuales, y los permisos efectivos de un usuario son la suma de su propio rol y de todos los roles heredados de sus equipos. Para las organizaciones que sincronizan grupos de identidad mediante SCIM, esos grupos se integran como equipos de TrueFoundry y pueden recibir roles directamente, por lo que el acceso sigue la misma fuente de verdad que ya gestiona tu IdP.

Cómo funciona el control de acceso para herramientas MCP

La puerta de enlace MCP separa tres aspectos que los equipos suelen mezclar, y mantenerlos diferenciados es lo que hace que el principio de menor privilegio a nivel de herramienta sea práctico.

Capa

Qué controla

Autenticación de entrada

Cómo se autentica un llamador (agente, desarrollador, aplicación) en la puerta de enlace mediante un token de acceso

Control de acceso

Qué usuarios, equipos o agentes pueden utilizar qué servidores MCP y qué herramientas específicas

Autenticación de salida

Cómo se autentica la puerta de enlace ante el servidor MCP descendente

‍

Captura de pantalla del producto, documentación de TrueFoundry: autenticación y autorización de la puerta de enlace MCP.

‍

La parte importante para los agentes es la capa intermedia. Las reglas de acceso pueden restringirse hasta el nivel de herramientas individuales dentro de un servidor, de modo que puedes conceder a un agente la herramienta de solo lectura ask_question de un servidor de base de datos, mientras le deniegas la herramienta que escribe en ella. Dado que la puerta de enlace se sitúa delante de cada llamada, la misma regla cubre a todos los que invocan esa herramienta, incluidos los agentes, sin necesidad de volver a implementar nada por cada agente.

Aplicación práctica del principio de menor privilegio

El principio de menor privilegio es menos una funcionalidad y más un hábito que la puerta de enlace facilita mantener. Unos pocos patrones aportan la mayor parte del valor.

‍

• Una identidad por carga de trabajo, con un alcance limitado. Asigna a cada aplicación su propia cuenta virtual y a cada agente su propia identidad de agente, y luego concede a cada una solo las cuentas de modelo y las herramientas MCP que realmente utiliza. Las credenciales compartidas y de amplio alcance son las que aumentan el radio de impacto.
• Limita los agentes a su función, no a la de quien los controla. Un agente de atención al cliente debería tener acceso a las herramientas de soporte y a nada relacionado con registros financieros o puntos de conexión administrativos, incluso si la persona que lo ejecuta tiene permisos más amplios. Los permisos a nivel de agente hacen que esa separación sea real.
• Utiliza roles de aprobador para herramientas sensibles. El rol de aprobador del servidor MCP permite la intervención humana antes de ejecutar herramientas de alto impacto, lo cual suele ser más seguro que una política rígida de permitir o denegar.
• Prioriza los equipos sobre los permisos por usuario. Asigna roles a un equipo una sola vez y gestiona sus miembros; así, el acceso permanece claro a medida que las personas y los agentes se incorporan o se van.

‍

Para una autorización que dependa del contexto de la solicitud en lugar de un rol estático, la pasarela admite directrices de política como código utilizando CedaryOPA en el gancho previo a la herramienta. Esto permite definir reglas detalladas, por ejemplo, permitir una llamada a una herramienta solo cuando los metadatos de la solicitud indiquen que se trata de un entorno que no es de producción. En producción, las aplicaciones se autentican con un token de cuenta virtual limitado en lugar de uno personal, y pueden etiquetar cada llamada con metadatos que las políticas puedan leer:

‍

curl https://gateway.truefoundry.ai/api/llm/chat/completions \

  -H "Authorization: Bearer $VIRTUAL_ACCOUNT_TOKEN" \

  -H 'X-TFY-METADATA: {"environment":"production","team":"support"}' \

-H "Content-Type: application/json" \

  -d '{ "model": "openai-main/gpt-4o", "messages": [ ... ] }'

‍

‍

::: BANNER CRO ::: Limita cada agente estrictamente a lo que necesita. TrueFoundry aplica el control de acceso basado en roles a modelos y herramientas MCP en la pasarela, dentro de tu propia VPC. CTA: Reservar una demo → /book-demo :::::::::::::::::::

Por qué aplicar el acceso de agentes en la pasarela

Podrías intentar integrar estas comprobaciones en cada agente, pero la razón para no hacerlo es la cobertura. Cuando el acceso se aplica en la pasarela, cualquier agente nuevo que llame a un modelo o servidor MCP ya regulado hereda sus reglas de acceso automáticamente, sin necesidad de añadir nada al código del agente. Los agentes creados con LangGraph, CrewAI, AutoGen o un bucle personalizado se dirigen a través del mismo plano de control y reciben las mismas políticas.

‍

Además, mantiene las decisiones de acceso donde pueden ser auditadas. Cada llamada lleva consigo la identidad de quien la realiza y el recurso al que accede, por lo que puede responder a la pregunta de «qué agentes pueden utilizar esta herramienta» desde un único lugar, en lugar de tener que revisar una docena de repositorios. Control de acceso, identidad de agente, ybarreras de seguridad y luego se integran en una ruta de llamada gobernada: la identidad indica quién realiza la llamada, el control de acceso determina si está permitida y las directrices de seguridad inspeccionan su contenido. La pasarela solo añade unos pocos milisegundos de latencia, por lo que incluir los tres elementos en la ruta crítica no ralentiza a los agentes.

‍

El resultado es un control de acceso que funciona como infraestructura. Se aplica de forma uniforme, es gestionado por el equipo de plataforma y se ejecuta dentro de su propia cuenta de AWS, GCP o Azure, lo que hace que las auditorías de SOC 2, HIPAA y RGPD sean mucho más sencillas de gestionar.

‍