Cosa è dimostrato, e cosa no.
Un’affermazione di sicurezza che non si può confutare non è un’affermazione, è pubblicità. Questa pagina dichiara il livello di prova di ogni profilo con le stesse parole che usa il piano interno, perché qualcuno dall’esterno possa confrontarlo con ciò che è stato pubblicato.
I quattro livelli
Ogni pacchetto di lavoro si chiude dichiarandone uno, accanto a PASS, FAIL o SKIP e ai denominatori. Non c’è un quinto livello né una comoda via di mezzo.
progettoSpecificato e revisionato. Non è stato eseguito nulla. Descrivere come funzionerebbe qualcosa non vale mai un PASS.
simulatoEseguito contro fixture, con provider e approvazioni identificati come fixture. Non è un’integrazione e non viene mai descritto come tale.
integrazione realeEseguito contro un provider reale, in un account autorizzato, per l’esatto profilo testato — e solo per quello.
non valutatoNon è stata eseguita alcuna probe. È il valore di partenza, non una dimenticanza, e non conta mai come superato.
Dimostrato oggi
Le regole qui sopra esistono per tenere onesta questa lista, non per non averne una. Ogni punto è una proprietà del codice, verificabile senza chiedercelo.
Un’autorizzazione si consuma una volta sola
L’uso singolo è un letterale a livello di tipo nello schema del grant, e qualsiasi altro valore viene rifiutato in validazione. Non è un contatore che qualcuno si è ricordato di decrementare.
I receipt si verificano senza rete
Non c’è alcuna chiamata di rete in tutto il percorso di verifica. Un receipt controllato fra cinque anni non dipende dal fatto che noi siamo raggiungibili, né da un registry mutabile.
Un adattatore non può ridefinire ciò che è stato concesso
Il client del provider riceve l’effetto e una chiave di idempotenza. Non riceve mai il grant né l’autorità, quindi non ha nulla da allargare.
Una mutazione non viene mai ritentata alla cieca
La riconciliazione è l’unica seconda chiamata a un provider. Se la riconciliazione stessa fallisce, l’esito viene registrato come indeterminato invece che dato per scontato.
Il cloud non può allargare il tetto locale
Il controllo di policy locale è deny-only e fissa tenant, gateway, provider, digest dell’adattatore, autorità, versioni di policy accettate, regole sulle risorse e limiti monetari. Richiede che sia installata una policy locale firmata, senza la quale la modalità produttiva si rifiuta di avviarsi.
Due di queste dipendono dal deployment: il tetto locale richiede una policy firmata installata — in sandbox senza policy non c’è tetto — e l’isolamento delle credenziali dipende dal connettore e dalla modalità di deployment scelti.
Le regole che la rendono confutabile
- SKIP e non valutato non contano mai come PASS.
- Una rotta senza probe resta non valutata. Non eredita la copertura di un’altra rotta.
- Il manifesto di copertura è un’affermazione che l’harness di test deve poter confutare: se un bypass ottiene un effetto, la copertura dichiarata diventa contraddetta e il gate fallisce, anche dove il file dice protetto.
- L’applicabilità si fissa prima che il runtime esista. Niente può essere marcato non applicabile dopo aver fallito.
- Testare un connettore con MFA o quorum non accredita un profilo delegato a più passi. Ogni affermazione nomina la catena e le versioni che ha testato.
- Le fixture di approvazione non sono MFA né quorum reali, e un’approvazione simulata non viene mai presentata come umana.
Cosa stabilisce un receipt
Un Action Receipt dimostra cosa è passato per un Guardian arruolato e l’esito che quel Guardian ha potuto stabilire. Un timeout si riconcilia rileggendo dal provider, non si ritenta mai alla cieca, e un esito ambiguo resta indeterminato invece di essere arrotondato a successo.
Minacce nominate
Quelle che mitighiamo, con le falle ancora aperte.
Tool poisoning
Un host altera le descrizioni dei tool perché il modello li chiami con argomenti manipolati. Il catalogo dei tool è autoritativo lato server — il server serve un elenco fisso e non accetta definizioni di tool dal client — e una allowlist limita cosa un dato client può invocare. Falla aperta: il manifesto servito non è ancora firmato, quindi la sua integrità poggia sul trasporto.
Host o client ostile
Il processo che orchestra l’agente è esso stesso ostile. Scope e allowlist dei tool limitano il danno, ogni chiamata è auditata e le chiavi si revocano subito. Falla aperta: una API key è una credenziale al portatore, quindi un host ostile che ne possieda una agisce come il tenant finché non viene revocata. I token delegati a vita breve esistono per stringere questo.
Prompt injection tramite il contenuto analizzato
Un messaggio tenta di iniettare istruzioni attraverso il contenuto analizzato. Il guard classifica e analizza; non esegue ciò che legge, e la risposta porta fatti estratti invece di istruzioni. Un effetto fuori contratto viene rifiutato che un rilevatore abbia visto l’injection o no.
Cambio di catalogo dopo la revisione
Ciò che hai approvato non è ciò che parte dopo. Uno snapshot fissato viene confrontato con il catalogo attuale e un cambiamento sostanziale chiede una revisione invece di applicarsi da solo.
Impersonificazione in una directory
Un terzo pubblica una scheda falsa. L’endpoint canonico e il manifesto sono serviti dal servizio stesso. Falla aperta: ancora nessuna firma del manifesto pubblicata né verifica del dominio.
Fuori garanzia
Nominato, non sottinteso.
- L’amministratore dell’host. Chi controlla la macchina controlla cosa ci gira.
- Un Guardian o una chiave di firma compromessi.
- Le azioni compiute fuori dal percorso di esecuzione arruolato. Su quelle il receipt tace per costruzione.
- Un canale laterale che nessuno ha osservato.
- Il danno che il mandato approvato già permetteva. Autorizzare non dimostra verità, benignità né correttezza.
- La proprietà legale dell’account del provider, che nessun receipt stabilisce.
Nessuna osservazione universale
Non esiste una vista dell’intero contesto di un host, della sua posta, della sua memoria o del traffico di altri server MCP. Ciò che si conosce è il catalogo proprio del bridge, le chiamate che lo attraversano e gli snapshot importati esplicitamente. Un hash di configurazione descrive un profilo; non è un’attestazione crittografica dell’host. Un container da solo, senza dimostrare la sua rete e i suoi mount, non prova l’isolamento.
Sulle firme
La firma di un manifesto attesta integrità e provenienza. Non attesta benignità, e nessun bollino — il nostro incluso — rende sicuro un server MCP.
Come cambia un’affermazione di questa pagina
Non riscrivendola. Una nuova affermazione di capacità viene verificata contro il codice e datata prima di comparire, e la tabella di verifica vive nel repository accanto al testo. Una pagina che ha fallito un controllo tiene il fallimento in vista invece di essere riscritta in silenzio — una corsa successiva crea una nuova versione invece di sostituire il risultato precedente. Non c’è alcun bug bounty finanziato né alcun audit indipendente di terze parti, e nessuno dei due verrà annunciato prima di esistere.
Stato di questa pagina
I livelli di prova e le regole qui sopra valgono oggi. La tabella per profilo pubblicherà i risultati osservati di ogni pacchetto di lavoro man mano che si chiudono, con denominatori, versioni e configurazione. Finché un profilo non ha un risultato proprio contro un provider reale, figura come simulato o non valutato — mai estrapolato da un mock né da un altro connettore.