cMCP: Runtime MCP Confidencial

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

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

Vista previa para desarrolladores - lanzado en la Cumbre de Computación Confidencial, 23 de junio de 2026. Puede tener cambios disruptivos antes de v1.0. Consulta STATUS.md para saber exactamente qué se incluye hoy frente a lo que está en la hoja de ruta.

cMCP (Runtime MCP Confidencial) es la forma segura y confidencial de ejecutar MCP: una puerta de enlace de código abierto que aplica la política de llamadas a herramientas MCP dentro de un Entorno de Ejecución Confiable (TEE) de hardware. Cada llamada a una herramienta es interceptada, evaluada contra un paquete de políticas Cedar y aplicada donde el proceso que gobierna no puede alcanzarla. Cada sesión produce una Reclamación TRACE firmada que un verificador comprueba sin confiar en el operador, con atestación de hardware cuando la puerta de enlace se ejecuta en un TEE y solo firmada en modo software. Si buscas una versión segura de MCP, este es el runtime de AgenTrust para ello.

En resumen - Apunta tu agente a la Puerta de Enlace cMCP. Evalúa cada llamada a una herramienta contra una política Cedar dentro de un TEE, bloquea o redacta lo que la política deniega y emite una Reclamación TRACE a prueba de manipulaciones como prueba. Ejecuta pip install cmcp-runtime y comienza en modo software sin necesidad de hardware.

Tu agente llama a Snowflake, Salesforce, una docena de APIs. ¿Qué impide que filtre los datos de un cliente en una de esas llamadas? Si un regulador lo pregunta, ¿podrías demostrar que no ocurrió?

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 estuviera comprometido. La gobernanza de MCP solo por software no puede garantizar:

• Que la política Cedar en disco sea la que se ejecutó. Un administrador malintencionado puede intercambiar el paquete después de la aprobación; la verificación del hash se ejecuta dentro del mismo sistema operativo que controla el administrador.
• Que la decisión de permitir/denegar no se haya alterado 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 tenga 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 una 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 Entorno de Ejecución Confiable (TEE). El hash del paquete de políticas se mide en el informe de atestación de hardware antes de que se ejecute cualquier código.

A diferencia de las soluciones de conectividad basadas en túneles, el Runtime cMCP procesa los payloads de llamadas a herramientas dentro del TEE. El proveedor de conectividad ve texto cifrado, no texto plano. Lo único que sale del enclave es la reclamación TRACE firmada.

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 bearer
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 rápidamente, y el enlace predeterminado sigue siendo 0.0.0.0:8443. En 0.3.0 esa combinación levantaba una puerta de enlace no autenticada en todas las interfaces de tu máquina. Desde 0.4.0 se rechaza: el modo dev sin token solo puede enlazar una dirección de 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

Haz una llamada a una 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 una herramienta devuelve 403 POLICY_DENY antes de llegar a un upstream y luego verifica el recibo firmado.

Consulta docs/quickstart.md para el tutorial completo: política Cedar, catálogo de herramientas, primera Reclamación TRACE y verificación (sin necesidad de TEE de hardware).

Cómo funciona

1. El agente envía cada llamada a una herramienta a la Puerta de Enlace cMCP en lugar de directamente a los servidores MCP.
2. Al iniciar, la puerta de enlace mide el hash del paquete de políticas Cedar en el informe de atestación de hardware. Ningún código se ejecuta antes de esta medición.
3. Cada llamada entrante a una herramienta es evaluada por el motor de políticas Cedar que se ejecuta dentro del TEE. El resultado es permitir, denegar o redactar. La llamada y su decisión se añaden a la cadena de auditoría sellada por hardware.
4. Al final de la sesión, la puerta de enlace produce una Reclamación TRACE: un artefacto firmado y atestado por hardware que registra qué herramientas se ejecutaron, qué política decidió cada llamada y la cadena de auditoría completa. Un verificador lo comprueba sin confiar en el operador.

Agent -> cMCP Runtime -> Cedar Policy Engine (TEE) -> Tool
                     |
               GatewayClaim (TRACE Profile)
               +-- trace.eat_profile
               +-- trace.runtime.platform + measurement
               +-- trace.policy.bundle_hash
               +-- trace.cnf.jwk  (Ed25519 confirmation key)
               +-- gateway.audit_chain (root/tip/length)
               +-- signature (Ed25519 over canonical JSON)

Proveedores de hardware

Orden de sondeo de detección automática de proveedores: azure-cvm -> tpm -> sev-snp -> tdx. Se selecciona el primer proveedor cuyo detect() tenga éxito. opaque es un marcador de posición aún no implementado: está excluido de la detección automática y seleccionarlo explícitamente genera ATTESTATION_PROVIDER_NOT_IMPLEMENTED en lugar de fallar silenciosamente. Si no se detecta ningún proveedor de hardware, la puerta de enlace solo se inicia bajo CMCP_DEV_MODE=1 (un respaldo solo de software sin atestación) y, de lo contrario, se niega a iniciarse.

from cmcp_runtime.config import TEEProvider

# Auto-detect (default)
# attestation.provider: auto  ->  azure-cvm -> tpm -> sev-snp -> tdx
# (software-only is used only under CMCP_DEV_MODE=1)

