MCP Audit: Secure and Govern Every Tool Call

What MCP standardizes, and where governance begins¶

In the current MCP specification, a client and server initialize a session, negotiate capabilities, and exchange protocol messages. A server with the tools capability can publish tool definitions through tools/list. Each definition can include a name, description, JSON Schema input, optional output schema, and behavior annotations. A client invokes one of those tools with tools/call.

That protocol sequence gives auditors stable objects to reference: protocol version, server implementation information, discovered tool definition, input schema, call identifier, arguments, result, and error state. Accountable ownership, consequence classification, enterprise authority, Decision Request routing, retention, and record-integrity proof belong at the host or gateway layer that sees every call.

The specification also sets an important trust rule. Clients must treat tool annotations as untrusted unless they come from a trusted server. Descriptions guide model tool selection and deserve the same review. Microsoft documents tool poisoning as an indirect prompt-injection path in which malicious instructions are placed inside tool descriptions. A production inventory therefore records the definition received from the server and the approved definition or digest that security reviewed.

Build the governed tool inventory before runtime¶

An audit population begins with the servers and tools an agent can actually reach. Record the server owner, transport, package or image version, source repository, deployment environment, authentication method, OAuth resource or audience, granted scopes, data destinations, egress paths, and the agents and Processes allowed to connect.

For every discovered tool, retain the full definition and a canonical digest. Review the name, description, input schema, output schema, annotations, and any declared task behavior. When a server publishes a changed list, pause newly added or materially changed tools until the owner approves the diff. A model should never gain a new write path because a remote description changed between sessions.

Classify the action from real behavior. Read-only, destructive, idempotent, and open-world annotations are useful review hints. The current MCP schema states that they are hints and gives cautious defaults. Network controls, sandboxing, scoped credentials, and policy enforcement carry the guarantee.

• Identity: stable server, tool, agent, principal, tenant, and owner identifiers.
• Supply chain: source, publisher, digest, signature status, dependency review, and approved update channel.
• Authority: exact tools, actions, destinations, data boundaries, OAuth scopes, and delegation expiry.
• Change control: approved definition digest, first-seen and last-reviewed times, and a diff for every list change.
• Runtime placement: environment, region, network boundary, secret reference, and egress policy.

Normalize every tools/call into one gate context¶

The gateway should parse the JSON-RPC request and add the facts the wire message cannot carry safely. The gate context needs tenant and execution identifiers, principal and agent identities, workflow and step, environment, canonical server and tool names, destination, tool arguments, data classification, model and prompt versions, and the current policy Release.

Validate the arguments against the approved input schema before policy evaluation. Hash the canonical arguments and keep sensitive values out of ordinary logs. The policy engine can evaluate selected structured fields when the tool schema declares them, while the evidence record retains a digest and controlled references to protected source data.

For HTTP transports, follow the MCP authorization specification: bind tokens to the intended resource, validate their audience at the MCP server, request the minimum scopes, and use separate downstream tokens for upstream APIs. For stdio, the MCP specification directs implementations to obtain credentials from the environment. In both cases, store token metadata and scope decisions in the audit record while excluding raw tokens and secrets.

{
  "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"
      ]
    }
  }
}

Evaluate policy before the tool can act¶

Authentication proves which principal reached the server. Authorization establishes which resource and scope that principal may use. The runtime policy determines whether this action may run here, with these arguments, in this Process, at this time.

Use a fail-closed default. KLA PolicyVersion contracts represent four outcomes. allow releases the call. warn releases it and creates a reviewable signal. require_approval pauses it and routes a Decision Request to an authorized group. block refuses it. Matched rules carry a stable reason code, the fields evaluated, a determinism classification, and configured remediation. The default decision blocks calls that match no rule and emits its generic fallback reason.

The example below matches the current KLA PolicyVersion schema and Policy Builder vocabulary. It uses tool names and the reviewer group from KLA’s current AML guided-demo template. Bind policy scope and tool names to the target Tool Catalog before publication. The default blocks every tool absent from an explicit rule.

{
  "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"
      }
    }
  ]
}

Make human approval a durable control¶

A durable approval control records that an authorized person reviewed a defined action under a defined policy before execution.

Show the reviewer the agent and principal, tool and destination, material arguments in a safe display, business consequence, policy basis, reason codes, evidence references, expiry, and the exact decision requested. Enforce maker-checker separation where one person proposed or initiated the action. Check the reviewer role when the decision is submitted.

Bind the Decision Request to the argument hash and gate identifier. After approval, re-drive the same logical call and verify the arguments against the sealed hash. A changed amount, destination, record ID, or evidence reference requires a new decision. Reject expired approvals and approvals issued for another tenant, environment, policy version, or tool.

