MCP Fusion/Security and governance/Governance
Governance
Weisen Sie nach, dass Ihr Konnektor über Releases hinweg sicher blieb: Capability-Lockfile, Blast-Radius-Analyse, Contract-Diffing, Zero-Trust-Attestation und semantische Sonden machen die Oberfläche zu einem geprüften Artefakt.
Ein KI-Konnektor ändert sich, sobald jemand eine Beschreibung bearbeitet, ein Feld hinzufügt oder ein Tool umbenennt. Die Governance-Schicht von MCP Fusion macht diese Änderungen sichtbar, überprüfbar und rückgängig machbar, damit die Oberfläche, die Ihre Agenten aufrufen, ein Artefakt mit Historie ist und kein bewegliches Ziel.
Die Capability-Lockfile
mcpfusion lock
mcpfusion lock --check ./dist/server.jsmcpfusion lock hasht jede verhaltensrelevante Oberfläche: Tool-Namen, Parameter, Beschreibungen, Middleware-Abdeckung, Redaction-Pfade. Das Ergebnis ist mcpfusion.lock, eine Datei, die sich mit git diffen lässt. In CI schlägt fusion lock --check fehl, wenn das Verhalten abweicht, ohne dass eine geprüfte Lockfile-Aktualisierung vorliegt. Kombinieren Sie das mit dem Test-Harness aus Testing, und jede Änderung passiert zwei Tore.
Blast-Radius-Analyse
Das Entitlement-Scanning liest Ihr Bundle und meldet, was es tatsächlich erreichen kann: Dateisystem, Netzwerk, Subprozesse, eval, dazu Heuristiken zur Umgehung, die verschleierten Zugriff aufspüren. Es beantwortet die Frage, die ein Security-Reviewer stellt: Was darf dieser Konnektor tun?
Contract-Diffing
Jede Änderung an der Oberfläche wird klassifiziert:
| Urteil | Bedeutung |
|---|---|
| BREAKING | Ein Tool, Parameter oder Feld, auf das sich der Agent verlässt, hat sich geändert oder ist verschwunden |
| RISKY | Die Semantik hat sich bei gleicher Signatur geändert |
| SAFE | Additiv, Beschreibungen präzisiert |
| COSMETIC | Keine verhaltensrelevante Bedeutung |
Self healing context setzt darauf auf: Wenn eine Vertragsänderung die Gewohnheit eines Agenten bricht, enthält der Validierungsfehler das Delta, sodass sich der Agent im nächsten Zug korrigiert, statt wiederholt zu scheitern.
Zero-Trust-Attestation
Jedes deployte Bundle wird mit HMAC SHA256 signiert und zur Laufzeit verifiziert, sodass auf dem Edge byte für byte das läuft, was Ihre CI passiert hat. Eine Abweichung zwischen dem getesteten Artefakt und dem laufenden Artefakt wird erkannt, nicht einfach weggestellt.
Semantische Sonden
Auch Beschreibungen weichen ab. Eine semantische Sonde fragt ein Judge-Modell, ob die Beschreibung eines Tools noch bedeutet, was sie beim Verriegeln bedeutete, und versagt bei Abweichung nach dem Fail-closed-Prinzip. Sie erfasst die stille Umformulierung, die das Contract-Diffing als SAFE einstuft, aber die Agenten als RISKY erleben.
Wo die Konsole übernimmt
Zur Laufzeit wird die Governance in der Vinkius-Konsole für jeden deployten Konnektor fortgesetzt:
- Die Ansicht Access tokens zeigt, welche Clients den Konnektor nutzen und welche Tokens veraltet sind
- Die Ansicht Security posture bewertet die Abdeckung und zeigt ungeschützte Server
- Die Ansicht Request failures trennt Agent-, Upstream- und Vinkius-bedingte Fehler
- Die Ansicht Connector policy ist der Einstellungs-Editor, einschließlich des globalen Nothaltens
Governance ist eine Pipeline, keine Produktstufe: Lockfile beim Build, Attestation beim Deploy, Konsolensteuerung zur Laufzeit. Jede Schicht ist im Framework und im kostenlosen Hosting gratis enthalten.