Was bewiesen ist, und was nicht.
Eine Sicherheitsaussage, die sich nicht widerlegen lässt, ist keine Aussage, sondern Werbung. Diese Seite deklariert die Belegstufe jedes Profils mit denselben Worten, die der interne Plan verwendet, damit jemand von außen sie gegen das Veröffentlichte halten kann.
Die vier Stufen
Jedes Arbeitspaket schließt damit ab, eine davon zu deklarieren, neben PASS, FAIL oder SKIP und den Nennern. Es gibt keine fünfte Stufe und keine bequeme Mitte.
EntwurfSpezifiziert und geprüft. Ausgeführt wurde nichts. Zu beschreiben, wie etwas funktionieren würde, ergibt nie ein PASS.
simuliertGegen Fixtures ausgeführt, wobei Provider und Freigaben als Fixtures gekennzeichnet sind. Es ist keine Integration und wird auch nie so bezeichnet.
echte IntegrationGegen einen echten Provider ausgeführt, in einem autorisierten Konto, für genau das getestete Profil — und nur für dieses.
nicht bewertetEs lief keine Probe. Das ist der Ausgangswert, kein Versäumnis, und zählt nie als bestanden.
Heute bewiesen
Die Regeln oben existieren, um diese Liste ehrlich zu halten, nicht um keine zu haben. Jeder Punkt ist eine Eigenschaft des Codes, nachprüfbar ohne uns zu fragen.
Eine Autorisierung wird genau einmal verbraucht
Die Einmalnutzung ist ein Literal auf Typebene im Grant-Schema, und jeder andere Wert wird bei der Validierung abgelehnt. Es ist kein Zähler, den jemand herunterzuzählen nicht vergessen hat.
Receipts verifizieren ohne Netzwerk
Im gesamten Verifikationspfad gibt es null Netzwerkaufrufe. Ein Receipt, das in fünf Jahren geprüft wird, hängt weder davon ab, dass wir erreichbar sind, noch von einer veränderlichen Registry.
Ein Adapter kann das Gewährte nicht neu definieren
Der Provider-Client bekommt die Wirkung und einen Idempotenzschlüssel. Er bekommt nie das Grant oder die Autorität, hat also nichts, was er ausweiten könnte.
Eine Mutation wird nie blind wiederholt
Die Abstimmung ist der einzige zweite Aufruf an einen Provider. Schlägt die Abstimmung selbst fehl, wird das Ergebnis als unbestimmt festgehalten statt angenommen.
Die Cloud kann die lokale Obergrenze nicht ausweiten
Die Prüfung der lokalen Policy ist deny-only und legt Tenant, Gateway, Provider, Adapter-Digest, Autorität, akzeptierte Policy-Versionen, Ressourcenregeln und monetäre Limits fest. Sie setzt eine installierte signierte lokale Policy voraus, ohne die der Produktivmodus gar nicht erst startet.
Zwei davon hängen vom Deployment ab: die lokale Obergrenze braucht eine installierte signierte Policy — in der Sandbox ohne Policy gibt es keine Obergrenze — und die Isolation der Credentials hängt vom gewählten Konnektor und Deployment-Modus ab.
Die Regeln, die sie widerlegbar machen
- SKIP und nicht bewertet zählen nie als PASS.
- Eine Route ohne Probe bleibt nicht bewertet. Sie erbt keine Abdeckung von einer anderen Route.
- Das Abdeckungs-Manifest ist eine Behauptung, die der Test-Harness widerlegen können muss: gelingt einem Bypass eine Wirkung, wird die deklarierte Abdeckung zu widerlegt und das Gate schlägt fehl, auch wenn in der Datei geschützt steht.
- Die Anwendbarkeit wird festgelegt, bevor die Laufzeit existiert. Nichts kann nach einem Fehlschlag als nicht zutreffend markiert werden.
- Einen Konnektor mit MFA oder Quorum zu testen bescheinigt kein delegiertes Mehrschritt-Profil. Jede Aussage nennt die Kette und die Versionen, die sie getestet hat.
- Freigabe-Fixtures sind kein echtes MFA und kein echtes Quorum, und eine simulierte Freigabe wird nie als menschliche dargestellt.
Was ein Receipt feststellt
Ein Action Receipt beweist, was einen enrollten Guardian passiert hat, und das Ergebnis, das dieser Guardian feststellen konnte. Ein Timeout wird durch Rücklesen beim Provider abgestimmt, nie blind wiederholt, und ein mehrdeutiges Ergebnis bleibt unbestimmt, statt zum Erfolg aufgerundet zu werden.
Benannte Bedrohungen
Die, die wir eindämmen — mit den Lücken, die offen bleiben.
Tool Poisoning
Ein Host verändert Tool-Beschreibungen, damit das Modell sie mit manipulierten Argumenten aufruft. Der Tool-Katalog ist serverautoritativ — der Server liefert eine feste Liste und nimmt keine Tool-Definitionen vom Client an — und eine Allowlist begrenzt, was ein bestimmter Client aufrufen darf. Offene Lücke: das ausgelieferte Manifest ist noch nicht signiert, seine Integrität hängt also am Transport.
Feindlicher Host oder Client
Der Prozess, der den Agenten orchestriert, ist selbst feindlich. Scopes und die Tool-Allowlist begrenzen den Schaden, jeder Aufruf wird auditiert und Schlüssel lassen sich sofort widerrufen. Offene Lücke: ein API-Key ist eine Bearer-Credential, ein feindlicher Host mit einem solchen Key handelt also als der Tenant, bis er widerrufen wird. Kurzlebige delegierte Tokens existieren, um das einzuengen.
Prompt Injection über analysierte Inhalte
Eine Nachricht versucht, über den analysierten Inhalt Anweisungen einzuschleusen. Der Guard klassifiziert und analysiert; er führt nicht aus, was er liest, und die Antwort trägt extrahierte Fakten statt Anweisungen. Eine Wirkung außerhalb des Vertrags wird abgelehnt, egal ob irgendein Detektor die Injection gesehen hat.
Katalogänderung nach der Prüfung
Was freigegeben wurde, ist nicht das, was später startet. Ein gepinnter Snapshot wird gegen den aktuellen Katalog verglichen, und eine inhaltliche Änderung verlangt eine Prüfung, statt sich selbst anzuwenden.
Vortäuschung in einem Verzeichnis
Ein Dritter veröffentlicht einen gefälschten Eintrag. Der kanonische Endpunkt und das Manifest werden vom Dienst selbst ausgeliefert. Offene Lücke: bislang keine veröffentlichte Manifest-Signatur und keine Domain-Verifikation.
Außerhalb der Garantie
Benannt, nicht bloß impliziert.
- Die Administration des Hosts. Wer die Maschine kontrolliert, kontrolliert was darauf läuft.
- Ein kompromittierter Guardian oder Signaturschlüssel.
- Handlungen außerhalb des enrollten Ausführungspfads. Über sie schweigt das Receipt bauartbedingt.
- Ein Seitenkanal, den niemand beobachtet hat.
- Schaden, den das freigegebene Mandat ohnehin erlaubt hat. Autorisierung beweist weder Wahrheit noch Gutartigkeit noch Richtigkeit.
- Die rechtliche Inhaberschaft des Provider-Kontos, die kein Receipt feststellt.
Keine universelle Beobachtung
Es gibt keinen Blick auf den gesamten Kontext eines Hosts, seine Mails, sein Gedächtnis oder den Verkehr anderer MCP-Server. Bekannt sind der eigene Katalog der Bridge, die Aufrufe, die durch sie laufen, und ausdrücklich importierte Snapshots. Ein Konfigurations-Hash beschreibt ein Profil; er ist keine kryptografische Attestierung des Hosts. Ein Container allein beweist keine Isolation, solange sein Netzwerk und seine Mounts nicht gezeigt werden.
Zu Signaturen
Eine Manifest-Signatur bezeugt Integrität und Herkunft. Sie bezeugt keine Gutartigkeit, und kein Siegel — unseres eingeschlossen — macht einen MCP-Server sicher.
Wie sich eine Aussage auf dieser Seite ändert
Nicht durch Überschreiben. Eine neue Aussage über eine Fähigkeit wird gegen den Code geprüft und datiert, bevor sie erscheint, und die Prüftabelle liegt im Repository neben dem Text. Eine Seite, die eine Prüfung nicht bestanden hat, lässt den Fehlschlag sichtbar, statt still umgeschrieben zu werden — ein späterer Durchlauf erzeugt eine neue Version, statt das alte Ergebnis zu ersetzen. Es gibt kein finanziertes Bug-Bounty-Programm und kein unabhängiges Audit durch Dritte, und beides wird nicht angekündigt, bevor es existiert.
Status dieser Seite
Die Belegstufen und Regeln oben gelten heute. Die Tabelle pro Profil wird die beobachteten Ergebnisse jedes Arbeitspakets veröffentlichen, sobald diese abgeschlossen sind, mit Nennern, Versionen und Konfiguration. Bis ein Profil ein eigenes Ergebnis gegen einen echten Provider hat, wird es als simuliert oder nicht bewertet geführt — nie hochgerechnet aus einem Mock oder von einem anderen Konnektor.