Auditoría de MCP: proteja y controle cada llamada de herramienta

Qué estandariza MCP y dónde comienza la gobernanza¶

En la especificación MCP actual, un cliente y un servidor inicializan una sesión, negocian capacidades e intercambian mensajes de protocolo. Un servidor con capacidad de herramientas puede publicar definiciones de herramientas a través de tools/list. Cada definición puede incluir un nombre, una descripción, una entrada de esquema JSON, un esquema de salida opcional y anotaciones de comportamiento. Un cliente invoca una de esas herramientas con tools/call.

Esa secuencia de protocolo proporciona a los auditores objetos estables a los que hacer referencia: versión del protocolo, información de implementación del servidor, definición de herramienta descubierta, esquema de entrada, identificador de llamada, argumentos, resultado y estado de error. La propiedad responsable, la clasificación de consecuencias, la autoridad empresarial, el enrutamiento de solicitudes de decisión, la retención y la prueba de integridad de registros pertenecen a la capa de host o puerta de enlace que ve cada llamada.

La especificación también establece una importante regla de confianza. Los clientes deben tratar las anotaciones de herramientas como no confiables a menos que provengan de un servidor confiable. Las descripciones guían la selección de herramientas del modelo y merecen la misma revisión. Microsoft documenta el envenenamiento de herramientas como una ruta indirecta de inyección rápida en la que se colocan instrucciones maliciosas dentro de las descripciones de las herramientas. Por lo tanto, un inventario de producción registra la definición recibida del servidor y la definición aprobada o el resumen que la seguridad revisó.

Cree el inventario de herramientas gobernadas antes del tiempo de ejecución¶

Una población de auditoría comienza con los servidores y las herramientas a los que realmente puede acceder un agente. Registre el propietario del servidor, el transporte, la versión del paquete o la imagen, el repositorio de origen, el entorno de implementación, el método de autenticación, el recurso o audiencia de OAuth, los alcances otorgados, los destinos de los datos, las rutas de salida y los agentes y procesos a los que se les permite conectarse.

Para cada herramienta descubierta, conserve la definición completa y un resumen canónico. Revise el nombre, la descripción, el esquema de entrada, el esquema de salida, las anotaciones y cualquier comportamiento de tarea declarado. Cuando un servidor publica una lista modificada, pausa las herramientas recién agregadas o modificadas materialmente hasta que el propietario apruebe la diferencia. Un modelo nunca debería obtener una nueva ruta de escritura porque una descripción remota cambió entre sesiones.

Clasificar la acción del comportamiento real. Las anotaciones de solo lectura, destructivas, idempotentes y de mundo abierto son sugerencias de revisión útiles. El esquema MCP actual establece que son sugerencias y ofrece valores predeterminados cautelosos. Los controles de red, la zona de pruebas, las credenciales de ámbito y la aplicación de políticas conllevan la garantía.

• Identidad: identificadores de servidor estable, herramienta, agente, director, inquilino y propietario.
• Cadena de suministro: fuente, editor, resumen, estado de firma, revisión de dependencia y canal de actualización aprobado.
• Autoridad: herramientas exactas, acciones, destinos, límites de datos, alcances de OAuth y vencimiento de la delegación.
• Control de cambios: resumen de definiciones aprobadas, horas de primera y última revisión, y una diferencia para cada cambio de lista.
• Ubicación del tiempo de ejecución: entorno, región, límite de red, referencia secreta y política de salida.

Normalice todas las herramientas/call en el contexto de una puerta¶

La puerta de enlace debe analizar la solicitud JSON-RPC y agregar los datos que el mensaje electrónico no puede transportar de forma segura. El contexto de la puerta necesita identificadores de inquilino y de ejecución, identidades de principal y agente, flujo de trabajo y paso, entorno, nombres de herramientas y servidores canónicos, destino, argumentos de herramientas, clasificación de datos, versiones de modelos y solicitudes, y la versión de política actual.

Valide los argumentos contra el esquema de entrada aprobado antes de la evaluación de la política. Aplique hash a los argumentos canónicos y mantenga los valores confidenciales fuera de los registros ordinarios. El motor de políticas puede evaluar campos estructurados seleccionados cuando el esquema de la herramienta los declara, mientras que el registro de evidencia conserva un resumen y referencias controladas a datos de origen protegidos.

