Sicurezza del gateway MCP: prova che ogni chiamata allo strumento attraversa il cancello

La sicurezza del gateway MCP non viene stabilita inserendo un proxy nel diagramma dell'architettura. L'impostazione predefinita difendibile è più rigorosa: dimostrare che ogni chiamata dello strumento di produzione protetto ha attraversato il gateway previsto, ha utilizzato la revisione della policy prevista, ha avuto un'identità convalidata e un ambito di privilegio minimo, ha prodotto una ricevuta di audit e si è conclusa con un effetto verificato o uno stato di attesa esplicito . Questa distinzione è importante perché “gateway” descrive un posizionamento, non un risultato. Gli attuali risultati di ricerca negli Stati Uniti mescolano prodotti gateway, confronti, spiegazioni sull'architettura e affermazioni sulla sicurezza. La loro promessa comune è un punto di controllo centrale tra agenti e server MCP. La questione operativa è se quel punto effettivamente possedesse una particolare chiamata. ILSpecifica di autorizzazione MCPdefinisce l'autorizzazione per i trasporti HTTP, i metadati delle risorse protette, il rilevamento e la selezione dell'ambito. Quello del protocollomigliori pratiche di sicurezzarichiedere agli implementatori di considerare i rischi di confusione, la convalida del pubblico dei token, i rischi di pass through dei token, il consenso e la verificabilità. Nessuno dei due documenti trasforma la mera presenza di un intermediario in una prova che ogni tratta sia controllata. Definire il contratto di prova prima di instradare il traffico Inizia con un manifest del percorso abbastanza piccolo da poter essere spedito insieme alla configurazione del gateway: Il manifest crea cinque asserzioni verificabili: 1. la richiesta è passata attraverso il gateway denominato anziché un URL diretto del server; 2. il gateway ha convalidato un carico di lavoro o un'identità utente non segreta; 3. la decisione è arrivata dalla prevista, nuova revisione politica; 4. l'ambito concesso copriva lo strumento selezionato senza ampliare silenziosamente l'accesso; 5. il gateway ha emesso una ricevuta di audit che può essere unita al risultato downstream. L'asserzione del percorso non è teorica. Cloudflare è attualeDocumentazione dei portali server MCPdescrive un percorso gateway opzionale per le chiamate agli strumenti, mentre la sincronizzazione in background si connette direttamente ai server upstream. Avverte inoltre che un utente bloccato può comunque utilizzare l'URL diretto di un server upstream a meno che non venga applicata l'autenticazione su quel server. Si tratta di comportamenti legittimi specifici del prodotto, non di regole MCP universali, ma dimostrano perché un inventario deve includere tutti i percorsi anziché presupporre che un portale o un gateway abbia eliminato le porte secondarie. Registrare una busta priva di contenuto per decisione. Non necessita di prompt, argomenti di strumenti, corpi di risultati, token di accesso o segreti: Gli identificatori opachi sono sufficienti per testare la proprietà del percorso, l'applicazione dell'identità, l'aggiornamento delle policy, la copertura dell'ambito, lo stato di approvazione e la continuità della ricezione. Mantieni i valori segreti alla fonte. Se un incidente richiede l'ispezione del contenuto, trattalo come un flusso di lavoro separato ed esplicitamente autorizzato con il proprio limite di conservazione. L'autorizzazione e l'applicazione delle policy sono correlate ma non intercambiabili. La specifica MCP afferma che l'autorizzazione è facoltativa per un'implementazione; quando è supportata l'autorizzazione HTTP, il server protetto funge da server di risorse OAuth. Un gateway pertanto non può produrre una prova notando l'esistenza di un token al portatore. Deve convalidare la risorsa e l’identità previste, valutare la politica relativa allo strumento pertinente e preservare prove non segrete sufficienti per spiegare la decisione. Le linee guida sulla sicurezza MCP identificano esplicitamente il token passthrough come un anti pattern perché può aggirare i controlli e danneggiare la responsabilità. Rigioca otto stati che "consentito" nasconde L'incontro allegato contiene otto richieste sintetiche. Il suo classificatore applica le porte in ordine operativo: Eseguilo localmente: Ogni verdetto richiede una risposta limitata diversa: Verdetto Cosa dicono le prove Azione successiva GATEWAY BYPASS La chiamata protetta ha utilizzato un'altra identità di percorso o gateway Client di inventario ed endpoint upstream; chiudere o governare separatamente il percorso diretto IDENTITY NOT ENFORCED Il percorso era centrale, ma il chiamante non è stato convalidato Rifiuta le chiamate di produzione anonime e correggi il carico di lavoro o l'identità dell'utente al limite POLICY DRIFT La decisione ha utilizzato una vecchia revisione o prove obsolete Riconciliare il gateway in esecuzione con l'elemento della policy approvata prima di riprovare AUTHORIZATION GAP Lo strumento o l'ambito richiesto non corrispondevano alla decisione Negare la chiamata, ridurre l'ambito e aggiungere un caso di regressione a livello di strumento AUDIT GAP La chiamata potrebbe essere stata consentita, ma non esiste alcuna ricevuta collegabile Riparare il percorso di registrazione/esportazione; mantenere il verdetto sconosciuto piuttosto che verde EFFECT UNCERTAIN Il trasporto o il completamento dell'attrezzatura non hanno dimostrato la destinazione Leggere la destinazione prima di riprovare, soprattutto dopo un timeout WAITING Un'azione protetta ha una dipendenza di approvazione denominata Avvisare il proprietario e preservare la scadenza; non etichettare l'agente bloccato HEALTHY Il percorso, l'identità, la politica, l'ambito, l'audit, l'approvazione e l'effetto concordano Conservare le ricevute attraverso la finestra di revisione dell'incidente La precedenza impedisce che una comoda attesa di approvazione nasconda un bypass o una politica obsoleta. WAITING è disponibile solo dopo il superamento dei gate di percorso, identità, policy, autorizzazione e controllo. Allo stesso modo, un effetto downstream riuscito non giustifica una chiamata che ha oltrepassato il percorso di controllo. L'esperimento è volutamente privo di contenuti. Controlla un contratto normalizzato, non un prodotto gateway live. Mappa i campi del tuo gateway sull'apparecchiatura anziché copiare i nomi dei campi come se MCP li standardizzasse. Il protocollo definisce i messaggi e il comportamento di autorizzazione; gli identificatori di revisione delle politiche del gateway, le forme delle ricevute di audit e i verificatori di destinazione rimangono scelte di implementazione. Autorizzazione separata dall'effetto risultante Una decisione di autorizzazione dimostra solo che una policy ha consentito un tentativo. Ciò non dimostra che lo strumento sia stato eseguito una volta, abbia cambiato la destinazione prevista o abbia prodotto il risultato richiesto. Per una mutazione, unisci la ricevuta del gateway a una ricevuta di destinazione: Ciò è particolarmente importante dopo un timeout. Un nuovo tentativo perché il gateway non ha ricevuto una risposta può duplicare un effetto di cui il sistema upstream ha già eseguito il commit. EFFECT UNCERTAIN indica all'operatore di riconciliare prima la destinazione. Un gateway può limitare la velocità o autorizzare un nuovo tentativo, ma la destinazione è solitamente la fonte più forte per stabilire se esiste l'effetto originale. Per gli strumenti di sola lettura, il risultato può essere un controllo dello schema, un'asserzione di aggiornamento o un confronto deterministico con i campi obbligatori dell'attività. Per le scritture, preferisci una rilettura dell'API, una versione dell'oggetto immutabile, un ID messaggio del provider, un hash di commit più controlli o un'altra ricevuta di proprietà della destinazione. Il risultato di successo JSON RPC di uno strumento è più debole quando il risultato promesso si trova altrove. Un'implementazione pratica può rimanere ristretta: 1. Scegli un server MCP di produzione e uno strumento ad alto impatto. 2. Enumerare ogni endpoint client e indirizzare l'URL upstream che può raggiungerlo. 3. Aggiungi l'identità del gateway e la revisione della policy nelle prove di distribuzione. 4. Invia un sondaggio consentito e uno negato con ID di richiesta opachi. 5. Verifica l'identità del chiamante, l'ambito richiesto, la decisione sullo strumento, l'aggiornamento e una ricevuta di audit per entrambi. 6. Provare la via diretta documentata e dimostrare che è bloccata o disciplinata esplicitamente. 7. Esercita una chiamata con richiesta di approvazione e conservala come WAITING fino a quando un proprietario nominato non decide. 8. Simulare un timeout dopo l'effetto upstream, quindi dimostrare che il runbook legge la destinazione prima di riprovare. 9. Ripetere le analisi dopo le modifiche al gateway, al provider di identità, alla policy, al client o al server MCP. Ci sono dei limiti. Questa soluzione non testa il parser, il motore DLP, le difese di prompt injection o lo scanner di vulnerabilità di un particolare fornitore. Ciò non dimostra che un gateway centrale sia l'architettura giusta per ogni server STDIO locale. Un processo locale potrebbe necessitare di controlli a livello di host anziché di un gateway di rete. Inoltre, non rende Sidewisp un modello o un gateway di strumenti richiesto. Il ruolo previsto da Sidewisp è adiacente: portare raggiungibilità, progresso, strumenti, risultati, tempo e prove di budget in una visione della salute dell'agente e preservare l'autorità umana riguardo al recupero. Sidewisp è attualmente in anteprima privata. L'esperienza dal vivo è un sito Web ad accesso anticipato e una dimostrazione interattiva; non vengono forniti un adattatore gateway MCP di produzione, un motore di monitoraggio in tempo reale e un esecutore di ripristino automatizzato. Utilizza la ricevuta di applicazione con il tuo gateway attuale e i sistemi di destinazione anziché dare per scontato che Sidewisp li monitori o li risolva attualmente. La risoluzione è concreta: inventariare i percorsi, bloccare il gate e la policy, verificare l'identità e l'ambito del privilegio minimo, richiedere una ricevuta di audit unibile, preservare la legittima attesa e controllare la destinazione prima di dichiarare il successo. La sicurezza del gateway MCP diventa prova operativa solo quando il percorso di controllo e l'effetto coincidono.