# Explicit hardware selection
# attestation.provider: sev-snp

# OPAQUE Managed Runtime (opt-in only; not yet implemented)
# OPAQUE_ATTESTATION_URL=https://... cmcp start --config cmcp-config.yaml

Modos de aplicación

El valor predeterminado es enforcing. Establece enforcement_mode: advisory en cmcp-config.yaml para usar el modo advisory.

Configuración

Referencia completa de cmcp-config.yaml:

attestation:
  provider: auto                    # auto | tpm | sev-snp | tdx | opaque | software-only
  enforcement_mode: enforcing       # enforcing | advisory | silent
  validity_seconds: 86400           # ventana de frescura de la atestación (predeterminado: 24 horas)
  staleness_policy: fail_closed     # fail_closed | warn_only
  expected_measurement: ~           # fija un PCR/medición específico (opcional)

policy_bundle_path: policies/       # directorio que contiene archivos .cedar y manifest.json
catalog_path: catalog.json          # catálogo de herramientas aprobadas

listen_addr: "127.0.0.1:8443"     # el modo dev sin token es solo-loopback; establece CMCP_BEARER_TOKEN antes de enlazar más amplio
max_response_size_bytes: 2097152    # 2 MB predeterminado
policy_reload_interval_seconds: 0   # >0 con CMCP_POLICY_HASH fijado se niega a iniciar, consulta docs/spec/policy-hot-reload.md

Variables de entorno:

Referencia CLI

Reclamaciones TRACE

Una GatewayClaim es la unidad de prueba entregada a un auditor, regulador o verificador downstream. Se produce por sesión (o por llamada, configurable) y se firma con una clave que nunca sale del TEE.

(Esta tabla es un resumen de los campos más utilizados.)

La verificación con la biblioteca cmcp_verify no requiere confiar en el operador. El verificador comprueba la firma contra la clave vinculada al TEE, el hash del paquete de políticas contra el valor aprobado y la cadena de auditoría para verificar su consistencia interna.

El esquema normativo es schemas/trace-claim.schema.json, y docs/quickstart.md muestra un ejemplo completo. Consulta docs/spec/verification-library.md y la especificación TRACE para el protocolo de verificación completo.

Alineación con estándares

Seguridad

Consulta SECURITY.md para la notificación de vulnerabilidades y los SLA de respuesta. Consulta LIMITATIONS.md para conocer los límites explícitos del alcance, incluidos los riesgos residuales de captura de payloads APM, inyección de configuración en tiempo de ejecución y cadena de suministro P4.1 (typosquat) que la Fase 1 no cierra.

Documentación

FAQ

¿Qué es cMCP?

cMCP (Runtime MCP Confidencial) es una puerta de enlace de código abierto que aplica la política de llamadas a herramientas MCP dentro de un Entorno de Ejecución Confiable de hardware. Intercepta cada llamada a una herramienta, la evalúa contra un paquete de políticas Cedar, aplica la decisión (permitir, denegar o redactar) y registra la llamada en una cadena de auditoría sellada por hardware.

¿En qué se diferencia cMCP de la gobernanza MCP solo por software?

La gobernanza solo por software ejecuta el motor de políticas en el mismo sistema operativo al que un operador o una CVE de la cadena de suministro puede acceder, por lo que no puede demostrar que la política ejecutada fuera la aprobada ni que la decisión no se alterara en memoria. cMCP ejecuta el motor de políticas dentro de un TEE y mide el hash del paquete Cedar en el informe de atestación de hardware antes de que se ejecute cualquier código, de modo que el plano de control no puede ser alcanzado por el proceso que gobierna.

¿Necesito hardware especial para probarlo?

No. Establece CMCP_DEV_MODE=1 para usar el proveedor TEE solo de software y ejecutar el inicio rápido completo sin un TEE de hardware. Los proveedores de hardware (TPM, AMD SEV-SNP, Intel TDX, OPAQUE) se usan en producción.

¿Qué es una Reclamación TRACE?

Una Reclamación TRACE (una GatewayClaim) es un artefacto firmado y atestado por hardware producido por sesión. Registra qué herramientas se ejecutaron, qué política decidió cada llamada, el hash del paquete Cedar y la cadena de auditoría, y se firma con una clave Ed25519 que nunca sale del TEE. Un verificador la comprueba con la biblioteca cmcp_verify sin confiar en el operador.

¿Qué proveedores TEE se admiten?

TPM 2.0 / vTPM, AMD SEV-SNP e Intel TDX, con computación confidencial de GPU NVIDIA planificada para v0.2 y Runtime Confidencial OPAQUE disponible como opt-in explícito. El orden de detección automática es VM confidencial de Azure, luego TPM 2.0 / vTPM, luego AMD SEV-SNP, luego Intel TDX; el proveedor solo de software se usa únicamente bajo CMCP_DEV_MODE=1.

¿Bajo qué licencia está cMCP?

MIT.

Contribuciones

CONTRIBUTING.md · GOVERNANCE.md · Discusiones

Únete a la comunidad en Discord.

¿Usas cMCP en producción? Añade tu organización a ADOPTERS.md.

Licencia

MIT - consulta LICENSE.