Para los transportes HTTP, siga la especificación de autorización de MCP: vincule tokens al recurso deseado, valide su audiencia en el servidor MCP, solicite los alcances mínimos y use tokens descendentes separados para las API ascendentes. Para stdio, la especificación MCP dirige las implementaciones para obtener credenciales del entorno. En ambos casos, almacene los metadatos de los tokens y las decisiones de alcance en el registro de auditoría y excluya los tokens y los secretos sin procesar.

{
  "jsonrpc": "2.0",
  "id": "call-1842",
  "method": "tools/call",
  "params": {
    "name": "cmb_decision_request.create",
    "arguments": {
      "case_id": "case-1842",
      "recommended_action": "require_human_approval",
      "reason_codes": [
        "confirmed_sanctions_hit"
      ],
      "approver_group": "aml-l1-approval",
      "urgency": "elevated",
      "evidence_refs": [
        "evidence://case-1842/screening"
      ]
    }
  }
}

Evaluar la política antes de que la herramienta pueda actuar¶

La autenticación demuestra qué principal llegó al servidor. La autorización establece qué recurso y alcance puede utilizar ese director. La política de tiempo de ejecución determina si esta acción puede ejecutarse aquí, con estos argumentos, en este Proceso, en este momento.

Utilice un valor predeterminado de cierre fallido. Los contratos KLA PolicyVersion representan cuatro resultados. permitir libera la llamada. advertir lo libera y crea una señal revisable. require_approval lo pausa y enruta una solicitud de decisión a un grupo autorizado. bloque lo rechaza. Las reglas coincidentes llevan un código de motivo estable, los campos evaluados, una clasificación de determinismo y una corrección configurada. La decisión predeterminada bloquea las llamadas que no coinciden con ninguna regla y emite su motivo de reserva genérico.

El siguiente ejemplo coincide con el esquema actual de KLA PolicyVersion y el vocabulario de Policy Builder. Utiliza nombres de herramientas y el grupo de revisores de la plantilla de demostración guiada AML actual de KLA. Vincule el alcance de la política y los nombres de las herramientas al catálogo de herramientas de destino antes de la publicación. El valor predeterminado bloquea todas las herramientas que no estén incluidas en una regla explícita.

{
  "schemaVersion": "1.0.0",
  "policyId": "pol_mcp_tool_calls",
  "workspaceId": "workspace-regulated-operations",
  "name": "MCP tool-call controls",
  "description": "Governs AML alert reads, evidence retrieval, and Decision Desk routing.",
  "status": "draft",
  "version": "1.0.0",
  "policyKind": "guardrail",
  "scope": {
    "workflowIds": [],
    "agentIds": [],
    "stepIds": [],
    "environments": [
      "prod"
    ]
  },
  "defaultDecision": "block",
  "rules": [
    {
      "ruleId": "allow-alert-read",
      "name": "Allow scoped alert reads",
      "interceptionPoint": "tool_call",
      "when": {
        "expression": {
          "==": [
            {
              "var": "context.action.toolName"
            },
            "cmb_alerts.read"
          ]
        }
      },
      "then": {
        "decision": "allow",
        "reason": "The registered read tool may inspect an alert within its configured data scope.",
        "reasonCodes": [
          "aml_scoped_alert_read"
        ]
      },
      "execution": {
        "mode": "deterministic"
      },
      "evidence": {
        "evaluatedFields": [
          "context.action.toolName"
        ],
        "artifactRefs": [],
        "sensitivityTier": "internal"
      }
    },
    {
      "ruleId": "warn-evidence-retrieval",
      "name": "Flag evidence retrieval",
      "interceptionPoint": "tool_call",
      "when": {
        "expression": {
          "==": [
            {
              "var": "context.action.toolName"
            },
            "cmb_evidence.retrieve"
          ]
        }
      },
      "then": {
        "decision": "warn",
        "reason": "The tool retrieves case evidence under class-aware governance.",
        "reasonCodes": [
          "aml_evidence_retrieval"
        ],
        "remediation": {
          "summary": "Review the evidence class and references before a consequential action.",
          "steps": []
        }
      },
      "execution": {
        "mode": "deterministic"
      },
      "evidence": {
        "evaluatedFields": [
          "context.action.toolName"
        ],
        "artifactRefs": [],
        "sensitivityTier": "restricted"
      }
    },
    {
      "ruleId": "approve-decision-desk-routing",
      "name": "Decision Desk routing requires approval",
      "interceptionPoint": "tool_call",
      "when": {
        "expression": {
          "==": [
            {
              "var": "context.action.toolName"
            },
            "cmb_decision_request.create"
          ]
        }
      },
      "then": {
        "decision": "require_approval",
        "reason": "An AML L1 reviewer must confirm the material recommendation.",
        "reasonCodes": [
          "aml_decision_desk_routing_requires_approval"
        ],
        "remediation": {
          "summary": "Assign the request to AML L1 review.",
          "steps": [
            {
              "title": "Review the case packet",
              "description": "Inspect the recommendation, rationale, evidence references, and missing information."
            }
          ]
        },
        "approverGroup": "aml_l1_reviewers"
      },
      "execution": {
        "mode": "deterministic"
      },
      "evidence": {
        "evaluatedFields": [
          "context.action.toolName",
          "context.action.toolArgs"
        ],
        "artifactRefs": [],
        "sensitivityTier": "restricted"
      }
    }
  ]
}

