Mínimo privilegio para los agentes de IA en un SaaS multiinquilino

Un atajo de prototipo frecuente consiste en proporcionar a un agente un token, exponer todas las herramientas y limitar su comportamiento mediante un prompt. Eso facilita la demostración. En producción genera un problema: la intención escrita en los prompts se convierte en la principal barrera entre un error del modelo y la plena capacidad de la cuenta.

El menor privilegio para un agente no termina con un rol de solo‑lectura. Como mínimo, debemos limitar cinco cosas: herramientas, tipo de operación, recursos objetivo, datos y la duración/identidad del acceso.

1. Limitar el conjunto de herramientas

Un agente que analiza el rendimiento publicitario no necesita funciones de gestión de usuarios. Un agente que prepara un informe de cumplimiento no necesita acceso ilimitado a la línea de comandos. Un agente que organiza archivos en un directorio no necesita todo el sistema de archivos.

Cuanto más amplio sea el catálogo de herramientas, mayor será la superficie de riesgo para:

• seleccionar la herramienta equivocada;
• inyección de prompt que conduzca a una acción no deseada;
• combinaciones inesperadas de herramientas;
• exposición accidental de datos;
• errores de configuración en la capa del modelo.

Por lo tanto, la primera pregunta no debería ser “¿qué puede hacer esta API?” sino:

¿qué tres o cinco operaciones necesita este agente para este trabajo específico?

Todo lo demás puede permanecer invisible.

2. Separar lectura, escritura, efecto operativo y destrucción

“Tiene acceso a campañas” es demasiado amplio.

Para nuestras herramientas, un modelo de operación resulta más útil:

Alcance	Significado	Ejemplo
read	recuperar estado e informes	obtener gasto, estado o lista de recursos
write	preparar o modificar configuración	crear borrador, renombrar, cambiar un parámetro
operate	activar una consecuencia de negocio	habilitar una campaña, publicar, iniciar sincronización
destructive	eliminar, desvincular o revocar	borrar un recurso, eliminar acceso, efectuar un cambio difícil de revertir

Un agente puede preparar una configuración sin permiso para activarla. Puede leer facturación sin cambiar la configuración de pago. Puede redactar un mensaje sin permiso para enviarlo.

Ese límite es a menudo donde reside la autonomía útil.

3. El alcance de la herramienta no basta — también hay que limitar el recurso

Un permiso como:

campaign.write

sigue siendo amplio si un operador tiene diez cuentas pero el agente solo debe trabajar en una.

Cuando sea práctico, la autorización debe considerar:

La decisión de autorización incluye al usuario, agente, función, tipo de operación, inquilino/cuenta/proyecto, recurso y contexto de la tarea.

quién
+ cuál agente
+ cuál función
+ cuál tipo de operación
+ cuál inquilino/cuenta/proyecto
+ cuál recurso
+ cuál contexto de tarea

Nuestro MCP interno de Brillnet Ads requiere identificadores explícitos de cuenta/cliente dentro de un límite permitido. Una consulta general no debe simplemente adivinar en qué cuenta operar.

Esto es particularmente importante en SaaS multi‑inquilino. Seleccionar el inquilino equivocado puede ser más grave que un error de razonamiento dentro del modelo mismo.

4. Limitar los datos de entrada y salida

El menor privilegio también se aplica a los datos.

Un agente puede necesitar:

• gasto agregado, no la lista completa de datos de usuarios;
• estado de la tarea, no cada archivo adjunto;
• confirmación de que una credencial existe, no su valor;
• un identificador de persona, no su perfil completo;
• campos seleccionados de un documento, no todo el repositorio.

Si una herramienta puede devolver un objeto mínimo, devuelva el objeto mínimo. No exponga una carga completa del proveedor al modelo solo porque la API lo permite.

El mismo principio se aplica a los registros: una pista de auditoría debe contener la evidencia suficiente, no una duplicación de todos los datos de origen.

Leer: Pistas de auditoría de agentes de IA

5. Una credencial no debe vivir más tiempo ni más amplio de lo necesario

Un token de administrador de larga duración colocado en el entorno de cada componente es fácil de configurar. También es difícil de limitar de forma segura.

Preferimos un patrón más cercano a:

1. El agente no recibe el secreto.
2. La puerta de enlace verifica identidad, alcance y recurso.
3. Obtiene una credencial de corta duración.
4. Realiza una llamada al proveedor permitida.
5. El secreto nunca entra en la respuesta del modelo ni en el registro de auditoría.

Según su documentación, nuestro MCP interno de Ads obtiene tokens de proveedor de corta duración en el momento de la llamada. El material de credencial se maneja fuera del contexto del modelo y no se escribe en los registros de la aplicación.

