Kontrollierte MCP-Werkzeuge für KI-Agenten

Das Model Context Protocol (MCP) erleichtert die Anbindung eines Modells oder Agenten an Werkzeuge. Das Protokoll selbst entscheidet nicht, ob dem Agenten erlaubt ist, eine bestimmte Operation auszuführen, auf welche Ressource und mit welchen Konsequenzen. Die Anwendungsschicht muss diese Grenzen weiterhin durchsetzen.

Wenn ein Agent MCP nutzen kann, um einen Bericht zu lesen, Konfigurationen zu ändern, Geld auszugeben oder eine Ressource zu löschen, behandeln wir ihn als privilegierten API‑Client. Der Prompt beschreibt die Absicht. Das Gateway setzt die Limits durch.

In der Praxis gestalten wir diese Grenze nach sieben Prinzipien.

1. Trennung von Operator‑Identität und Zielsystem‑Anmeldeinformationen

Ein Agent handelt im Auftrag einer Person. Deshalb müssen mindestens zwei getrennte Fragen beantwortet werden:

• Wer hat diese Operation angefordert und was darf er in Brillnet tun?
• Wie authentifiziert sich Brillnet beim externen Anbieter?

Das sind nicht dieselben Dinge.

In unserem internen Brillnet‑Ads‑MCP‑Tool durchläuft der Operator die Autorisierungsschicht von Brillnet, während Aufrufe zu Google eine separate Service‑Identität verwenden. Das Anbietertoken ist kurzlebig und wird nicht über MCP als Daten an das Modell zurückgegeben.

Das Modell muss kein Anmeldecredential kennen, um eine erlaubte Aufgabe auszuführen. Es kann das Credential auch nicht versehentlich in einer Antwort einfügen, wenn es es nie erhalten hat.

Regel

Ein Geheimnis sollte nur der Komponente zur Verfügung stehen, die es tatsächlich benutzen muss, nicht der gesamten Ausführungskette.

2. Berechtigungen nach Operation ausdrücken, nicht nur nach Agenten‑Name

Eine Rolle wie marketing-agent ist leicht zu lesen, sagt aber wenig darüber aus, was das System tatsächlich zulässt.

Viel hilfreicher ist es, Berechtigungen nach Konsequenz zu trennen:

read
→ Berichte und Abrufe

write
→ Erstellen oder Ändern einer Ressource

operate
→ Aktivieren einer betrieblichen Konsequenz, z. B. Ausgaben oder Veröffentlichung

destructive
→ Löschen, Trennen, Widerrufen oder andere schwer umkehrbare Änderungen

Ein Agent kann read besitzen, ohne write zu haben. Er kann write besitzen, um eine Kampagne vorzubereiten, aber kein operate, sodass er die Kampagne nicht aktivieren kann. Löschen kann sowohl write + destructive erfordern.

Die Namen müssen nicht exakt diese sein. Wichtig ist die Unterscheidung zwischen Vorbereitung einer Änderung und Aktivierung ihrer Konsequenz.

Lesen: Least privilege for AI agents

3. Sichere Vorgaben müssen ohne Modell‑Hilfe funktionieren

Wenn das Weglassen eines Parameters eine Aktion auslöst, ist die Vorgabe unsicher.

In unserem internen Brillnet‑Ads‑MCP bleibt eine neue Kampagne PAUSED, wenn kein Status explizit angegeben wird. Das wirkt klein, aber die Regel ist entscheidend: fehlende Information bedeutet keine Zustimmung zum Ausgeben von Geld.

Das gleiche Muster gilt an anderen Stellen:

• Dokument ohne Status → Entwurf, nicht Veröffentlichung;
• Neuer Nutzer ohne Rolle → kein Zugriff, nicht eine Standard‑Rolle;
• Integration ohne bestätigtes Ziel → keine Synchronisation;
• Mehrdeutige Ressource → Fehler, nicht das „wahrscheinlichste“ Ergebnis;
• Fehlende Genehmigung für eine Hochrisiko‑Aktion → Abbruch, nicht Wiederholung.

