cMCP: Entorno de ejecución MCP confidencial

Novedades de la comunidad y destacados de colaboradores: AgenTrust en LinkedIn.

Aplica la política de herramientas MCP dentro de un TEE, donde el agente que gobierna no puede alcanzarla

Inicio rápido · Arquitectura · Configuración · CLI · Registro de cambios

Vista previa para desarrolladores - lanzada en la Confidential Computing Summit, 23 de junio de 2026. Puede tener cambios incompatibles antes de la v1.0. Consulta STATUS.md para saber exactamente qué se entrega hoy frente a lo que está en la hoja de ruta.

cMCP (Confidential MCP Runtime) es una puerta de enlace de código abierto que verifica cada llamada a herramienta que realiza un agente de IA contra las reglas que tú escribes, y puede ejecutarse en hardware aislado que el agente no puede manipular. Los agentes de IA utilizan herramientas (bases de datos, CRMs, correo electrónico, API internas) enviando solicitudes llamadas llamadas a herramientas, normalmente a través de MCP, el Model Context Protocol. cMCP se sitúa en la ruta de esas llamadas, verifica cada una contra tus reglas (escritas en el lenguaje de políticas Cedar) y bloquea las que las reglas prohíben. Puede ejecutarse dentro de un TEE (entorno de ejecución de confianza: hardware que mantiene la memoria de un programa aislada incluso del propietario de la máquina), donde el agente que gobierna no puede alcanzarlo. Cada sesión termina con un recibo firmado, un TRACE Claim, que cualquiera puede verificar sin confiar en quien ejecutó la puerta de enlace. El recibo está respaldado por un informe de hardware cuando la puerta de enlace se ejecuta en un TEE, y solo está firmado (sin prueba de hardware) en modo software. ¿No conoces estos términos? Consulta los términos, en lenguaje sencillo.

TL;DR: Apunta tu agente a la puerta de enlace cMCP. Verifica cada llamada a herramienta contra tus reglas Cedar, bloquea o redacta (oculta) lo que las reglas deniegan, y te entrega un recibo firmado que muestra si alguien lo alteró. Ejecuta pip install cmcp-runtime y empieza en modo software en cualquier ordenador; no se requiere hardware especial.

Tu agente llama a Snowflake, Salesforce, una docena de API. ¿Qué le impide filtrar los datos de un cliente en alguna de esas llamadas? Si un regulador lo pregunta, ¿podrías demostrar que no lo hizo?

---

El problema

Un agente llama a una herramienta. El motor de políticas dice permitir. La llamada a la herramienta se realiza.

Nada de eso demuestra que el propio motor de políticas no haya sido comprometido. La gobernanza MCP solo por software no puede garantizar:

• Que la política Cedar en disco sea la que se ejecutó. Un administrador malicioso puede sustituir el paquete después de su aprobación; la verificación de hash se ejecuta dentro del mismo sistema operativo que controla el administrador.
• Que la decisión de permitir/denegar no se haya invertido en memoria. Una CVE de la cadena de suministro en el evaluador se ejecuta en el mismo espacio de direcciones que el atacante.
• Que el registro de auditoría refleje lo que realmente ocurrió. Cualquier parte que posea la clave de firma de software puede reconstruir una cadena de auditoría válida a posteriori.

El plano de control que gobierna las llamadas a herramientas debe ejecutarse donde no pueda ser alcanzado por el proceso que gobierna.

Aplicación de políticas con atestación de hardware para llamadas a herramientas MCP. Cada llamada a herramienta se intercepta, se evalúa contra un paquete de políticas Cedar y se aplica mediante un motor de políticas que se ejecuta dentro de un Trusted Execution Environment (TEE). Antes de atender una sola llamada a herramienta, la puerta de enlace mide su código instalado, el paquete de políticas y la configuración en el informe de atestación de hardware, y vuelve a atestiguar cada vez que el paquete se recarga.

En un despliegue de hardware, el tiempo de ejecución de cMCP procesa las cargas útiles de las llamadas a herramientas dentro del TEE. Lo que el host y el proveedor de conectividad pueden leer también depende de la política de salida, y el servidor de herramientas ascendente es un componente separado fuera del TEE. El modo software (CMCP_DEV_MODE) no proporciona aislamiento de hardware. LIMITATIONS.md enumera lo que cMCP no impide.

---

Inicio rápido

pip install cmcp-runtime

Cree cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory eases first-run tuning; the default is `enforcing`
listen_addr: "127.0.0.1:8443"  # pin loopback: dev mode runs without a bearer token
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

listen_addr no es opcional aquí. CMCP_DEV_MODE=1 omite deliberadamente el requisito del token bearer para que puedas probar cosas rápidamente, y el bind por defecto sigue siendo 0.0.0.0:8443. En 0.3.0 esa combinación levantaba un gateway sin autenticación en todas las interfaces de tu máquina. A partir de 0.4.0 se rechaza: el modo de desarrollo sin token solo puede enlazar una dirección de loopback, y un bind que no sea de loopback requiere CMCP_BEARER_TOKEN. Fija listen_addr explícitamente y la configuración será correcta en ambos casos.

Inicia el gateway:

CMCP_DEV_MODE=1 cmcp start --config cmcp-config.yaml

Hacer una llamada a la herramienta:

curl -X POST http://localhost:8443/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"salesforce.contacts","arguments":{"query":"Acme Corp"},"_cmcp":{"session_id":"s1","workflow_id":"demo-agent"}}}'

¿Prefieres una versión guiada? agentrust-io.com/quickstart recorre el mismo camino en unos diez minutos en un portátil, sin hardware y sin registro: instala, escribe una regla Cedar forbid, observa cómo una llamada a herramienta devuelve 403 POLICY_DENY antes de llegar a un upstream, y luego verifica el recibo firmado.

Consulta docs/quickstart.md para el recorrido completo: política Cedar, catálogo de herramientas, primer TRACE Claim y verificación (no se requiere TEE de hardware).

---

Cómo funciona