Verificar el permiso en tiempo de ejecución

Un agente puede haber iniciado una tarea mientras el operador tenía cierto rol. Diez minutos después, ese rol puede haber sido revocado. Un flujo de trabajo largo no debe asumir que el permiso del inicio de la sesión sigue vigente.

Para operaciones materiales, la autorización se comprueba cuando la herramienta se ejecuta.

Lo mismo ocurre con la aprobación. El consentimiento para una acción no es permiso para acciones arbitrarias posteriores.

Un prompt no es una ACL

Una instrucción como:

solo puedes leer datos y nunca debes eliminar nada

puede ser una regla de comportamiento útil. No sustituye a un control que bloquee técnicamente DELETE.

Si el modelo puede acceder a una herramienta destructiva y a una credencial que permite la eliminación, esa capacidad existe. El prompt simplemente le pide al modelo que no la use.

Una separación práctica es:

• prompt: qué debe hacer el agente;
• autorización/política: qué está permitido que haga el agente;
• rol del proveedor/API: qué puede hacer la identidad técnica en el proveedor.

El arreglo más seguro es cuando las tres capas están alineadas, pero ninguna es el único control.

Perfiles en lugar de un super‑agente

En nuestra herramienta interna de publicidad, separamos capacidades de lectura/planificación, gestión de campañas y una superficie de nivel propietario para operaciones administrativas raras.

Los nombres no son importantes. Lo esencial es que el análisis ordinario no se ejecute continuamente con el nivel de privilegio más alto.

Un diseño similar en otro contexto podría ser:

Perfil	Trabajo permitido	Límite adicional
agente‑investigación	buscar, leer, resumir	sin cambios de estado
agente‑operaciones	leer, crear borrador, actualizar campos aprobados	alcance operativo
flujo‑admin	operación administrativa	invocación separada, identidad/alcance, aprobación obligatoria, ventana de tiempo estrecha

Un compromiso o error en un agente no otorga automáticamente acceso a todas las clases de operación.

Restringir el sistema de archivos y las herramientas “universales”

Dos categorías merecen especial atención.

Shell / ejecución de comandos

Un shell sin restricciones puede eludir la mayor parte de un modelo de herramientas cuidadosamente diseñado. Si un agente puede ejecutar cualquier comando como un usuario del SO con amplios privilegios, los alcances finos en otras capas ofrecen poca protección.

Las herramientas diseñadas a medida o los comandos en una lista blanca dentro de un entorno limitado suelen ser más fáciles de razonar.

Sistema de archivos

Un agente que necesita escribir un informe en /workspace/reports no necesita acceso a /etc, al directorio personal de un operador ni a secretos de CI.

En nuestro MCP interno de Ads, las operaciones de archivo están limitadas a ubicaciones del servidor aprobadas o a cargas útiles delimitadas. Las rutas de sistema arbitrarias son rechazadas.

Una puerta de enlace de bajo nivel también necesita alcances

A veces una puerta de enlace general es útil para nuevos puntos finales del proveedor antes de que exista una herramienta dedicada. No debe convertirse en una vía de escape.

Debe clasificar:

• método HTTP;
• punto final;
• recurso;
• características de la carga útil;
• si la operación escribe o destruye estado.

Solo entonces debe mapear la solicitud a los permisos requeridos.

Si raw_request puede usar un token de acceso total sin verificaciones de política, es efectivamente acceso de administrador, sin importar cuán cuidadosamente se hayan delimitado las demás herramientas.

Elevación temporal para acciones de alto riesgo

En lugar de asignar un alcance amplio de forma permanente, un sistema puede usar elevación controlada:

1. el agente prepara la operación;
2. la puerta de enlace detecta que se requiere mayor privilegio;
3. una persona aprueba los parámetros exactos;
4. el sistema concede permiso solo para esa operación o por un período corto;
5. el permiso expira tras la ejecución;
6. la pista de auditoría registra la aprobación y el resultado.

No es necesario en todos los casos. Para operaciones críticas reduce el tiempo durante el cual existe un permiso amplio.

Leer: ¿Cuándo debe un agente de IA requerir aprobación humana?

Plantilla de inventario de capacidades

Antes de pasar a producción, escriba los límites:

Agente / flujo de trabajo	Herramienta	Operación	Recurso	Datos	Aprobación	Credencial	Auditoría
informe de campaña	Ads report	read	cuenta A	métricas sin PII	no	corta duración	sí
preparación de campaña	herramienta de campaña	write	cuenta A	configuración	no/condicional	corta duración	sí
activación de campaña	campaign operate	operate	campaña X	presupuesto + estado	sí	corta duración	sí
eliminación de recurso	herramienta admin	destructive	recurso específico	mínimo	sí	elevada	sí