Eine sichere Vorgabe muss sicher bleiben, wenn das Modell halluziniert, ein Feld weglässt oder die Absicht missversteht.

4. Hoch‑impact‑Operationen benötigen ein separates Gate

Ein Agent kann eine technisch korrekte Änderung vorbereiten, die dennoch die falsche geschäftliche Entscheidung darstellt.

Ausgaben, Veröffentlichung von Inhalten, Kundenansprache, Zugriffsänderungen oder Datenlöschung haben Konsequenzen, die über die aktuelle Agent‑Sitzung hinausgehen. Die Genehmigung sollte daher ein unabhängiges Ereignis sein.

Mindestens sollte eine Genehmigungsvorschau zeigen:

• Zielsystem und Ressource;
• Operationstyp;
• wesentliche Parameter der Änderung;
• erwartete Konsequenz;
• ob die Operation reversibel ist;
• wer genehmigt.

„Weiter?“ reicht nicht. Die Person muss wissen genau, was genehmigt wird.

Lesen: When should an AI agent require human approval?

5. Ein Retry darf keinen stillen Schreib‑Duplikat erzeugen

Agentische Systeme führen viele API‑Aufrufe aus. Netzwerkfehler, Time‑outs und Wiederholungen sind normal. Das Problem entsteht, wenn das Wiederholen derselben Operation ein zweites Objekt, eine zweite Zahlung, Veröffentlichung oder Nachricht erzeugt.

Wo die Operation das unterstützt, verwenden wir einen Idempotenz‑Schlüssel. Das Gateway erkennt den gleichen Versuch und verhindert ein unkontrolliertes Duplikat.

Das sollte mit read‑after‑write kombiniert werden:

Agent fordert eine Änderung an
↓
Gateway validiert und führt den Schreibvorgang aus
↓
Zielsystem antwortet
↓
Gateway liest den resultierenden Ressourcen‑Zustand
↓
Operator sieht den resultierenden Zustand

Ein HTTP‑200‑Status ist dann nicht das einzige Beweismittel dafür, dass das System im erwarteten Zustand ist.

6. Ein rohes Gateway darf kein Hintertür‑Werkzeug werden

Große APIs erzeugen eine praktische Versuchung: statt für jeden Endpunkt ein dediziertes Tool zu bauen, ein allgemeineres REST‑Capability bereitstellen.

Das kann sinnvoll sein, aber nur, wenn der allgemeine Pfad die gleichen Kontrollen erbt.

In Brillnet werden Methode, Endpunkt und Anforderungs‑Merkmale vor der Ausführung klassifiziert. Eine Low‑Level‑Anfrage umgeht nicht die erforderlichen Funktions‑Scopes oder die zusätzlichen Kontrollen für destruktive Operationen.

Das Anti‑Pattern sieht so aus:

sichere MCP‑Tools
→ abgegrenzt und validiert

raw_http_request
→ kann jeden Endpunkt mit einem Voll‑Zugriff‑Token aufrufen

In diesem Design sind die vorherigen Kontrollen weitgehend kosmetisch. Der breiteste Pfad definiert die eigentliche Sicherheitsgrenze.

7. Das Audit‑Log zeichnet Entscheidung und Ergebnis, nicht Geheimnisse, auf

Unser internes Tool speichert Anforderungs‑Metadaten und Ergebnisse in einer append‑only, integritäts‑kontrollierten Audit‑Kette. Anmeldeinformationen, Autorisierungs‑Header und rohe Personen‑IDs werden ausgeschlossen.

Diese Unterscheidung ist wichtig. Ein Audit‑Log soll eine Aktion rekonstruieren, nicht den Sicherheits‑Kontext in einen anderen Datenspeicher duplizieren.

Für eine Agent‑Operation wollen wir typischerweise wissen:

• Anforderungs‑/Task‑ID;
• Operator‑ und Agent‑Identität;
• Werkzeug‑ und Operationsklasse;
• Ziel‑Ressource;
• Autorisierungs‑Entscheidung;
• Genehmigungs‑ID, falls erforderlich;
• Anbieter‑/Backend‑Ergebnis;
• nach einem Schreibvorgang beobachteter Zustand;
• angewandte Richtlinien‑ oder Konfigurations‑Version.

