Fortgeschritten•12–18 Stunden

Audit der Agent-Capability-Lieferkette

Prüfe Agent Skills, Plugins, MCP-Server und Tool-Kataloge als ausführbare Capability-Lieferkette mit Provenance, Installationsgrenzen, Schemas, Autorisierung, Cache, Versionsdrift und Widerruf.

KI-LieferketteMCP-SicherheitTool-ProvenanceAutorisierungVersionskontrolleWiderruf

Szenario

Aufgabe

Eine Organisation bindet Dutzende MCP-Server, Agent Skills und Plugins an. Der Tool-Katalog ändert sich unabhängig vom Application Release, lokale Installation kann Befehle ausführen und gecachte Metadaten können Redeployments überleben. Weise nach, welche Capabilities für einen konkreten Agent Release tatsächlich autorisiert sind und wie sie widerrufen werden.

Schrittweise Umsetzung

1. Capability-Inventar erstellen

Ergebnis: Der Release enthält keine unbekannten Tool-, Plugin- oder Skill-Abhängigkeiten.

Aufgaben

→MCP-Server und Tools erfassen
→Version, Digest und Provenance festhalten
→Command Boundaries lokaler Installationen markieren
→Read-, Write-, Egress- und Datenzugriffe klassifizieren

Prüfungen

✓Jede Capability hat einen Owner
✓Ein portables Paket gilt nicht allein wegen seines Formats als vertrauenswürdig

2. Protokollzugriff und Business Authority trennen

Ergebnis: Ein gültiger OAuth- oder MCP-Request bedeutet keine Berechtigung zu einer folgenreichen Aktion.

Aufgaben

→Issuer- und Client-Bindung prüfen
→Business-Permission-Scopes zuweisen
→Exact-Action Approvals hinzufügen
→Neue Tools standardmäßig verweigern

Prüfungen

✓Ein neues Tool erhält nicht automatisch Authority
✓Privilege Expansion erfordert ein separates Review

3. Drift- und Poisoning-Tests ausführen

Ergebnis: Änderungen an Metadaten, Schema oder Cache umgehen die Policy nicht.

Aufgaben

→Tool Description verändern
→Input Schema ändern
→Stale Cached Catalog erzeugen
→Header/Body-Mismatch simulieren
→Widerrufenes Tool nach Reconnect prüfen

Prüfungen

✓Nicht vertrauenswürdige Metadaten definieren keine Permission Policy
✓Eine widerrufene Capability kehrt nicht über stale Cache zurück

4. Revocation Drill durchführen

Ergebnis: Das Team kann eine kompromittierte Capability ohne vollständigen Blackout lokalisieren und widerrufen.

Aufgaben

→Alle betroffenen Agents finden
→Credentials und Scopes widerrufen
→Caches leeren
→In-Flight Work prüfen
→Auf eine Known-Good-Version zurückkehren

Prüfungen

✓Time-to-Revoke wird gemessen
✓Nach dem Restore besteht die Regression Suite

Akzeptanzkriterien

Die Capability BOM ist vollständig
Neue Capabilities sind deny-by-default
Protokollauthentifizierung ist von Business Authority getrennt
Tool-Metadaten- und Schema-Drift sind durch Tests abgedeckt
Der Revocation Drill weist Known-Good Recovery nach