MCP tools/call does not define an enterprise approval workflow. The host can pause through its durable workflow engine, return a structured approval-required marker, or use the experimental task-augmented flow when both parties negotiate support. The control objective stays constant: no side effect occurs until the authorized decision resolves, and retries cannot create duplicate effects.

• Pending: persist the Decision Request and stop before execution.
• Approved: verify authority, expiry, gate ID, policy version, and argument hash; execute once.
• Rejected: close the request and return a stable blocked outcome.
• Changed call: create a new request with a new hash and decision history.
• Timeout or outage: apply the published fail-closed outcome and preserve the failed attempt.

Control execution, output, and retries¶

Write an idempotency intent before a side-effecting call. Pass the idempotency key downstream when the tool supports it, then commit the outcome. A retry can return the committed result, resume a pending approval, or recover an in-flight intent under the same key. It cannot silently run the side effect twice.

Validate structured output against the approved output schema when the tool declares one. Treat returned text, links, embedded resources, images, and structured content as untrusted data. Apply redaction, content policy, destination controls, and an output gate before the model or another tool consumes the result.

Record protocol errors and tool execution errors separately. MCP tool results can carry isError: true, while malformed requests and unknown tools use protocol errors. Preserve both classes because they support different control tests: client validation, server availability, downstream business failure, and policy refusal.

Record the complete audit unit¶

One MCP audit record should connect the proposed action, governance decision, human decision, execution outcome, and proof. A client trace with tool name and latency covers only part of that unit.

Use one correlation identifier across the client, gateway, policy engine, approval service, tool server, downstream system, Audit Trail, and evidence export. Reconcile counts across those layers. Every discovered call should end in one terminal governance state, and every executed side effect should have one decision plus one outcome record.

Seal evidence and preserve verification limits¶

KLA’s Evidence Factory exports a Sealed Evidence Bundle with a manifest, content hashes, signatures, verification material, and a documented population boundary. Keep raw records append-only where possible and preserve the policy and tool-definition snapshots needed to interpret them.

KLA evidence tooling creates a SHA-256 digest of the canonical manifest and signs it with ES256 service and tenant keys. The bundle carries public verification keys, and the offline verifier checks the manifest signatures, governance receipt signatures and ordering links, applicable ledger hash graphs, artifact Merkle inclusion, and timestamp anchor. Each check has an explicit result.

Integrity proof has a boundary. A valid signature proves that signed bytes match the key and manifest. Completeness requires an independently defined population, reconciliation to source systems, and a terminal anchor or equivalent control where a chain could be truncated. State missing records and unavailable dependencies as limitations in the audit report.

Use the execution lineage sample to inspect the shape of a review artifact. The policy-as-code guide explains the authoring side, and Execution Lineage covers investigation and replay.

Run the MCP audit as a repeatable program¶

Define the period, environments, agents, servers, tools, and consequential actions in scope. Export the approved inventory and every observed tool call. Reconcile client calls to gateway decisions, tool outcomes, downstream receipts, and evidence entries before selecting samples.

Test full populations for deterministic assertions such as approved server digest, recognized tool, valid schema, policy decision present, approval required where configured, argument hash unchanged, unique idempotency key, terminal outcome, and manifest entry. Sample human judgment for rationale, reviewer authority, safe-display sufficiency, exception handling, and business consequence.

Bias the sample toward new or changed tools, write and destructive actions, open-world retrieval, sensitive data, cross-tenant or cross-region boundaries, approval overrides, denials, errors, retries, policy outages, evidence failures, and the first calls after a tool or policy Release.

• Population test: every observed call maps to an approved server and tool definition.
• Control test: every call has one terminal validation or policy outcome; every schema-valid call has one enforced decision under the policy active at that time.
• Approval test: every required approval precedes execution and binds to the same argument hash.
• Outcome test: executed calls reconcile to one downstream effect and one result record.
• Integrity test: bundle verification passes and negative tamper tests fail as expected.
• Completeness test: source counts, exclusions, late events, failed exports, and unresolved gaps are quantified.

Current primary sources and scope¶

Protocol behavior in this guide was checked on 27 July 2026 against the official MCP 2025-11-25 tools specification, authorization specification, lifecycle specification, experimental tasks specification, and MCP security best practices.

The tool-poisoning description and mitigations were checked against Microsoft for Developers, Protecting against indirect prompt injection attacks in MCP. Exploit counts, forum claims, and product-flaw reports without primary advisories are excluded.

MCP evolves through dated protocol revisions. Pin the revision under audit, archive the schema and tool definitions received in that session, and re-check the current specification when changing client, server, or authorization behavior.