Haga de la aprobación humana un control duradero¶

Un control de aprobación duradero registra que una persona autorizada revisó una acción definida bajo una política definida antes de su ejecución.

Muestre al revisor el agente y el principal, la herramienta y el destino, los argumentos materiales en una pantalla segura, las consecuencias comerciales, la base de la política, los códigos de motivo, las referencias de evidencia, el vencimiento y la decisión exacta solicitada. Hacer cumplir la separación entre hacedor y verificador cuando una persona propuso o inició la acción. Verifique el rol del revisor cuando se presente la decisión.

Vincule la solicitud de decisión al hash del argumento y al identificador de puerta. Después de la aprobación, vuelva a ejecutar la misma llamada lógica y verifique los argumentos contra el hash sellado. Un cambio en el monto, el destino, la identificación del registro o la referencia de evidencia requiere una nueva decisión. Rechace aprobaciones caducadas y aprobaciones emitidas para otro inquilino, entorno, versión de política o herramienta.

MCP tools/call no define un flujo de trabajo de aprobación empresarial. El anfitrión puede pausar su motor de flujo de trabajo duradero, devolver un marcador estructurado de aprobación requerida o utilizar el [flujo de tarea aumentada] experimental (https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks) cuando ambas partes negocian el apoyo. El objetivo de control permanece constante: no se produce ningún efecto secundario hasta que se resuelve la decisión autorizada, y los reintentos no pueden crear efectos duplicados.

• Pendiente: persiste la solicitud de decisión y se detiene antes de su ejecución.
• Aprobado: verificar autoridad, vencimiento, ID de puerta, versión de política y hash de argumento; ejecutar una vez.
• Rechazado: cierra la solicitud y devuelve un resultado bloqueado estable.
• Llamada modificada: crea una nueva solicitud con un nuevo hash y un historial de decisiones.
• Tiempo de espera o interrupción: aplica el resultado de cierre fallido publicado y conserva el intento fallido.

Controlar la ejecución, la salida y los reintentos.¶

Escriba una intención de idempotencia antes de una llamada de efectos secundarios. Pase la clave de idempotencia en sentido descendente cuando la herramienta la admita y luego confirme el resultado. Un reintento puede devolver el resultado confirmado, reanudar una aprobación pendiente o recuperar una intención en curso bajo la misma clave. No puede ejecutar silenciosamente el efecto secundario dos veces.

Valide la salida estructurada con el esquema de salida aprobado cuando la herramienta lo declare. Trate el texto, los enlaces, los recursos incrustados, las imágenes y el contenido estructurado devueltos como datos que no son de confianza. Aplique redacción, política de contenido, controles de destino y una puerta de salida antes de que el modelo u otra herramienta consuma el resultado.

Registre los errores de protocolo y los errores de ejecución de herramientas por separado. Los resultados de la herramienta MCP pueden contener isError: true, mientras que las solicitudes con formato incorrecto y herramientas desconocidas utilizan errores de protocolo. Conserve ambas clases porque admiten diferentes pruebas de control: validación del cliente, disponibilidad del servidor, fallas comerciales posteriores y rechazo de políticas.

Registre la unidad de auditoría completa¶

Un registro de auditoría de MCP debe conectar la acción propuesta, la decisión de gobernanza, la decisión humana, el resultado de la ejecución y la prueba. Un seguimiento de cliente con nombre de herramienta y latencia cubre solo una parte de esa unidad.

Utilice un identificador de correlación en el cliente, la puerta de enlace, el motor de políticas, el servicio de aprobación, el servidor de herramientas, el sistema descendente, el seguimiento de auditoría y la exportación de evidencia. Concilie los recuentos en esas capas. Cada llamada descubierta debería terminar en un estado de gobernanza terminal, y cada efecto secundario ejecutado debería tener una decisión más un registro de resultado.

