Audit MCP: proteggi e controlla ogni chiamata allo strumento

Cosa standardizza MCP e dove inizia la governance¶

Nella specifica MCP attuale, un client e un server inizializzano una sessione, negoziano capacità e scambiano messaggi di protocollo. Un server con funzionalità strumenti può pubblicare definizioni di strumenti tramite tools/list. Ogni definizione può includere un nome, una descrizione, un input dello schema JSON, uno schema di output facoltativo e annotazioni sul comportamento. Un client richiama uno di questi strumenti con tools/call.

La sequenza del protocollo fornisce agli auditor oggetti stabili a cui fare riferimento: versione del protocollo, informazioni sull'implementazione del server, definizione dello strumento scoperto, schema di input, identificatore di chiamata, argomenti, risultato e stato di errore. La proprietà responsabile, la classificazione delle conseguenze, l'autorità aziendale, l'instradamento delle richieste decisionali, la conservazione e la prova dell'integrità dei record appartengono al livello host o gateway che riceve ogni chiamata.

La specifica stabilisce anche un'importante regola di fiducia. I client devono considerare le annotazioni degli strumenti come non attendibili a meno che non provengano da un server attendibile. Le descrizioni guidano la selezione degli strumenti del modello e meritano la stessa recensione. Microsoft documenta l'avvelenamento da strumenti come un percorso indiretto di prompt-injection in cui le istruzioni dannose vengono inserite nelle descrizioni degli strumenti. Un inventario di produzione pertanto registra la definizione ricevuta dal server e la definizione approvata o il digest sottoposto a revisione di sicurezza.

Costruisci l'inventario degli strumenti regolamentati prima del runtime¶

Una popolazione di audit inizia con i server e gli strumenti che un agente può effettivamente raggiungere. Registra il proprietario del server, il trasporto, la versione del pacchetto o dell'immagine, il repository di origine, l'ambiente di distribuzione, il metodo di autenticazione, la risorsa o il pubblico OAuth, gli ambiti concessi, le destinazioni dei dati, i percorsi di uscita e gli agenti e i processi autorizzati a connettersi.

Per ogni strumento scoperto, conservare la definizione completa e un riepilogo canonico. Esamina il nome, la descrizione, lo schema di input, lo schema di output, le annotazioni e qualsiasi comportamento dell'attività dichiarata. Quando un server pubblica un elenco modificato, metti in pausa gli strumenti appena aggiunti o modificati materialmente finché il proprietario non approva la differenza. Un modello non dovrebbe mai ottenere un nuovo percorso di scrittura perché una descrizione remota è cambiata tra le sessioni.

Classificare l'azione dal comportamento reale. Le annotazioni di sola lettura, distruttive, idempotenti e open-world sono utili suggerimenti per la revisione. L'attuale schema MCP afferma che si tratta di suggerimenti e fornisce impostazioni predefinite caute. I controlli di rete, il sandboxing, le credenziali con ambito e l'applicazione delle policy sono la garanzia.

• Identità: identificatori stabili di server, strumento, agente, entità, tenant e proprietario.
• Catena di fornitura: fonte, editore, digest, stato della firma, revisione delle dipendenze e canale di aggiornamento approvato.
• Autorità: strumenti, azioni, destinazioni, limiti dei dati, ambiti OAuth esatti e scadenza della delega.
• Controllo delle modifiche: sintesi delle definizioni approvate, orari della prima visualizzazione e dell'ultima revisione e un differenziale per ogni modifica dell'elenco.
• Posizionamento runtime: ambiente, regione, confine di rete, riferimento segreto e policy di uscita.

Normalizza ogni strumento/chiamata in un contesto di gate¶

Il gateway dovrebbe analizzare la richiesta JSON-RPC e aggiungere i fatti che il messaggio wire non può trasportare in modo sicuro. Il contesto del gate necessita di identificatori di tenant e di esecuzione, identità di entità principale e agente, flusso di lavoro e passaggio, ambiente, nomi di server e strumenti canonici, destinazione, argomenti dello strumento, classificazione dei dati, versioni di modello e prompt e la versione corrente della policy.

Convalidare gli argomenti rispetto allo schema di input approvato prima della valutazione della policy. Elimina gli argomenti canonici e mantieni i valori sensibili fuori dai log ordinari. Il motore delle policy può valutare i campi strutturati selezionati quando lo schema dello strumento li dichiara, mentre il record delle prove conserva un digest e riferimenti controllati ai dati di origine protetti.

Per i trasporti HTTP, seguire la specifica di autorizzazione MCP: associare i token alla risorsa prevista, convalidare il relativo pubblico sul server MCP, richiedere gli ambiti minimi e utilizzare token downstream separati per le API upstream. Per stdio, la specifica MCP indica alle implementazioni di ottenere credenziali dall'ambiente. In entrambi i casi, archivia i metadati dei token e le decisioni sull'ambito nel record di controllo escludendo token e segreti non elaborati.

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

