Werkzeuge an der Leine

Was ist MCP?

MCP steht für Model Context Protocol – ein offener Standard, über den ein KI-Agent mit Werkzeugen und Datenquellen spricht. Statt jedes Werkzeug fest in den Agenten einzubauen, bietet jeder Werkzeug-Server seine Fähigkeiten über eine einheitliche Schnittstelle an. Der Agent fragt: «Welche Werkzeuge hast du?», bekommt eine maschinenlesbare Beschreibung zurück und kann sie ab da nutzen.

Der Vorteil ist Entkopplung. Ein Werkzeug lässt sich hinzufügen, ändern oder entfernen, ohne den Agenten anzufassen – so wie man ein USB-Gerät einsteckt, ohne den Computer umzubauen. Für uns heisst das: Jede Fähigkeit von Botster ist ein eigener, gekapselter Baustein.

Wie wir Skills als MCP-Server bauen

Bei uns heisst jeder dieser Bausteine Skill, und jeder Skill ist ein eigenständiger Dienst in seinem eigenen Container – der Security-Skill genauso wie der Ticket- oder der Dokumenten-Skill. Das hat drei bewusste Konsequenzen:

• Isolation. Fällt ein Skill aus oder wird kompromittiert, ist der Schaden auf diesen einen Baustein begrenzt – nicht auf den ganzen Agenten.
• Dynamische Erkennung. Der Agent lädt die Werkzeugliste eines Skills zur Laufzeit (mit kurzem Cache), statt sie fest verdrahtet zu haben. Neue Werkzeuge erscheinen, sobald der Skill sie anbietet.
• Begrenzter Netzzugang. Skills laufen in einem abgeschotteten Netzwerk ohne freien Internet-Ausgang. Jeder ausgehende Verbindungsversuch muss durch einen Filter mit ausdrücklicher Erlaubnisliste. Ein Werkzeug, das heimlich Daten nach aussen schickt, scheitert an dieser Wand – nicht an unserem Vertrauen.

So weit die Mechanik. Nützlich wird sie erst mit der zweiten Hälfte.

Die Governance: nicht ob ein Werkzeug existiert, sondern was es darf

Werkzeuge sind nicht gleich. «Ein SSL-Zertifikat prüfen» ist harmlos. «Ein Ticket schliessen» verändert etwas. «Eine Konfiguration ausrollen» kann etwas kaputt machen. Wir behandeln sie deshalb nicht gleich, sondern stufen jedes einzelne Werkzeug nach Risiko ein:

→ Tabelle seitlich wischen

Dem gegenüber steht die Autonomie-Stufe, die pro Kunde festlegt, wie viel der Agent selbstständig tun darf:

• L0 – assistiert: gar keine Werkzeuge, reine Antworten.
• L1 – lesend autonom: nur R1-Werkzeuge.
• L2 – geringes Schreiben: R1 und R2 automatisch (unsere Voreinstellung).
• L3 – mit Freigabe: R1/R2 automatisch, R3 nur nach menschlicher Bestätigung.

Die Regel dahinter ist streng und einfach: Ist das Werkzeug-Risiko höher als die Autonomie-Stufe, wird der Aufruf abgelehnt – nicht «trotzdem versucht». Liegt es genau eine Stufe darüber und ist Freigabe möglich, hält der Agent an und fragt einen Menschen. Im Zweifel passiert nichts.

Der Mensch in der Schleife

Verlangt ein Werkzeug eine Freigabe, stoppt der Agent mitten im Vorgang. Er führt nichts aus, sondern legt die geplante Aktion offen und wartet. Der Nutzer bestätigt mit einem einfachen «ja» (oder lehnt ab) – in Deutsch, Französisch, Italienisch oder Englisch. Erst dann läuft der Aufruf, und erst dann sieht das Modell das Ergebnis.

Drei Details, die zeigen, dass das ernst gemeint ist:

• Ablehnung hat Konsequenzen. Wer ablehnt, stoppt nicht nur diesen einen Aufruf – der Agent stuft seine Autonomie herab und wird vorsichtiger. Häufen sich Ablehnungen, geht eine Eskalation an den Verantwortlichen.
• Keine offene Warteschleife. Bleibt eine Freigabe unbeantwortet, läuft sie nach einigen Minuten ab und wird eskaliert – sie verschwindet nicht still.
• Jede Entscheidung ist aktenkundig. Freigabe-Anfrage, Erteilung, Ablehnung, Zeitüberschreitung – alles wird als Audit-Ereignis festgehalten.