Sellar evidencia y preservar los límites de verificación¶

Evidence Factory de KLA exporta un paquete de evidencia sellado con un manifiesto, hashes de contenido, firmas, material de verificación y un límite de población documentado. Mantenga los registros sin procesar solo para agregarlos cuando sea posible y conserve las instantáneas de definición de políticas y herramientas necesarias para interpretarlos.

Las herramientas de evidencia de KLA crean un resumen SHA-256 del manifiesto canónico y lo firman con claves de inquilino y servicio ES256. El paquete incluye claves de verificación públicas y el verificador fuera de línea verifica las firmas del manifiesto, las firmas de los recibos de gobierno y los enlaces de pedidos, los gráficos hash del libro mayor aplicables, la inclusión de artefactos Merkle y el anclaje de la marca de tiempo. Cada verificación tiene un resultado explícito.

La prueba de integridad tiene un límite. Una firma válida demuestra que los bytes firmados coinciden con la clave y el manifiesto. La integridad requiere una población definida de forma independiente, reconciliación con los sistemas de origen y un ancla terminal o control equivalente donde una cadena podría truncarse. Indique los registros faltantes y las dependencias no disponibles como limitaciones en el informe de auditoría.

Utilice la muestra de linaje de ejecución para inspeccionar la forma de un artefacto de revisión. La guía de política como código explica la parte de creación y el Linaje de ejecución cubre la investigación y la reproducción.

Ejecute la auditoría MCP como un programa repetible¶

Definir el período, entornos, agentes, servidores, herramientas y acciones consecuentes en el alcance. Exporte el inventario aprobado y cada llamada de herramienta observada. Concilie las llamadas de los clientes con las decisiones de la puerta de enlace, los resultados de las herramientas, los recibos posteriores y las entradas de evidencia antes de seleccionar las muestras.

Pruebe poblaciones completas para afirmaciones deterministas, como resumen de servidor aprobado, herramienta reconocida, esquema válido, decisión de política presente, aprobación requerida cuando esté configurada, hash de argumento sin cambios, clave de idempotencia única, resultado de terminal y entrada de manifiesto. Muestra del juicio humano para conocer el fundamento, la autoridad del revisor, la suficiencia de la pantalla segura, el manejo de excepciones y las consecuencias comerciales.

Sesgar la muestra hacia herramientas nuevas o modificadas, escritura y acciones destructivas, recuperación de mundo abierto, datos confidenciales, límites entre inquilinos o entre regiones, anulaciones de aprobación, denegaciones, errores, reintentos, interrupciones de políticas, fallas de evidencia y las primeras llamadas después del lanzamiento de una herramienta o política.

• Prueba de población: cada llamada observada se asigna a un servidor aprobado y a una definición de herramienta.
• Prueba de control: cada llamada tiene una validación de terminal o resultado de política; cada llamada de esquema válido tiene una decisión impuesta según la política activa en ese momento.
• Prueba de aprobación: cada aprobación requerida precede a la ejecución y se vincula al mismo hash de argumento.
• Prueba de resultado: las llamadas ejecutadas se concilian con un efecto descendente y un registro de resultado.
• Prueba de integridad: la verificación del paquete pasa y las pruebas de manipulación negativas fallan como se esperaba.
• Prueba de integridad: se cuantifican los recuentos de fuentes, las exclusiones, los eventos tardíos, las exportaciones fallidas y las brechas no resueltas.

Fuentes primarias actuales y alcance¶

El comportamiento del protocolo en esta guía se verificó el 27 de julio de 2026 con la [especificación de herramientas MCP 2025-11-25] (https://modelcontextprotocol.io/specification/2025-11-25/server/tools), [especificación de autorización] (https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization), [especificación de ciclo de vida] (https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle), [especificación de tareas experimentales] (https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks) y [mejores prácticas de seguridad de MCP] (https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices).

La descripción y las mitigaciones del envenenamiento de herramientas se compararon con Microsoft para desarrolladores, [Protección contra ataques indirectos de inyección rápida en MCP] (https://developer.microsoft.com/blog/protecting-against-indirect-injection-attacks-mcp/). Se excluyen los recuentos de exploits, las reclamaciones en foros y los informes de fallos de productos sin avisos primarios.

MCP evoluciona a través de revisiones de protocolos anticuadas. Fije la revisión bajo auditoría, archive el esquema y las definiciones de herramientas recibidas en esa sesión y vuelva a verificar la especificación actual al cambiar el comportamiento del cliente, servidor o autorización.