Praxisbericht · Deep Dive
Ein Praxisbericht aus VamiGRC
Ein sicherer MCP-Server hält jede Entscheidung, die zählt, vom KI-Agenten fern. Beim Bau des MCP-Servers, der KI-Assistenten wie Claude mit VamiGRC verbindet, haben wir gelernt: Eine Bestätigung im Chat ist keine Sicherheitskontrolle, denn ein manipulierter Agent kann sie selbst beantworten. Hier steht, wie wir Identität, Freigaben, Autonomie und Mandantengrenzen ins Backend verlagert, jede Kontrolle getestet und die Grenzen offen benannt haben.
Seit der Revision der MCP-Spezifikation vom Juni 2025 ist ein geschützter MCP-Server ein OAuth-2.1-Resource-Server. Die Praxis hinkt hinterher, und eine GRC-Plattform erhöht den Einsatz.
8,5 %
von über 5.200 untersuchten Open-Source-MCP-Servern nutzten im Oktober 2025 OAuth.
State of MCP Server Security 2025: Research Report (Oktober 2025) (öffnet externe Website)
Specification, Revision 2025-06-18: Authorization (Juni 2025) (öffnet externe Website)
Der Agent liest Risiken, Vorfälle und Lieferantendaten, und er kann sie ändern. Eine falsche Änderung ist nicht nur ein Bug: Sie kann die Nachweise verfälschen, auf die sich ein Auditor verlässt.
Wie kann ein KI-Agent mit Compliance-Daten arbeiten, ohne zur schwächsten Stelle der Plattform zu werden?
Wir haben drei Angreifer modelliert: STRIDE für die Art des Fehlers, die OWASP MCP Top 10 als Risikokatalog. Wählen Sie einen Angreifer, um zu sehen, welche Kontrollen ihn begrenzen, welche Negativtests dazugehören und was bleibt.
Was bleibt: In einer gekaperten Sitzung kann der Agent auf L2 im Chat noch bestätigen, und die Lösch-Referenz kann er selbst tippen. Deshalb brauchen Löschungen und Entscheidungen die Freigabe in der Anwendung. Prompt Injection selbst lässt sich nicht vollständig verhindern.
Was bleibt: Was die öffentliche API und die Limits der Organisation erlauben, bleibt möglich: Änderungen außer Löschungen und Entscheidungen kann eine gekaperte Sitzung auf L2 im Chat bestätigen, und ein Rollback gibt es nur teilweise.
Der rote Faden: Ein manipulierter Agent bricht nicht ein. Er nutzt Berechtigungen, die er rechtmäßig hat. Jede Kontrolle muss deshalb dort sitzen, wo der Agent sie nicht erreicht.
Der Agent hält nie ein Token, das das Backend als normale Nutzersitzung akzeptiert. Die Anmeldekette in vier Schritten:
Der Assistent findet den Autorisierungsserver über die Protected Resource Metadata des MCP-Servers (RFC 9728).
Die Person meldet sich bei VamiGRC selbst an und sieht einen Consent-Screen: welcher Assistent, nur lesen oder lesen und ändern, welcher Mandant.
Der Assistent erhält ein Access Token, das Minuten statt Tage gilt und den MCP-Server als Audience trägt, dazu ein Refresh Token, das sich bei jeder Nutzung ändert.
Das Backend akzeptiert dieses Token nur wie ein eingehegtes API-Token: nur die öffentliche API, nie Admin-Funktionen und nie mehr als die eigene Rolle der Person.
Unser früheres Design tauschte die Anmeldung bei einem externen Identity Provider gegen ein Backend-Token. Das funktionierte, doch langlebige Sitzungen und Token Exchange passten schlecht zusammen: Nach Leerlauf sahen Nutzer „Anmeldung abgelaufen“. Seit VamiGRC selbst der Autorisierungsserver ist, gibt es diese Problemklasse nicht mehr.
Ein einziger fehlender Scope, offline_access, ließ einen großen KI-Client scheitern, bevor er überhaupt eine Anmeldeseite zeigte.
Grundlagen: RFC 9728: OAuth 2.0 Protected Resource Metadata (April 2025) (öffnet externe Website) · RFC 8707: Resource Indicators for OAuth 2.0 (Februar 2020) (öffnet externe Website) · RFC 9700: Best Current Practice for OAuth 2.0 Security (Januar 2025) (öffnet externe Website) · The OAuth 2.1 Authorization Framework (Internet-Draft) (öffnet externe Website)
Unsere erste Version ließ jede Änderung im Gespräch bestätigen. Das fühlte sich sicher an, doch die Bestätigung lief über denselben Kanal, den der Angreifer kontrolliert.
Die Kontrolle liegt im Kanal des Angreifers.
Diese Schichten kann der Agent nicht fälschen. Löschungen und Entscheidungen brauchen zusätzlich die Freigabe in der App.
Jeder Schreibzugriff ist ein Zwei-Schritt-Aufruf. Der erste liefert eine Vorschau und speichert sie auf dem Server, erst ihre Bestätigung schreibt. Hat sich der Datensatz inzwischen geändert, wird die Bestätigung abgelehnt.
Beim Bestätigen signiert der MCP-Server die exakte Anfrage. Das Backend lehnt jeden Schreibzugriff ohne diesen Nachweis ab. Ein gestohlenes Access Token kann deshalb direkt gegen die API nicht schreiben.
Ein bloßes „Ja“ löscht nichts. Die Person tippt die Referenz des Datensatzes, und die Vorschau nennt alles, was mit ihm verknüpft ist. Was sich archivieren lässt, wird archiviert statt gelöscht.
Nicht jede Aktion verdient dasselbe Vertrauen. Jede Schreibroute der öffentlichen API gehört zu einer Aktionsklasse, und die Organisation legt je Klasse die höchste Autonomiestufe fest, nach den Stufen L0 bis L3 von VamiGRC.
L0
Der Agent darf nicht handeln.
Im MCP-ServerAbgelehnt mit klarer Begründung, die Person handelt in VamiGRC.
L1
Der Agent bereitet vor, die Person handelt.
Im MCP-ServerEin Entwurf, den die Person prüft und speichert.
L2
Der Agent handelt, nachdem ein Mensch freigegeben hat.
Im MCP-ServerVorschau und Bestätigung, bei Löschungen und Entscheidungen Freigabe in der App.
L3
Der Agent handelt allein, alles wird protokolliert.
Im MCP-ServerNur für Klassen mit geringem Risiko, etwa Notizen.
Die Organisation setzt das Maximum, jede Person kann es für ihre eigenen Assistenten nur verengen. Es gilt immer die strengste Einstellung.
Löschungen und Entscheidungen laufen nie autonom, und signierte Entscheidungen wie Freigaben gehen nie über den Chat.
Eine Route ohne Klasse gilt als gesperrt. Ein Test schlägt fehl, sobald eine neue Schreibroute keine Klasse hat.
Wählen Sie eine Aktionsklasse, das Maximum der Organisation und das persönliche Limit. Der Rechner wendet die drei Regeln an.
Wirksame Stufe
L2KI-ausgeführt mit Pflichtfreigabe
Vorschau und Bestätigung, bei Löschungen und Entscheidungen Freigabe in der App.
Begrenzt durch das Maximum der Organisation.
Vereinfachtes Modell auf Basis dieses Praxisberichts, kein Abbild der Produktkonfiguration.
Beraterinnen und Berater arbeiten für mehrere Kunden, eine Person hat also oft Zugriff auf mehrere Mandanten. Der MCP-Server folgt dem Mandanten, der in der VamiGRC-App gewählt ist, bei jedem Aufruf geprüft und ohne Caching. Diese Bequemlichkeit schafft ein neues Risiko.
Die Vorschau speichert Mandant und Gesellschaft, die Antwort nennt beide.
Der MCP-Server folgt dem Wechsel beim nächsten Aufruf.
Die Bestätigung wird abgelehnt, bevor irgendetwas gesendet wird.
Der Server lehnt ab, statt still auf einen anderen Mandanten auszuweichen.
Jeder Test versucht, eine Kontrolle zu brechen, Ende zu Ende gegen ein echtes Backend und einen echten MCP-Client, nicht nur in Unit-Tests.
| Prüfung | Erwartet | Ergebnis |
|---|---|---|
| Autorisierungscode zweimal verwendet | Abgelehnt, und die damit erzeugte Verbindung wird beendet | Bestanden |
| Altes Refresh Token nach der Rotation wiederverwendet | Abgelehnt, und die ganze Verbindung wird beendet | Bestanden |
| Bloßes „Ja“ auf eine Lösch-Vorschau | Nichts gelöscht, die Referenz wird verlangt | Bestanden |
| Mandant zwischen Vorschau und Bestätigung gewechselt | Bestätigung abgelehnt, nichts geschrieben | Bestanden |
| Mehrere Mandantenwechsel hintereinander | Die Verbindung folgt jedem Wechsel | Bestanden |
| Löschen in einer anderen Gesellschaft per ID | Nicht gefunden, der Datensatz bleibt erhalten | Bestanden |
| Schreiben ohne Bestätigungsnachweis | Abgelehnt | Bestanden |
| Persönliches Limit strenger als das der Organisation | Das strengere Limit gilt | Bestanden |
Gefunden haben das Tests, die die Kontrollen wie ein Angreifer prüften, nicht nur die Funktionen.
Fünf Erkenntnisse, die sich auf andere MCP-Server übertragen lassen, und fünf Grenzen, offen benannt.
Zehn Fragen aus diesem Praxisbericht. Je öfter Sie mit „Ja“ antworten, desto weniger hängt Ihre Sicherheit davon ab, was der Agent tut.
Beantwortet: 0/10
Das Ergebnis ist eine Orientierung, kein Prüfnachweis. Ihre Antworten werden nicht übertragen.
So ordnen wir die Kontrollen den Risikokatalogen zu. Beide Kataloge sind jung, das Mapping wird sich mit ihnen ändern.
MCP01
OWASP MCP Top 10 (v0.1, Beta) (öffnet externe Website)
Kein Token-Passthrough, kurzlebige und an die Audience gebundene Tokens, rotierende Refresh Tokens mit Wiederverwendungserkennung, Zugriff nur auf die öffentliche API.
MCP10
OWASP MCP Top 10 (v0.1, Beta) (öffnet externe Website)
Antworten nennen Mandant und Gesellschaft, Daten aus Datensätzen sind als nicht vertrauenswürdig markiert, und der Agent sieht nur, was die Rolle der Person erlaubt.
LLM06:2025
OWASP Top 10 for LLM Applications 2025 (öffnet externe Website)
Autonomiestufen je Aktionsklasse, harte Obergrenzen und Freigabe in der Anwendung für Löschungen und Entscheidungen.
Die OWASP MCP Top 10 sind eine Beta, der Agent Control Standard steht bei Version 0.1.0. Alle zehn MCP-Risiken im Deep Dive
Der Praxisbericht aufbereitet für Entscheider: Bedrohungsmodell, Identität ohne Token-Passthrough, Freigaben im Backend, Autonomiestufen und Governance, Mandantenbindung und Audit-Trail, Negativtests, Fragen an Anbieter und ein 30-60-90-Tage-Plan.
Wir prüfen MCP-Server und Agenten-Anbindungen so, wie es dieser Bericht beschreibt: mit Bedrohungsmodell, Kontrollen außerhalb des Agenten und Negativtests.
Spezifikationen, Standards und Studien, auf die sich dieser Praxisbericht stützt.
Kurz beantwortet
Weil sie im selben Kanal läuft, den ein Angreifer kontrolliert. Ein per Prompt Injection manipulierter Agent kann die Rückfrage selbst mit „Ja“ beantworten, und wer ein Access Token gestohlen hat, umgeht den Chat ganz. Wirksamer sind Kontrollen, die der Agent nicht fälschen kann: vom Server erzwungene Vorschauen, ein an die exakte Anfrage gebundener Bestätigungsnachweis und, für Löschungen und Entscheidungen, die Freigabe in der Anwendung.
Seit der Revision vom Juni 2025 ist ein geschützter MCP-Server ein OAuth-2.1-Resource-Server. Verlangt sind Metadata-Discovery über die Protected Resource Metadata (RFC 9728), PKCE und Tokens, die für den MCP-Server als Audience ausgestellt sind; Token-Passthrough ist verboten. Der Praxisbericht zeigt, was darüber hinaus nötig ist, sobald ein Agent schreiben darf.
Sie legen fest, was ein Agent allein darf: L0 manuell, L1 KI-assistiert, L2 KI-ausgeführt mit Pflichtfreigabe, L3 voll autonom und voll auditiert. Im MCP-Server von VamiGRC setzt die Organisation je Aktionsklasse die höchste Stufe, jede Person kann sie nur verengen, und eine Route ohne Klasse ist gesperrt. Löschungen und Entscheidungen laufen nie autonom.
Nein. Text aus Datensätzen wird als nicht vertrauenswürdig markiert, ein Modell kann ihm trotzdem folgen. Die Kontrollen begrenzen, was ein manipulierter Agent anrichten kann, stoppen aber nicht die Manipulation selbst. Deshalb brauchen Löschungen und Entscheidungen die Freigabe in der Anwendung.
Mit einem Negativtest für jede Kontrolle, der sie gezielt zu brechen versucht: Autorisierungscode doppelt einlösen, ein altes Refresh Token wiederverwenden, zwischen Vorschau und Bestätigung den Mandanten wechseln, ohne Bestätigungsnachweis schreiben, per ID in einer fremden Gesellschaft löschen. Ende zu Ende gegen ein echtes Backend und einen echten MCP-Client, nicht nur in Unit-Tests.
Beide sind früh: Die OWASP MCP Top 10 liegen als Beta in Version 0.1 vor, der Agent Control Standard in Version 0.1.0. Wir ordnen unsere Kontrollen den Risiken Token Mismanagement & Secret Exposure, Context Injection & Over-Sharing und Excessive Agency zu und passen das Mapping an, wenn die Standards reifen.
Wir prüfen MCP-Server und Agenten-Anbindungen wie ein Angreifer und zeigen, welche Entscheidungen noch in Reichweite des Agenten liegen.
