MCP y agentes de IA: cómo limitar permisos antes de conectar herramientas
Un agente de IA puede comenzar consultando la documentación interna de una empresa y terminar creando un ticket, modificando un registro o ejecutando una acción operativa. El riesgo no está únicamente en el modelo: también está en las herramientas que puede invocar, en los permisos asociados y en la ausencia de controles entre una consulta de solo lectura y una operación que cambia datos.
Model Context Protocol (MCP) puede facilitar la conexión entre agentes y herramientas, pero conectar una herramienta no debería equivaler a otorgar acceso ilimitado. Antes de habilitar una integración, un equipo de ingeniería debe responder una pregunta concreta: ¿qué puede leer el agente, qué puede cambiar y quién autoriza las acciones sensibles?
Este artículo presenta un enfoque de arquitectura para aplicar mínimo privilegio, separar capacidades de lectura y escritura, gestionar secretos, incorporar aprobación humana y probar posibles abusos. Los principios son generales; los mecanismos disponibles pueden variar según el cliente de IA, el servidor MCP y la plataforma utilizada.
El problema: consultar información no es lo mismo que modificar datos
Consideremos un agente utilizado por un equipo de soporte. Su objetivo es:
- Consultar la documentación técnica de un producto.
- Buscar incidentes similares en un sistema de tickets.
- Proponer una respuesta para el operador.
- Crear un ticket cuando el usuario lo solicite.
La primera parte del flujo es principalmente de lectura. El agente necesita recuperar información y generar una respuesta. La creación de un ticket, en cambio, es una operación con efectos persistentes: puede notificar a otras personas, iniciar un proceso operativo, generar compromisos de atención o almacenar información incorrecta.
Un diseño débil podría entregar al agente un token con permisos amplios sobre el sistema de tickets. En ese escenario, una instrucción ambigua, una respuesta manipulada en la documentación o un error de interpretación podría provocar una acción no deseada.
La alternativa es separar las capacidades:
- Servidor o herramienta de consulta: permite buscar documentación y leer tickets autorizados.
- Herramienta de creación: permite proponer o crear tickets, pero con un permiso distinto.
- Control de aprobación: exige confirmación antes de ejecutar acciones que modifican datos.
La separación no elimina todos los riesgos. Sin embargo, reduce el alcance de un error o de una instrucción maliciosa y hace más explícita la frontera entre recuperar información y actuar sobre sistemas empresariales.
Qué aporta MCP y qué no debería darse por supuesto
MCP puede entenderse como un protocolo para conectar clientes de agentes con servidores que exponen recursos, instrucciones o herramientas. Esa conexión ayuda a estandarizar la forma en que un agente descubre y utiliza capacidades externas.
Pero MCP no debe confundirse con una política completa de seguridad. El protocolo o una implementación concreta no necesariamente resuelve por sí solo:
- Qué identidad tiene el agente en cada sistema.
- Qué permisos posee esa identidad.
- Si una operación requiere aprobación humana.
- Cómo se almacenan y rotan los secretos.
- Qué datos pueden cruzar los límites entre entornos.
- Cómo se registran y revisan las acciones.
Estos controles dependen de la arquitectura completa: cliente de IA, servidor MCP, proveedor de identidad, sistema destino, gestor de secretos, mecanismos de auditoría y procesos operativos.
Por eso conviene distinguir entre tres niveles:
- Principio: por ejemplo, mínimo privilegio o separación de funciones.
- Control de arquitectura: como utilizar identidades diferentes para lectura y escritura.
- Mecanismo específico: una función de un cliente, servidor MCP o plataforma que solicita confirmación o limita una herramienta.
Un mecanismo que existe en una implementación puede no estar disponible, activado o configurado de la misma forma en otra. Antes de basar una decisión crítica en una funcionalidad concreta, es necesario validar su comportamiento en la documentación vigente y mediante pruebas controladas.
Aplicar mínimo privilegio a las herramientas del agente
El principio de mínimo privilegio indica que una identidad debe tener únicamente los permisos necesarios para realizar su función. En agentes de IA, esto debe aplicarse a cada herramienta, no solo al sistema completo.
Separar lectura y escritura
Una práctica recomendable es utilizar identidades, credenciales o políticas diferenciadas para las operaciones de lectura y de modificación. Por ejemplo, un agente puede consultar una base de conocimiento mediante una identidad de solo lectura, mientras que la creación de tickets se ejecuta mediante una capacidad distinta.
La separación puede implementarse de varias maneras, según la plataforma:
- Exponer herramientas distintas para consultar y modificar.
- Usar tokens o roles diferentes.
- Colocar las operaciones de escritura detrás de un servicio intermedio.
- Permitir que el agente genere una propuesta y que otro componente ejecute la acción después de validarla.
No siempre será necesario crear un servidor independiente para cada capacidad. Lo importante es que una credencial utilizada para consultar documentación no pueda, por defecto, crear, actualizar o eliminar registros.
Limitar el alcance de las operaciones
El permiso “crear tickets” puede ser demasiado amplio. Conviene precisar aspectos como:
- Qué proyectos o colas puede utilizar el agente.
- Qué campos puede completar.
- Qué tipos de ticket puede crear.
- Qué etiquetas o prioridades puede asignar.
- Si puede adjuntar archivos o incluir contenido externo.
- Si puede modificar tickets existentes o únicamente crear borradores.
Este nivel de detalle reduce el riesgo de que una herramienta aparentemente limitada se convierta en una vía indirecta para ejecutar cambios más amplios.
Validar los parámetros en el servidor
Las instrucciones del agente no deben considerarse una frontera de seguridad. El servidor que ejecuta una acción debe validar identidad, autorización, formato y alcance de los parámetros recibidos.
Por ejemplo, si una herramienta acepta un identificador de proyecto, el servidor debería comprobar que la identidad del agente tiene acceso a ese proyecto. No debería confiar únicamente en que el modelo recibió instrucciones de utilizar un proyecto concreto.
Separar entornos y reducir el impacto de los errores
Un agente en desarrollo no debería operar con las mismas credenciales ni contra los mismos datos que un agente en producción. La separación de entornos permite probar herramientas, políticas y flujos de aprobación sin exponer directamente sistemas operativos.
Un esquema razonable puede contemplar:
- Desarrollo: datos sintéticos o anonimizados y herramientas limitadas.
- Pruebas: escenarios controlados para verificar permisos, trazabilidad y comportamiento ante errores.
- Producción: acceso restringido, identidades administradas y aprobación para acciones sensibles.
La separación debe cubrir más que la URL del sistema. También conviene separar cuentas, secretos, colas, bases de datos, espacios de trabajo y destinos de notificación cuando corresponda.
Un error frecuente es probar un agente con una cuenta personal de administrador porque resulta más rápido. Esa práctica oculta problemas de autorización y dificulta saber cuál sería el comportamiento con los permisos reales. Las pruebas deben utilizar identidades representativas del rol que tendrá el agente en producción.
Gestionar secretos y aprobar acciones sensibles
Los secretos no pertenecen al prompt
Tokens, claves de API y credenciales de servicios no deberían incluirse en instrucciones, archivos de configuración sin protección ni mensajes enviados al modelo. Deben gestionarse mediante mecanismos apropiados para secretos, con acceso restringido, rotación y registro de uso cuando la plataforma lo permita.
El servidor MCP o el componente intermediario debería obtener únicamente los secretos que necesita para la operación que ejecutará. Una herramienta de consulta no debería tener acceso a la credencial utilizada por una herramienta de escritura.
También es importante revisar qué información aparece en logs, trazas y mensajes de error. Un secreto puede quedar expuesto aunque no forme parte explícita de la conversación con el agente.
La aprobación humana como control de riesgo
Las operaciones sensibles pueden requerir una confirmación explícita antes de ejecutarse. Crear un ticket de soporte puede tener un riesgo moderado; eliminar datos, cambiar permisos, desplegar código o modificar una configuración de producción requiere un umbral de control mayor.
La aprobación debería mostrar suficiente contexto para que una persona pueda decidir:
- Qué herramienta se invocará.
- Qué sistema y recurso serán afectados.
- Qué parámetros se enviarán.
- Qué identidad ejecutará la acción.
- Qué resultado se espera.
Una ventana de confirmación genérica, como “¿desea continuar?”, ofrece poca protección si no explica el cambio concreto. Además, la aprobación no debería convertirse en un trámite automático que los usuarios aceptan sin revisar.
En algunos diseños, el agente no ejecuta directamente la escritura. Genera una propuesta estructurada y un servicio o persona la revisa antes de enviarla al sistema destino. Esto agrega latencia y complejidad, pero puede ser apropiado cuando el impacto de una acción incorrecta es alto.
Diseñar trazabilidad y pruebas de abuso
La seguridad de un agente no se puede evaluar solo observando si responde correctamente en un escenario ideal. También es necesario saber qué intentó hacer, qué herramientas utilizó y por qué una acción fue permitida o rechazada.
Qué registrar
La trazabilidad debería permitir reconstruir una operación sin almacenar innecesariamente información sensible. Según las restricciones de privacidad y cumplimiento de la organización, puede ser útil registrar:
- Identidad del usuario que inició la solicitud.
- Identidad técnica utilizada por el agente.
- Herramienta invocada y operación solicitada.
- Recurso afectado y resultado de la autorización.
- Si hubo aprobación humana y quién la otorgó.
- Resultado de la operación y código de error cuando corresponda.
- Referencia a la conversación o solicitud original, evitando guardar secretos.
La observabilidad debe abarcar el cliente, el servidor MCP, el servicio intermediario y el sistema final. Un log únicamente del modelo puede no explicar si una operación fue rechazada por autorización, falló por una condición de red o nunca llegó al sistema destino.
Probar instrucciones maliciosas y límites de autorización
Las pruebas de abuso deben incluir casos en los que el agente reciba instrucciones para saltarse controles, revelar información o utilizar una herramienta fuera de su objetivo. Algunos ejemplos son:
- Solicitar que el agente utilice una credencial de lectura para ejecutar una escritura.
- Incluir en un documento consultado una instrucción que intente cambiar el comportamiento del agente.
- Pedir acceso a tickets de otro equipo o a datos fuera del alcance autorizado.
- Manipular los parámetros para apuntar a otro proyecto o recurso.
- Repetir una operación después de un error para comprobar si produce duplicados.
- Intentar ejecutar una acción sensible sin la aprobación requerida.
El objetivo no es demostrar que el modelo “entiende” la política, sino verificar que los controles técnicos siguen funcionando aunque el modelo se equivoque o reciba contenido adversarial.
Errores frecuentes al conectar agentes con herramientas
- Dar permisos de administrador para simplificar la integración: acelera la prueba inicial, pero impide evaluar el diseño real de autorización.
- Exponer una herramienta genérica: una operación como “ejecutar una solicitud HTTP” puede tener un alcance mucho mayor que una herramienta específica para crear un ticket.
- Confiar en el prompt como política de seguridad: una instrucción textual no sustituye la autorización aplicada por el servidor.
- Mezclar lectura y escritura en la misma credencial: dificulta revocar una capacidad sin interrumpir las demás.
- Omitir la idempotencia: si una solicitud se reintenta, una acción de escritura podría duplicarse. El diseño debe considerar identificadores de operación o validaciones adecuadas cuando el sistema lo permita.
- No revisar los datos que salen del entorno: una herramienta de consulta puede exponer información sensible al contexto del modelo o a los registros operativos.
- Confundir disponibilidad con autorización: que el agente pueda descubrir una herramienta no significa que deba poder utilizarla en cualquier situación.
Una lista de verificación antes de habilitar una integración MCP
Antes de conectar una herramienta empresarial a un agente, el equipo puede documentar al menos los siguientes puntos:
- Objetivo exacto de la herramienta y casos de uso permitidos.
- Datos que puede leer, crear, actualizar o eliminar.
- Identidad técnica y permisos efectivos.
- Separación entre capacidades de solo lectura y de escritura.
- Entornos en los que estará disponible.
- Secretos utilizados, ubicación de almacenamiento y proceso de rotación.
- Acciones que requieren aprobación humana.
- Validaciones aplicadas por el servidor, independientemente del modelo.
- Eventos que se registrarán y período de conservación.
- Pruebas de abuso, errores, reintentos y acceso fuera de alcance.
- Proceso para revocar la herramienta o sus credenciales.
Esta documentación también facilita las revisiones de arquitectura y evita que una integración experimental se convierta gradualmente en una dependencia crítica sin controles equivalentes.
Conclusión: conectar menos no siempre es limitar mejor
El riesgo de un agente de IA no depende únicamente de su capacidad para generar respuestas. Depende de las acciones que puede realizar sobre sistemas reales y de los controles que existen entre una intención textual y un cambio persistente.
MCP puede ser una pieza útil para integrar agentes con herramientas, pero la seguridad debe diseñarse alrededor de identidades, permisos, separación de entornos, secretos, aprobación, trazabilidad y pruebas. La decisión clave es separar explícitamente el acceso de lectura de las operaciones que modifican datos, sin asumir que una función concreta del cliente o servidor estará disponible en todas las implementaciones.
Antes de habilitar una herramienta a un agente, documenta qué puede leer, qué puede cambiar y quién autoriza las acciones sensibles. Ese ejercicio es un punto de partida práctico para revisar la arquitectura, identificar riesgos y establecer un gobierno técnico sostenible para equipos que adoptan agentes de IA.