Valutare la politica prima che lo strumento possa agire¶

L'autenticazione dimostra quale entità ha raggiunto il server. L'autorizzazione stabilisce quale risorsa e ambito può essere utilizzato dall'entità. La politica di runtime determina se questa azione può essere eseguita qui, con questi argomenti, in questo processo, in questo momento.

Utilizzare un'impostazione predefinita con chiusura in errore. I contratti KLA PolicyVersion rappresentano quattro risultati. allow rilascia la chiamata. warn lo rilascia e crea un segnale rivedibile. require_approval lo mette in pausa e instrada una richiesta di decisione a un gruppo autorizzato. blocca lo rifiuta. Le regole abbinate contengono un codice motivo stabile, i campi valutati, una classificazione deterministica e una correzione configurata. La decisione predefinita blocca le chiamate che non corrispondono ad alcuna regola ed emette il motivo di fallback generico.

L'esempio seguente corrisponde allo schema PolicyVersion KLA corrente e al vocabolario del Policy Builder. Utilizza i nomi degli strumenti e il gruppo di revisori dell'attuale modello di demo guidata AML di KLA. Associa l'ambito della policy e i nomi degli strumenti al catalogo degli strumenti di destinazione prima della pubblicazione. L'impostazione predefinita blocca ogni strumento assente da una regola esplicita.

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

Rendere l’approvazione umana un controllo duraturo¶

Un controllo di approvazione durevole registra che una persona autorizzata ha esaminato un'azione definita in base a una politica definita prima dell'esecuzione.

Mostra al revisore l'agente e il mandante, lo strumento e la destinazione, gli argomenti materiali in una visualizzazione sicura, le conseguenze aziendali, la base politica, i codici motivo, i riferimenti alle prove, la scadenza e l'esatta decisione richiesta. Applicare la separazione maker-checker laddove una persona ha proposto o avviato l'azione. Controlla il ruolo del revisore quando viene inviata la decisione.

Associa la Decision Request all'hash dell'argomento e all'identificatore del gate. Dopo l'approvazione, ripetere la stessa chiamata logica e verificare gli argomenti rispetto all'hash sigillato. Un importo, una destinazione, un ID record o un riferimento di prova modificati richiedono una nuova decisione. Rifiutare le approvazioni scadute e quelle rilasciate per un altro tenant, ambiente, versione della policy o strumento.

MCP tools/call non definisce un flusso di lavoro di approvazione aziendale. L'host può mettere in pausa il suo motore di flusso di lavoro durevole, restituire un indicatore strutturato di richiesta di approvazione o utilizzare il [flusso potenziato dalle attività] sperimentale (https://modelcontextprotocol.io/specification/2025-11-25/basic/utilities/tasks) quando entrambe le parti negoziano il supporto. L'obiettivo di controllo rimane costante: non si verifica alcun effetto collaterale finché la decisione autorizzata non viene risolta e i nuovi tentativi non possono creare effetti duplicati.

• In sospeso: persiste la richiesta di decisione e interrompela prima dell'esecuzione.
• Approvato: verifica autorità, scadenza, ID gate, versione policy e hash argomento; eseguire una volta.
• Rifiutato: chiude la richiesta e restituisce un risultato stabile bloccato.
• Chiamata modificata: crea una nuova richiesta con un nuovo hash e cronologia delle decisioni.
• Timeout o interruzione: applica il risultato di chiusura con errore pubblicato e preserva il tentativo non riuscito.

Controllare l'esecuzione, l'output e i tentativi¶

Scrivi un intento di idempotenza prima di una chiamata con effetti collaterali. Passa la chiave di idempotenza a valle quando lo strumento la supporta, quindi conferma il risultato. Un nuovo tentativo può restituire il risultato confermato, riprendere un'approvazione in sospeso o recuperare un intento in volo con la stessa chiave. Non può eseguire silenziosamente l'effetto collaterale due volte.

Convalida l'output strutturato rispetto allo schema di output approvato quando lo strumento ne dichiara uno. Tratta il testo restituito, i collegamenti, le risorse incorporate, le immagini e il contenuto strutturato come dati non attendibili. Applica la redazione, la policy dei contenuti, i controlli di destinazione e un gate di output prima che il modello o un altro strumento utilizzi il risultato.

Registrare separatamente gli errori di protocollo e gli errori di esecuzione dello strumento. I risultati dello strumento MCP possono contenere isError: true, mentre le richieste non valide e gli strumenti sconosciuti utilizzano errori di protocollo. Conserva entrambe le classi perché supportano diversi test di controllo: convalida del client, disponibilità del server, fallimento del business downstream e rifiuto della policy.

Registrare l'unità di audit completa¶

Un record di audit MCP dovrebbe collegare l'azione proposta, la decisione di governance, la decisione umana, il risultato dell'esecuzione e la prova. Una traccia client con nome strumento e latenza copre solo parte di tale unità.

