cMCP: Runtime MCP Confidencial

Actualizaciones 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 el Confidential Computing Summit, 23 de junio de 2026. Puede tener cambios disruptivos 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, APIs 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 (trusted execution environment: 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. ¿Eres nuevo en 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 comienza en modo software en cualquier computadora; no se requiere hardware especial.

Tu agente llama a Snowflake, Salesforce, una docena de APIs. ¿Qué le impide filtrar los datos de un cliente en una 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 prueba que el propio motor de políticas no haya sido comprometido. La gobernanza MCP solo por software no puede garantizar:

La política Cedar en disco es la que se ejecutó. Un administrador malicioso puede intercambiar el paquete después de la aprobación; la verificación de hash se ejecuta dentro del mismo SO que controla el administrador.
La decisión de permitir/denegar no fue alterada en memoria. Un CVE de cadena de suministro en el evaluador se ejecuta en el mismo espacio de direcciones que el atacante.
El registro de auditoría refleja lo que realmente ocurrió. Cualquier parte que posea la clave de firma de software puede reconstruir una cadena de auditoría válida después de los hechos.

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 es interceptada, evaluada contra un paquete de políticas Cedar, y aplicada por 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 Runtime 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 egreso, y el servidor de herramientas upstream 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 previene.

Inicio Rápido

pip install cmcp-runtime

Crea cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory   # advisory facilita el ajuste inicial; el valor predeterminado es `enforcing`
listen_addr: "127.0.0.1:8443"  # fija loopback: el modo dev se ejecuta sin token de portador
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

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

Inicia la puerta de enlace:

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

Realiza una llamada a 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 una laptop, 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).

cmcp v0.4.0