Least Privilege: jeder sieht nur, was ihn betrifft

Zwei weitere Leitplanken begrenzen, was überhaupt erreichbar ist:

• Strikte Kontext-Trennung. Jeder Werkzeug-Aufruf trägt den Mandanten, den Nutzer und dessen Team mit sich. Zwischengespeicherte Ergebnisse sind an genau diesen Kontext gebunden – die Daten des einen Nutzers landen nie beim anderen, auch nicht versehentlich über einen geteilten Cache.
• Nur die relevanten Werkzeuge. Statt dem Modell den ganzen Werkzeugkasten vorzulegen, filtern wir vorab auf die für die Anfrage passenden. Das senkt nicht nur Kosten, sondern auch die Angriffsfläche: Was nicht angeboten wird, kann nicht versehentlich gewählt werden.

Das Beispiel: der Security-Skill

Nichts illustriert das besser als ein Werkzeug, das Systeme prüft. Unser Security-Skill bietet genau solche Fähigkeiten: eine URL auf Sicherheits-Header scannen, ein SSL/TLS-Zertifikat validieren, DNS- und E-Mail-Sicherheit (SPF/DKIM/DMARC) prüfen, den Bedrohungs- und Sperrstatus einer IP abfragen und daraus einen umfassenden Sicherheitsbericht erzeugen.

Hier greift die Governance sichtbar:

• Die Prüf-Werkzeuge sind als R1 eingestuft (sie lesen und prüfen, verändern nichts), der zusammenfassende Bericht als R2. Kein Werkzeug dieses Skills ist R3 – er ist ein Scanner, kein Eingreifer. Ein Sicherheits-Audit darf niemals selbst etwas am System verändern.
• Damit läuft das reine Scannen unter unserer Standard-Stufe (L2) ohne Reibung – aber jeder Aufruf ist protokolliert, mit Werkzeug, Parametern (persönliche Daten geschwärzt) und Ergebnis-Status.
• Würde der Skill je ein eingreifendes Werkzeug bekommen – etwa «eine IP automatisch sperren» –, bekäme es zwingend die Stufe R3 und damit die Pflicht zur menschlichen Freigabe. Das ist kein nachträglicher Schalter, sondern in die Risiko-Einstufung eingebaut.

Wo wir stehen

Wir beschreiben, was ist – nicht, was sein könnte:

• Der Security-Skill ist neu und gerade erst in die Standard-Ausstattung aufgenommen. Die Perimeter-Prüfungen (URL, SSL, DNS, E-Mail, IP-Reputation, Bericht) sind fertig, registriert und über MCP nutzbar.
• Eine zweite Ausbaustufe – die interne Härtungs- und Bestandsprüfung über unsere Monitoring-Infrastruktur – ist im Code angelegt, aber noch nicht freigeschaltet. Sie kommt, wenn die Anbindung sauber steht. Bis dahin behaupten wir sie nicht.
• Die Risiko-Einstufung, die Autonomie-Stufen, der Freigabe-Fluss, die Kontext-Trennung und das Audit sind dagegen kein Plan, sondern Produktiv-Mechanik – sie gelten für jeden Skill, nicht nur für diesen.

Warum dieser Aufwand

Weil ein Agent, der Werkzeuge bedient, nur so vertrauenswürdig ist wie die Regeln, die ihn führen. MCP gibt uns die saubere Technik, Fähigkeiten modular und isoliert hinzuzufügen. Die Governance – Risiko pro Werkzeug, Autonomie pro Kunde, Mensch in der Schleife bei echten Eingriffen, Least Privilege und lückenloses Audit – sorgt dafür, dass aus «kann viel» nie unbemerkt «darf alles» wird.

Für Sie heisst das: Bei uns ist jede Fähigkeit an die Leine genommen – mit Protokoll und einer klaren Antwort, wer wann was darf.

Mehr zur Schutzschicht auf Eingabe und Ausgabe lesen Sie in «Die unsichtbare Schutzschicht».