Utilizza un identificatore di correlazione tra client, gateway, motore delle policy, servizio di approvazione, server degli strumenti, sistema downstream, audit trail ed esportazione delle prove. Riconciliare i conteggi tra questi livelli. Ogni chiamata rilevata dovrebbe terminare in uno stato di governance del terminale e ogni effetto collaterale eseguito dovrebbe avere una decisione più un record di risultato.

Sigillare le prove e preservare i limiti di verifica¶

L'Evidence Factory di KLA esporta un pacchetto di prove sigillate con un manifest, hash dei contenuti, firme, materiale di verifica e un confine di popolazione documentato. Mantieni i record non elaborati di sola aggiunta, ove possibile, e preserva le policy e gli snapshot di definizione degli strumenti necessari per interpretarli.

Gli strumenti di prova KLA creano un digest SHA-256 del manifesto canonico e lo firmano con il servizio ES256 e le chiavi del tenant. Il pacchetto contiene chiavi di verifica pubbliche e il verificatore offline controlla le firme manifest, le firme delle ricevute di governance e i collegamenti agli ordini, i grafici hash del registro applicabili, l'inclusione degli artefatti Merkle e l'ancoraggio del timestamp. Ogni controllo ha un risultato esplicito.

La prova di integrità ha un confine. Una firma valida dimostra che i byte firmati corrispondono alla chiave e al manifest. La completezza richiede una popolazione definita in modo indipendente, la riconciliazione con i sistemi di origine e un ancoraggio terminale o un controllo equivalente in cui una catena possa essere troncata. Indicare i record mancanti e le dipendenze non disponibili come limitazioni nel rapporto di audit.

Utilizza l'esempio di derivazione di esecuzione per esaminare la forma di un artefatto di revisione. La guida alla policy-as-code spiega il lato di creazione e Execution Lineage copre l'indagine e la riproduzione.

Esegui l'audit MCP come un programma ripetibile¶

Definire il periodo, gli ambienti, gli agenti, i server, gli strumenti e le azioni consequenziali nell'ambito. Esporta l'inventario approvato e ogni chiamata allo strumento osservata. Riconciliare le chiamate dei clienti con le decisioni del gateway, i risultati degli strumenti, le ricevute a valle e le voci delle prove prima di selezionare i campioni.

Testare popolazioni complete per asserzioni deterministiche come digest del server approvato, strumento riconosciuto, schema valido, decisione politica presente, approvazione richiesta dove configurata, hash dell'argomento invariato, chiave di idempotenza univoca, risultato del terminale e voce del manifest. Esempio del giudizio umano in termini di logica, autorità del revisore, sufficienza di visualizzazione sicura, gestione delle eccezioni e conseguenze aziendali.

Distorcere il campione verso strumenti nuovi o modificati, azioni di scrittura e distruttive, recupero open-world, dati sensibili, confini tra tenant o tra regioni, ignorazioni di approvazione, rifiuti, errori, nuovi tentativi, interruzioni delle policy, errori di prove e le prime chiamate dopo il rilascio di uno strumento o di una policy.

• Test sulla popolazione: ogni chiamata osservata viene mappata a una definizione di server e strumento approvata.
• Test di controllo: ogni chiamata ha una convalida del terminale o un risultato della policy; a ogni chiamata valida per lo schema viene applicata una decisione in base alla policy attiva in quel momento.
• Test di approvazione: ogni approvazione richiesta precede l'esecuzione e si lega allo stesso hash dell'argomento.
• Test dei risultati: le chiamate eseguite si riconciliano con un effetto downstream e un record di risultati.
• Test di integrità: la verifica del pacchetto supera i risultati e i test di manomissione negativi falliscono come previsto.
• Test di completezza: vengono quantificati i conteggi delle fonti, le esclusioni, gli eventi tardivi, le esportazioni non riuscite e le lacune irrisolte.

Fonti primarie attuali e ambito¶

Il comportamento del protocollo in questa guida è stato controllato il 27 luglio 2026 rispetto alla specifica degli strumenti MCP 2025-11-25, specifica dell'autorizzazione, specifica del ciclo di vita, specifica delle attività sperimentali e migliori pratiche di sicurezza MCP.

La descrizione e le attenuazioni dell'avvelenamento degli strumenti sono state verificate rispetto a Microsoft for Developers, Protezione dagli attacchi indiretti di prompt injection in MCP. Sono esclusi i conteggi degli exploit, le rivendicazioni nei forum e le segnalazioni di difetti del prodotto senza avvisi primari.

MCP si evolve attraverso revisioni del protocollo datate. Blocca la revisione sotto controllo, archivia le definizioni di schema e strumento ricevute in quella sessione e ricontrolla la specifica corrente quando si modifica il comportamento del client, del server o dell'autorizzazione.