Lesen: AI agent audit trails

Beispiel‑Architektur: Ein Agent für Google Ads

Unser internes Beispiel ist bewusst eng gefasst. Das Werkzeug wird nur für Google‑Ads‑Konten verwendet, die Brillnet gehört. Es ist kein Agentur‑Dienst und erhält keinen Zugriff auf Kunden‑Ad‑Accounts.

Der Ablauf lässt sich vereinfachen zu:

Brillnet‑Operator
↓
Identität + Profil + Scopes
↓
Agent / Modell
↓
MCP‑Tool‑Aufruf
↓
Gateway: Validierung + Klassifizierung + Genehmigungs‑Policy
↓
kurzlebiges Anbieter‑Token
↓
Google Ads API
↓
Normalisierung + Redaktion
↓
read‑after‑write / Ergebnis
↓
Audit‑Trail

Die wichtigste Kontrolle liegt nicht im Modell, sondern in der Schicht zwischen Absicht und Ausführung.

Gut aussehende Anti‑Patterns

Ein Administrator‑Token für jeden Agent

Erleichtert das Prototyping. Später wird es schwierig, die Auswirkungen eines Fehlers zu begrenzen oder nachzuweisen, dass ein Agent überhaupt Zugriff auf eine Ressource haben durfte.

„Das Modell fragt den Nutzer, ob eine Aktion riskant ist“

Damit wird die Sicherheitsentscheidung an dieselbe Komponente delegiert, deren Fehler die Kontrolle eigentlich verhindern soll.

Das vollständige Prompt‑ und Antwort‑Logging als Audit‑Trail

Ein Gespräch ist kein operatives Audit‑Record. Es kann zudem Informationen enthalten, die nicht in das Log‑System kopiert werden dürfen.

Automatisches Wiederholen jedes Fehlers

Nicht jeder Fehler ist transient. Nicht jeder Schreibvorgang ist idempotent. Ein unklassifizierter Retry kann den Schaden vergrößern.

Ein universeller Endpunkt mit Vollzugriff „für zukünftige Features“

Wenn ein breites Werkzeug die eingeschränkten Werkzeuge umgehen kann, ist das breite Werkzeug das eigentliche Berechtigungs‑Modell.

MCP‑Server‑Checkliste

Vor dem produktiven Einsatz würde ich mindestens Folgendes prüfen:

• Ist die Operator‑Identität für jeden Aufruf bekannt?
• Sind Zielsystem‑Anmeldeinformationen vor dem Modell verborgen?
• Können Lese‑, Schreib‑, Betriebs‑ und destruktive Berechtigungen getrennt werden?
• Beschränkt die Autorisierung die Ressource/Mandant/Account ebenso wie die Funktion?
• Führt das Weglassen eines Parameters zu einem sicheren Zustand?
• Haben finanzielle, externe und destruktive Operationen eine unabhängige Genehmigung?
• Sind Schreib‑Retries kontrolliert?
• Wird die Ziel‑Ressource nach einem Schreibvorgang gelesen?
• Nutzt ein Low‑Level‑Gateway dieselben Autorisierungs‑Regeln?
• Schließt das Audit‑Log Tokens, Geheimnisse und rohe personenbezogene Daten aus?
• Werden beliebige Dateisystem‑Pfade und unbeschränkte Payloads abgelehnt?
• Können Agent‑ oder Operator‑Zugriffe zentral widerrufen werden?

MCP 2026‑07‑28 ändert das Protokoll, nicht den Bedarf an Anwendungskontrollen

Die MCP‑Version 2026-07-28 führte u. a. einen zustandslosen Protokoll‑Kern und zusätzliche Autorisierungs‑Härtungen ein. Diese Änderungen erleichtern das Skalieren und Verstehen der Kommunikationsschicht. Sie bestimmen jedoch nicht die Geschäfts‑Policy einer Implementierung: ob ein Agent 5.000 PLN ausgeben, ein Konto löschen oder 10.000 Personen anschreiben darf.

Die Anwendung muss diese Entscheidung weiterhin durchsetzen.