Esto resulta mucho más útil que escribir “el agente tiene acceso a Google Ads”.

Anti‑patrones

Una sola clave API para todo el sistema

Los roles no pueden separarse limpiamente y el acceso para un flujo de trabajo es difícil de revocar.

El mismo conjunto de herramientas para todos los agentes

La función más amplia del catálogo pasa a formar parte de la superficie de riesgo de cada agente.

“Solo‑lectura” únicamente en el prompt

Si el backend sigue aceptando escrituras, “solo‑lectura” es una solicitud, no un control.

Expansión automática del alcance tras un 403

La falta de permiso es una razón para detenerse y tomar una decisión, no para “reintentar como admin”.

Credenciales en el contexto del modelo

Un modelo no necesita el valor de un secreto para pedir a una puerta de enlace confiable que realice una llamada permitida.

Lista de verificación de menor privilegio para un agente

• El agente solo ve las herramientas requeridas para su rol.
• Lectura y escritura están separadas.
• Activar un efecto operativo tiene un alcance distinto de preparar la configuración.
• Las operaciones destructivas tienen una barrera adicional.
• El permiso está limitado al inquilino/cuenta/proyecto/recurso.
• Los recursos objetivo ambiguos no se adivinan automáticamente.
• Las herramientas devuelven los datos mínimos necesarios.
• Las credenciales permanecen fuera del contexto del modelo.
• Los tokens son de corta duración cuando sea práctico.
• La autorización se verifica en la ejecución, no solo al iniciar la sesión.
• El acceso al sistema de archivos y al shell está limitado o sustituido por herramientas específicas.
• Una puerta de enlace cruda no elude la política.
• La elevación de privilegios es explícita y auditable.
• El acceso puede revocarse de forma centralizada.

Ejemplo trabajado: informe de calidad para una línea de producción

Considere un flujo de trabajo propuesto, no una implementación real. Un fabricante desea un resumen matutino de no conformidades para la línea L1. El agente combina recuentos, estados y plazos de acción. No decide si liberar un producto. El responsable de calidad posee el proceso; el administrador de la aplicación posee la configuración de acceso.

Comience con permiso para leer los registros de L1, excluyendo adjuntos y datos de empleados. Guarde el informe en un directorio interno. No otorgue funciones para cerrar no conformidades, cambiar resultados de inspección o enviar comunicaciones a clientes solo porque la misma API las soporta.

Si el equipo más adelante necesita tareas de acción correctiva, añada permiso para crear un borrador para un equipo nombrado. Crear ese borrador no debe cambiar el estado del producto. Actualice el inventario de acceso e identifique quién gestiona una tarea asignada incorrectamente. Los identificadores en este ejemplo son suposiciones de diseño, no resultados de una implementación de Brillnet.

Qué establece la autorización MCP

Esta guía utiliza la especificación MCP versión 2026‑07‑28. Su modelo de autorización HTTP requiere comprobar que un token de acceso fue emitido para el servidor previsto. Un token válido para otro servicio no debe conceder acceso a MCP. La guía de seguridad de MCP también aborda el reenvío de tokens de cliente a APIs descendentes sin la validación adecuada.

Eso aún no determina si un usuario puede leer el registro del cliente B. La autorización de la aplicación debe resolver la relación entre identidad y recurso objetivo. Los alcances OAuth y el filtrado por inquilino cubren partes diferentes del límite. Ambos importan. Verifique los detalles del protocolo contra las versiones realmente usadas por su cliente y servidor; “compatible con MCP” por sí solo dice poco sobre las restricciones de acceso.

Verificar tanto la denegación como el éxito

Un informe correcto demuestra que la ruta permitida funciona. No prueba que otras rutas estén cerradas. Durante la aceptación, conserve resultados para un conjunto pequeño de comprobaciones concretas:

• solicitar el mismo tipo de objeto desde otro inquilino;
• llamar a una función de escritura a través del perfil de informe;
• ejecutar después de que el rol del operador haya sido revocado;
• acceder a un archivo fuera del directorio de informes;
• intentar la misma operación prohibida mediante una puerta de enlace general.

Espere una denegación sin cambio de estado ni divulgación de datos del recurso. Registre el identificador de la comprobación, la versión de la política y el resultado, excluyendo secretos y registros completos de clientes. Estas son sugerencias de pruebas de aceptación para este flujo, no un programa completo de pruebas de seguridad.

Mantener un propietario para los cambios de permiso

