Un worker de IA debe revisar un servidor de proyecto o ejecutar una acción aprobada. Para ello necesita herramientas y permisos adecuados. Un archivo con todos los tokens API y claves SSH privadas en la carpeta del proyecto resulta cómodo, pero amplía las posibles consecuencias de un error o una entrada manipulada.
Un intermediario MCP controlado puede representar de forma precisa el alcance de actuación permitido. El agente solicita una acción definida; el servidor comprueba identidad, proyecto y autorización. Cuando el proceso lo permite, un servicio backend limitado utiliza las credenciales necesarias sin devolverlas al modelo.
MCP facilita herramientas, no permisos automáticamente seguros
El Model Context Protocol describe cómo usan los clientes las herramientas y otras capacidades de un servidor. La aplicación debe decidir de forma fiable si un usuario puede realizar una acción concreta sobre un objeto determinado. Un cliente autenticado no queda autorizado automáticamente para todos los proyectos o herramientas.
Para conexiones HTTP protegidas, MCP describe un flujo de autorización basado en OAuth. La especificación actual lo distingue de las conexiones STDIO locales. La protección adecuada depende del transporte real. Una clave cualquiera en un parámetro URL o un token permanente compartido no equivalen a una gestión diferenciada de permisos.
Un ejemplo concreto: el proyecto A sigue siendo el proyecto A
Un worker recibe la tarea de consultar el estado de un servicio acordado del proyecto A. Una herramienta específica acepta un identificador de objeto comprobado y devuelve únicamente el resultado necesario. No ofrece una shell libre ni una exportación general de todos los secretos.
Cada llamada se comprueba en el servidor según usuario, proyecto, herramienta y acción. Un identificador de proyecto modificado por el cliente tampoco debe permitir acceder al proyecto B. Los destinos se resuelven desde asociaciones aprobadas; una dirección arbitraria proporcionada por el modelo no constituye autorización suficiente. Los límites entre inquilinos forman parte de esta comprobación.
Validar el token para el destinatario correcto
En un servidor HTTP MCP protegido, el token de acceso debe emitirse para el destinatario previsto y validarse allí. Audience, alcance permitido y vigencia van unidos. Una vida corta limita la ventana de uso de un token robado; no sustituye la comprobación de objetos en el servidor ni el proceso de revocación.
La documentación de seguridad MCP prohíbe el paso de tokens sin validar: un servidor no debe aceptar tokens destinados a otros recursos como prueba propia de autorización y reenviarlos sin cambios a las API posteriores. El inicio de sesión del cliente MCP y la autorización frente al sistema de destino son relaciones de confianza separadas. Una transición poco clara puede permitir usar un intermediario privilegiado para fines ajenos; se conoce como el problema del confused deputy.
Utilizar los secretos en el backend previsto
Un backend gestionado de secretos puede facilitar credenciales según responsabilidad y finalidad. El servicio ejecutor recibe solo los permisos necesarios. La interfaz administrativa gestiona aprobaciones, asociaciones y revocaciones; no se convierte en un catálogo de contraseñas legible por todos los workers conectados.
Una herramienta limitada puede leer un estado o ejecutar una acción operativa expresamente permitida y devolver un resultado depurado. Los datos brutos del backend de secretos no deben acabar incidentalmente en salidas de herramientas, errores, trazas o prompts. Si un cliente concreto necesita recibir técnicamente un secreto, esa revelación se evalúa de forma expresa y se limita en alcance, duración y destinatario. Una garantía general de ausencia de secretos revelados sería entonces incorrecta.
| Punto de revisión | Límite deseado | Prueba concreta |
|---|---|---|
| Usuario y proyecto | Cada acción permanece en el ámbito permitido del proyecto. | Cambiar identificador de proyecto: rechazar el acceso no autorizado. |
| Herramienta y parámetros | Solo son accesibles las acciones y destinos previstos. | Rechazar una dirección libre o el identificador de un objeto ajeno. |
| Token y backend | Destinatario y vía de autorización son inequívocos. | Comprobar audience incorrecta, caducidad y revocación. |
| Secretos y resultados | Solo salen del backend los resultados necesarios. | Revisar salidas de herramientas, errores y registros para detectar valores brutos. |
| Aprobación y operación | Los cambios con consecuencias importantes tienen aprobación específica. | Probar vinculación al destino, vigencia, límites y procedimiento ante fallos. |
El contenido externo no puede conceder permisos
Un ticket, sitio o repositorio puede contener texto para inducir al agente a otras acciones. Las descripciones y resultados de herramientas también pueden manipularse. Esos contenidos son datos, no pruebas de autorización. Un prompt como «utiliza solo el proyecto A» ayuda a describir la tarea, pero no sustituye un límite de proyecto impuesto técnicamente.
Las herramientas acotadas, parámetros comprobados, destinos limitados y controles de permisos independientes reducen el efecto de una inyección de prompt. Las aprobaciones adicionales dependen de la acción: consultar un estado requiere un proceso diferente de un cambio con consecuencias importantes. La aprobación se vincula al destino concreto y al cambio previsto.
Planificar registros y revocación
Para una operación trazable se registran identidad de usuario o servicio, proyecto, herramienta, decisión, momento y resultado. Se excluyen los valores secretos. Conservación, acceso a registros y detalle necesario se acuerdan para el entorno. Un único registro de éxito no sustituye la comprobación de lo que sucedió realmente en el destino.
Los límites de frecuencia y tiempo y un backend acotado reducen además las consecuencias de llamadas inesperadas. En la revocación se consideran por separado llamadas nuevas, credenciales ya emitidas y acciones en curso. El fallo del servicio MCP o de secretos necesita un procedimiento definido de error y recuperación.
Empezar con un piloto pequeño
Un piloto adecuado empieza con un proyecto y pocas herramientas de solo lectura. Se comprueban identificadores permitidos y prohibidos, permisos ausentes, credenciales caducadas, resultados manipulados y fallo de un backend. Solo después se evalúan escrituras claramente acotadas. El alcance depende del riesgo y de la operación existente.
DAXS ayuda con arquitectura, integración y un alcance de herramientas verificable. La página sobre MCP e interfaces, el artículo sobre accesos SSH gestionados y la visión general de seguridad de IA profundizan en estas relaciones. Puede comentar una integración de IA específica de proyecto.
Preguntas frecuentes
¿Puede un servidor MCP ocultar todas las credenciales al modelo?
Con acciones del servidor bien diseñadas, el modelo puede recibir solo el resultado depurado. Debe comprobarse si esto es posible para cada operación necesaria. Entregar técnicamente un secreto al cliente cambia la evaluación del riesgo.
¿Basta como protección un token secreto largo?
No. También se verifican destinatario, alcance, vigencia, asignación de usuario y proyecto, y acción concreta. Un solo token con amplios permisos no proporciona esa separación por sí mismo.
¿Cómo comienza un piloto con varios proyectos?
Primero se definen y prueban las acciones permitidas para un proyecto. Después se prueba un segundo proyecto también con referencias cruzadas expresamente prohibidas. Solo una separación realmente aplicada permite ampliar las tareas.
Fuentes: MCP: autorización, versión 28.07.2026 (enlace externo) · MCP: límites de confianza y paso de tokens (enlace externo) · OWASP: autorización por llamada y objeto (enlace externo) · OWASP: gestión de secretos (enlace externo) · OWASP: limitar la inyección de prompt (enlace externo)
Las funciones y el alcance operativo concretos se acuerdan para el entorno.