Wer braucht dieses Design‑Pattern

Prozess‑Owner, Entwickler und Sicherheits‑Reviewer benötigen diese Grenze. Fertigungs‑Agenten können Änderungsanträge entwerfen; Immobilien‑Management‑Agenten können Dokumente organisieren; B2B‑Agenten können Tickets analysieren. Das Versenden von Bewohner‑Hinweisen oder das Ändern von Kunden‑Berechtigungen erfordert Kontrolle über die Konsequenz.

Das Ads‑MCP‑Beispiel stammt aus interner Tool‑Design‑Dokumentation. Es beschreibt weder einen Kunden‑Werbekonto‑Dienst noch ein unabhängiges Audit der aktuellen Produktionsumgebung.

Identität und Isolation benötigen mehr als ein gültiges Token

MCP‑Autorisation verlangt Tokens, die für die Ressource des Servers selbst bestimmt sind. Eine gültige Signatur eines Tokens eines anderen Dienstes reicht nicht aus. Prüfen Sie Audience, Issuer und Gültigkeit. Ungültige Tokens vor der Ausführung ablehnen.

Auch der Ressourcenzugriff muss geprüft werden. Vergleichen Sie ein übermitteltes tenant_id mit der vom Server etablierten Identität, anstatt dem Agenten‑Identifier zu vertrauen. Jede Lese‑ und Schreiboperation benötigt Ressourc‑Autorisation, inklusive Anhänge, Exporte und Hintergrund‑Jobs.

MCP 2026-07-28 kennt keine protokoll‑level Sitzungen. Anwendungen können dennoch Zustand behalten, etwa einen Änderungs‑Vorschau‑Handle. Besitz darf nicht Authentifizierung ersetzen. Binden Sie Handles an autorisierte Operatoren, prüfen Sie jede Nutzung und setzen Sie ein Verfallsdatum. Ein gestohlener Handle darf nicht den Workflow einer anderen Person offenbaren.

Inhalte und Kommunikationsziele validieren

Suchergebnisse, PDFs, E‑Mails und API‑Antworten sind Analyse‑Material. Eingebettete Anweisungen, Geheimnisse abzurufen oder Dokumente anderswo zu senden, stellen keine Operator‑Genehmigung dar. Zum Schutz vor Prompt‑Injection muss der Server unautorisierte Ressourcen, Empfänger und Operationen ablehnen, selbst wenn Tool‑Argumente technisch gültig sind.

Für ein Tool, das URLs akzeptiert, definieren Sie zulässige Ziele und Redirect‑Verhalten. MCP‑Leitfäden diskutieren SSRF in OAuth‑Metadata‑Discovery. Bewerten Sie das gleiche Problem in eigenen Abruf‑Tools. Das Recht, eine öffentliche Seite zu holen, darf nicht dazu führen, dass ein lokaler Administrations‑Dienst oder ein Cloud‑Metadata‑Endpoint erreicht wird. Schutzmaßnahmen hängen von der Netzwerk‑Architektur ab; eine reine Host‑Namens‑Liste reicht möglicherweise nicht aus, um das endgültige Ziel zu kontrollieren.

Für Dateitools beschränken Sie Verzeichnisse und Payload‑Größe. Pfade außerhalb des erlaubten Bereichs, unbekannte Felder und übermäßige Exporte ablehnen. Ein expliziter Fehler ist besser als ein stilles Ausweiten der Zuweisung.

Kleines Deployment‑Szenario: Service‑Ticket‑Entwürfe

Angenommen, ein Unternehmen will die Vorbereitungszeit für Geräte‑Incident‑Tickets reduzieren. Der Agent liest ein genehmigtes Handbuch und die Vorfall‑Historie, erstellt dann einen Entwurf. Das Versenden an einen Lieferanten bleibt eine separate Operation. Dies ist ein Design‑Szenario, keine Aussage darüber, dass Brillnet diese Funktion aktuell bereitstellt.