El acceso tiende a crecer de forma incremental: otro conector, una excepción, un directorio adicional. Pregunte si el agente sigue realizando el mismo trabajo. Un conector que permite enviar mensajes no debe ampliar silenciosamente un perfil de informe.

El propietario del proceso aprueba la necesidad de negocio. El administrador provisiona y revoca el acceso. El propietario de seguridad examina excepciones y rutas de bypass. En una empresa pequeña, una persona puede ejercer varios roles, pero las decisiones deben seguir siendo rastreables. Defina un intervalo de revisión basado en la frecuencia de cambios y las posibles consecuencias. Elimine los privilegios de instalación una vez completada la instalación.

Mañana, inventarie un agente. Elimine un permiso que su tarea no requiera y verifique la denegación fuera del límite aprobado. Eso brinda evidencia útil sin requerir una sustitución completa de la arquitectura.

Evidencia y límites

Las guías de OWASP respaldan herramientas restringidas y verificaciones de autorización. NIST publica un catálogo de controles de seguridad. Nuestro modelo de lectura/escritura/operación/destrucción y el ejemplo trabajado son recomendaciones de ingeniería, no legislación ni certificado de cumplimiento. Determine por separado las obligaciones organizacionales aplicables. La documentación interna de Ads MCP, versión 1.0 con fecha 28 julio 2026, describe el diseño de control citado; no prueba de forma independiente la operación en producción para un cliente.

Límite

El menor privilegio reduce el impacto máximo de un error o abuso. No garantiza que una operación permitida sea sustancialmente correcta. Por ello lo combinamos con validación de entrada, aprobación para acciones de alto impacto y una pista de auditoría.

Regrese a la guía de agentes de IA seguros o consulte Brillnet Security.

Dos organizaciones ficticias, una tarea limitada

En un entorno de demostración dedicado, dé permiso a un asistente para leer un procedimiento aprobado en la organización ficticia A y preparar un borrador. Excluir aprobación, publicación, cambios de permisos y acceso a la organización B. El servicio de aplicación establece el contexto de la organización a partir del actor autenticado y la relación permitida; un identificador modificado en la solicitud no constituye autoridad para utilizar los datos de otra organización.

Pruebe la lectura permitida, una aprobación excluida y una solicitud para la organización B. Para cada caso, registre el resultado esperado e inspeccione el resultado real. Los casos de rechazo deben dejar el estado prohibido sin cambios y no devolver datos de inquilinos no relacionados. Mantenga la versión de la política y los metadatos mínimos del evento necesarios para reconstruir la verificación, excluyendo al mismo tiempo las credenciales y el contenido innecesario del documento.

Incluya una instrucción inofensiva dentro de la fuente sintética solicitando una exportación no relacionada. Trátelo como contenido del documento. La tarea aprobada y los permisos del servidor siguen siendo la base para la operación permitida. Esto muestra cómo el manejo rápido y el acceso forzado deben trabajar juntos en el diseño propuesto.

En Pulsar, registre el requisito, riesgo, acción y evidencia ficticia para su revisión. Esto prueba cómo su equipo documenta el control. No significa que la prueba pública de Pulsar exponga una puerta de enlace MCP o implemente todos los permisos de agente en su arquitectura. Revise la prueba de 14 días, el método de pago requerido y los términos de cancelación, y acuerde una integración externa por separado si la necesita.

Fuentes

• OWASP AI Agent Security Cheat Sheet. Accedido: 2026-10-02.
• OWASP Authorization Cheat Sheet. Accedido: 2026-10-02.
• Model Context Protocol — The 2026-07-28 Specification. Accedido: 2026-10-02. Fuentes verificadas: 2026-10-10.
• MCP — HTTP authorization specification, 2026-07-28 — Autorización de transporte y tokens vinculados a recursos.
• MCP — security best practices — Límites de autorización y seguridad de integración.
• NIST SP 800-53 Rev. 5 — Principios de control de acceso y control de auditoría.
• OWASP — LLM01 Prompt Injection — Instrucciones de documentos no confiables y riesgos de agentes.
• OWASP — Logging Cheat Sheet — Registros de eventos útiles e información confidencial excluida.
• Pulsar GRC — data-exchange scope — Límite de las reivindicaciones de integración pública.
• Alcance del producto publicado y términos de prueba — Alcance del producto publicado y términos de prueba.

Revise los términos y comience la prueba de 14 días

Auditar una operación de IA: autorización, resultado y estado verificado

CAPA sobre producción de alimentos: de un hallazgo a una revisión de su eficacia

Se modificó un POE farmacéutico: verifique la versión fuente y de capacitación