Sicherheitsarchitekturen für KI Agenten
Ein aktueller Vorfall rund um einen KI-Agenten zeigt, wie schnell aus technischer Bequemlichkeit ein operatives Risiko werden kann. Wer Agenten mit Tools, APIs und internen Systemen verbindet, braucht mehr als ein funktionierendes Protokoll. Er braucht klare Identitäten, kurzlebige Berechtigungen und einen kontrollierten Zugriffspfad.
Genau darin liegt die eigentliche Herausforderung bei produktiven Agentensystemen: Nicht das Modell allein erzeugt das Risiko, sondern die Kombination aus Rechten, Laufzeitumgebung und fehlenden Leitplanken.
Der Vorfall ist kein Ausreißer, sondern ein Warnsignal
Ein aktueller Vorfall bei PocketOS macht die Sicherheitsfrage sehr greifbar. Laut heise löschte ein KI-Agent in einer Entwicklungsumgebung Daten, nachdem er Zugriff auf ein Token erhalten hatte und damit weitreichende Aktionen ausführen konnte.
Die einfache Deutung wäre: Der Agent hat einen Fehler gemacht. Das greift zu kurz. Das eigentliche Problem liegt meist an anderer Stelle. Wenn ein Agent Zugriff auf produktive oder produktionsnahe Systeme hat, wenn Tokens zu breit vergeben sind und wenn kritische Aktionen ohne zusätzliche Kontrolle möglich bleiben, dann wird aus einem nützlichen Werkzeug schnell ein operatives Risiko.
Der Vorfall ist deshalb weniger ein Beleg gegen Agenten als ein Beleg gegen schlechte Sicherheitsarchitektur.
Kernaussagen
- MCP standardisiert den Zugriff von Agenten auf Tools und Daten, ersetzt aber keine Sicherheitsarchitektur.
- Dauerhafte API-Keys im Agentenkontext sind ein unnötiges und vermeidbares Risiko.
- Sicherer ist ein vorgeschalteter Gatekeeper mit kurzlebigen, zweckgebundenen Tokens.
- Destruktive Aktionen brauchen zusätzliche Policy-Prüfungen und Freigabemechanismen.
- Produktive Agenten brauchen kontrollierte Wege statt Generalschlüssel.
Warum Agenten und MCP zusammengehören
Wer über Agenten spricht, landet schnell bei MCP, dem Model Context Protocol. MCP schafft einen standardisierten Weg, mit dem Modelle und Agenten auf Tools, Datenquellen und Funktionen zugreifen können. Das ist technisch sinnvoll, weil Integrationen damit strukturierter, wiederverwendbarer und schneller umsetzbar werden. Ein Modell kann nicht nur beraten, sodern ein Agent kann gleich „agieren“.
Wenn das LLM Modell das Gehirn ist, dann ist ein Agent das Rückgrat über das die Bewegung der Extremitäten und den damit angebundenen Werkzeuge gesteuert werden. Das Protokoll dieser Nervenbahnen heißt MCP.
MCP ermöglichst den Zugriff. Es löst nicht automatisch die Frage, wer zugreifen darf, wie lange dieser Zugriff gilt und welche Aktionen tatsächlich erlaubt sein sollen. Mit anderen Worten: MCP ist ein Integrationsprotokoll, kein Baustein einer Sicherheitsarchitektur.
Sobald ein Agent per MCP mit Dateisystemen, Geschäftsanwendungen, APIs oder internen Services verbunden wird, gelten dieselben Grundfragen wie bei jeder anderen Systemkopplung auch: Wer ist die handelnde Identität? Welche Rechte gelten konkret? Wie lange gelten sie? Wie wird Missbrauch verhindert? Wie werden kritische Aktionen nachvollziehbar gemacht?
Wer diese Fragen nicht sauber beantwortet, verlagert bestehende IAM- und Security-Probleme nur in eine neue technische Schicht.
Der gefährliche Kurzschluss: dem Agenten einfach einen API-Key geben
In vielen frühen Setups passiert genau das. Ein Agent bekommt einen API-Key, ein Service-Token oder Zugangsdaten für ein internes System. Technisch ist das bequem. Man schaue sich die Möglichkeiten von Systemen wie OpenClaw an: Mit ihnen kann man „auf Zuruf“ Automatisierungen erschaffen. „Welchen API-Key brauchst Du dafür?“ lautet auch eine typische Frage an die KI, wenn allzu schnell und wie von Zauberhand Systeme zu einem großen Ganzen integriert werden sollen.
Liegt ein dauerhafter Schlüssel im Agentenkontext, in Konfigurationsdateien, in Logs, in Umgebungsvariablen oder direkt im MCP-Server, ist die Kontrolle schnell verloren. Schon ein fehlerhafter Tool-Call, ein zu breiter Prompt-Kontext oder eine unerwartete Aktion kann dann reichen, um Schaden auszulösen.
Das Ausspähen von Passwörtern
Unbeabsichtigte Aktiväten eines Agenten sozusagen menschliches Versagen im Umgang mit der KI ist ein neues Problem. Ein altes Problem der Informationssicherheit dagegen taucht hier wieder auf. Die Speicherung von Zugangsdaten (Credentials). Sie werden vom Benutzer unsichtbar gespeichert. Werden sie in einem Chat übergeben („Verwende diesen API Key“) dann wird dieser fast sicher in Klartext im Log des Chats gespeichert. Werden Skripte verwendet oder Umgebungsvariablen gesetzt, dann werden die Credentials ebenfalls oft unverschlüsselt abgelegt. Intranparent für den Benutzer, wo, wie oft und für wen zugänglich. Ein Paradies für alle, die Zugangsdaten ausspähen. Noch verschärft, wenn sich Angreifer ebenfalls KI Tools zunutze machen.
Verwundbare Abläufe
Dazu kommt ein operatives Risiko. Läuft ein API key ab, oder wird ein Passwort geändert, dann sprengt das einmal laufende Automatisierungen. Die Abläufe selbst werden verwundbar.
Der bessere Ansatz: ein Torwächter vor dem Zielsystem
Sicherer wird es, wenn der Agent nicht direkt mit dem Zielsystem authentifiziert wird, sondern über einen vorgeschalteten Torwächter arbeitet. Dieser Torwächter kapselt den Zugriff. Er trennt Identitäten, prüft Richtlinien und stellt nur dann Berechtigungen bereit, wenn sie für eine konkrete Aktion wirklich erforderlich sind.
Statt eines dauerhaften API-Keys erhält der Agent, wenn überhaupt, nur ein kurzlebiges, zweckgebundenes Token mit engem Gültigkeitsbereich. Wichtig ist dabei: Die eigentliche Anmeldung erfolgt nicht über den Agenten selbst. Sie erfolgt über einen separaten Authentifizierungs- und Token-Server. Der Agent bekommt also keinen dauerhaften Schlüssel, sondern ein zeitlich begrenztes Ticket für eine klar definierte Aufgabe.
Wer deshalb Identität, Autorisierung und Token-Ausstellung aus dem Agenten herauslöst, reduziert nicht nur das Missbrauchsrisiko, sondern erhöht auch Nachvollziehbarkeit, Widerrufbarkeit und Governance.
Das MCP-Protokoll unterstützt OAuth 2.1 für Autorisierung bei geschützten MCP-Servern. Die Spezifikation beschreibt MCP-Server dabei als OAuth-2.1-Resource-Server und MCP-Clients als OAuth-2.1-Clients. Quelle: MCP Authorization Specification, Understanding Authorization in MCP.
Wie so ein Sicherheitsmuster praktisch aussieht
In einem belastbaren Setup ruft der Agent nicht direkt CRM, ERP, Dateispeicher oder Deployment-Schnittstellen auf. Er spricht zunächst mit einem Gatekeeper-Service. Dieser prüft zum Beispiel, welche Identität oder welcher Mandant hinter der Anfrage steht, für welchen Zweck der Zugriff angefordert wird, ob die gewünschte Aktion grundsätzlich erlaubt ist, wie hoch das Risiko der Aktion ist und ob eine zusätzliche Freigabe erforderlich ist.
Erst danach wird ein kurzlebiger Token mit minimalem Scope ausgestellt oder die Aktion wird kontrolliert serverseitig ausgeführt. Gerade bei sensiblen Vorgängen wie Löschen, Exportieren, Überschreiben, Deployen oder produktiven Änderungen sollten zusätzliche Schutzmechanismen greifen. Denkbar sind Vier-Augen-Freigaben, feste Zeitfenster, Allowlists, Scopes pro Aktion oder harte Limits für besonders riskante Operationen.
So wird aus einem offenen Maschinenzugang ein kontrollierter Zugriffspfad.
Fünf Regeln, die man nicht verletzen sollte
- Gib dem Agenten nie einen dauerhaften API-Key.
- Verstecke Zugriffsdaten nicht einfach im MCP-Server und halte das für Sicherheit.
- Regle die Authentifizierung über einen Token-Server mit kurzlebigen, zweckgebundenen Berechtigungen und verwende standardisierte und moderne Protokolle wie OAuth 2.1
- Erlaube destruktive Aktionen nie ohne zusätzliche Policy-Prüfung oder Freigabemechanismus.
- Verbinde Agenten nicht direkt mit Produktivsystemen, solange Rollen, Protokollierung und Entzug von Rechten nicht sauber gelöst sind.
Was Unternehmen daraus ableiten sollten
Viele Unternehmen stehen derzeit unter Druck, Agenten schnell produktiv zu machen. Das ist nachvollziehbar. Der Nutzen kann erheblich sein. Aber Geschwindigkeit ersetzt keine Sicherheitsarchitektur. Die eigentliche Sicherheitsfrage lautet nicht, ob ein Agent klug genug ist. Die eigentliche Frage lautet, wie begrenzt, kontrolliert und nachvollziehbar sein Zugriff auf echte Systeme ist. Wer Agenten produktiv einsetzt, sollte ihnen keine Schlüssel geben, sondern kontrollierte Wege.
In der Praxis
Wir stellen ein komplettes Open Source Demo Projekt zu diesem Thema zur Verfügung. Es ist mit Codex getestet. Lesen Sie auch diesen Beitrag: Remote-MCP sicher anbinden: Demo Projekt
SilverQ unterstützt bei sicheren Agenten-Architekturen
Wenn Sie Agenten im Unternehmen einsetzen wollen, ohne dabei neue Sicherheitslücken zu schaffen, unterstützt SilverQ bei der strukturierten Ausarbeitung von Zugriffsmodellen, Governance, Sicherheitsleitplanken und produktionsfähigen KI-Architekturen. Ziel ist nicht nur ein funktionierender Agent, sondern ein verantwortbarer Einsatz im realen Betrieb.
Wenn Sie dieses Thema für Ihre Organisation konkret bewerten möchten, sprechen Sie mit SilverQ über einen kontrollierten Einstieg in sichere Agentensysteme.
Fazit
Der eigentliche Fehler liegt meist nicht im Agenten, sondern in einer Architektur, die ihm zu viele Rechte und zu wenig Leitplanken gibt. MCP erleichtert den Zugriff auf Tools und Systeme, ersetzt aber keine Sicherheitsarchitektur.
Wer Agenten produktiv einsetzen will, sollte deshalb keine dauerhaften Schlüssel vergeben, sondern auf klar begrenzte Berechtigungen, kurzlebige Tokens und einen vorgeschalteten Gatekeeper setzen. Nicht der leistungsfähigste Agent ist am Ende entscheidend, sondern der sicherste Zugriffspfad.
Sichere Agentensysteme kontrolliert einführen
Sie möchten Agenten im Unternehmen einsetzen, ohne neue Sicherheitslücken zu schaffen? SilverQ unterstützt bei Zugriffsmodellen, Governance und produktionsfähigen Sicherheitsarchitekturen für KI-Systeme