Der Service‑Owner wählt eine Gerätegruppe und definiert die erwartete Ausgabe: einen Entwurf, der Gerät, Symptom, Ereigniszeit und fehlende Informationen benennt. Der Entwickler stellt zwei enge Werkzeuge bereit: genehmigtes Dokument‑Abrufen und Entwurf‑Erstellung in einem festgelegten Projekt. Die Anfangsversion bietet weder Messaging noch Gerätekonfiguration. Der Sicherheits‑Reviewer prüft den Daten‑Scope und die zentrale Zugriffs‑Widerruf‑Möglichkeit.

Testen Sie einen erlaubten Lese‑Vorgang, einen versuchten projektübergreifenden Lese‑Vorgang, ein Dokument mit bösartigen Anweisungen und einen Schreib‑Retry nach einem Timeout. Ein kleiner Werkzeug‑Katalog reicht aus, um zu starten. Er muss die im Design versprochenen Beschränkungen durchsetzen.

Wird später das Versenden hinzugefügt, muss die Genehmigung Empfänger und Inhalt abdecken. Eine Änderung des Empfängers macht frühere Genehmigungen ungültig. Fehlt dem Anbieter Idempotenz‑Unterstützung, lösen Sie einen mehrdeutigen Timeout, indem Sie prüfen, ob die Nachricht bereits existiert. Nicht einfach erneut senden, weil das Modell keine Antwort erhalten hat.

Was man morgen mit einem Owner tun sollte

Der Prozess‑Owner wählt eine Aktion und die erlaubte Konsequenz. Der Entwickler mappt Werkzeug, Operation und Ressource, inklusive des breitesten verfügbaren Zugriffswegs. Der Sicherheits‑Reviewer prüft, wo die Operator‑Identität endet, wo die Service‑Identität beginnt und ob das Modell Zugang zu Anmeldeinformationen hat. Das Ergebnis des ersten Tages sollte eine kurze Übersicht und eine Ausführung sein, deren Ergebnis im Zielsystem verifiziert werden kann.

Messen Sie die akzeptierte Entwurfs‑Qualität, abgelehnte Scope‑Verstöße und die Zeit für menschliche Reviews. Mehr Werkzeug‑Aufrufe sind nicht automatisch nützlich. Wenn die Korrektur länger dauert als die Vorbereitung spart, beschränken Sie die Aufgabe, bevor Sie weitere Fähigkeiten hinzufügen.

Technische Anleitung und rechtliche Pflichten

OWASP und NIST bieten technische Leitfäden. Die MCP‑Spezifikation definiert Protokoll‑Anforderungen. Diese Quellen bestimmen nicht eigenständig die rechtlichen Pflichten eines Unternehmens oder Aufbewahrungsfristen für Daten. Ermitteln Sie die für den Prozess geltenden sektor‑, vertrags‑ und gesetzlichen Vorgaben. Dieser Leitfaden erklärt das Kontroll‑Design und verleiht keine Konformitäts‑Zertifizierung.

Grenze

Dies sind Muster, die wir in unserer eigenen Arbeit verwenden. Diese Seite behauptet nicht, dass das gesamte Werkzeug zertifiziert oder universell konform mit OWASP, NIST oder der kompletten MCP‑Spezifikation ist. Jede Integration benötigt ein eigenes Threat‑Model und Sicherheitstests.

Wenn Sie prüfen wollen, wie Brillnet mit Zugriff, Daten und KI umgeht, siehe Security und Compliance and AI oversight.

Quellen

Die technischen Quellen unterstützen die genannten Prinzipien. Einsatzszenarien und der Aktionsplan sind die Design‑Empfehlungen des Autors.

• Model Context Protocol — Specification 2026-07-28 release — accessed: 2026-10-02.
• Model Context Protocol — Authorization 2026-07-28 — accessed: 2026-10-02.
• Model Context Protocol — Security Best Practices 2026-07-28 — accessed: 2026-10-02.
• OWASP AI Agent Security Cheat Sheet — accessed: 2026-10-02.
• OWASP MCP07:2025 — Insufficient Authentication & Authorization — accessed: 2026-10-02.
• OWASP MCP08:2025 — Lack of Audit and Telemetry — accessed: 2026-10-02.
• OWASP Authorization Cheat Sheet — accessed: 2026-10-02.