AI Security · 10 Min.
Agentic Security Model 2026: Tool-Use, Identität und Freigaben
Sobald Agenten Tools nutzen, wird Security nicht mehr nur Modellschutz. Es geht um Identität, Rechte und nachvollziehbare Aktionen.
SYSTEMS Grafik zu Agentic Security Model: Risk -> Guardrail -> Audit. Fokus: Wie baut man ein Security-Modell für KI-Agenten, die echte Tools und Daten nutzen?
Kurzfassung
Agenten-Security beginnt, sobald KI Tools nutzen oder Daten verändern darf. Identität, Rechte, Freigaben und Audit Logs müssen gemeinsam entworfen werden. Gute Security ermöglicht mehr Autonomie, weil riskante Aktionen kontrolliert werden.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknüpfe es mit den nächsten Architekturentscheidungen.
Update Mai 2026: Agentic Security wird zur eigenen Risikoklasse OWASP behandelt agentische Anwendungen inzwischen getrennt, weil autonome Tool-Nutzung andere Fehler erzeugt als ein klassischer Chatbot. Dazu kommt: Computer-Use- und Browser-Agenten bringen Screenshots, Webseiten, Logins, Formulare und externe Instruktionen in denselben Loop. Das ist produktiv, aber nur, wenn Identität, Tool-Scopes und Freigaben vor dem ersten autonomen Schreibzugriff stehen.
Die wichtigste Verschiebung: Prompt-Injection ist nicht nur ein Textproblem. Sie wird zum Aktionsproblem. Ein manipuliertes Dokument, eine Webseite oder ein Ticket kann den Agenten zu einem Tool-Call drücken. Deshalb gehören Allowlists, Risk-Tiers, Human-in-the-Loop und Audit-Logs in die Architektur, nicht in eine spätere Security-Phase.
Die neue Sicherheitsfrage: Wer handelt gerade wirklich? Bei Agenten reicht "der Nutzer hat gefragt" nicht als Autorisierung. Ein produktives System muss unterscheiden:
Erst diese Kombination macht Rechte prüfbar. Ohne sie entsteht ein unsichtbarer Superuser mit natürlicher Sprache als Interface.
Nutzeridentität: Wer hat den Auftrag gestartet? Agentenidentität: Welcher Agent führt die Aktion aus? Workspace- oder Mandantenkontext: In welchem Datenraum passiert die Aktion? Tool-Identität: Welches System wird berührt? Zweckbindung: Warum ist dieser Zugriff für diese Aufgabe notwendig? Warum klassische LLM-Security nicht reicht Bei einfachen Chatbots geht es vor allem um falsche Antworten, Prompt Injection und Datenabfluss. Bei Agenten kommt eine neue Ebene dazu: Aktionen. Der Agent kann Systeme lesen, Tickets verändern, E-Mails vorbereiten, Daten schreiben oder Workflows starten.
Damit wird die zentrale Frage: Unter welcher Identität handelt der Agent und welche Rechte hat er?
Identität vor Tool-Zugriff Ein Agent sollte nicht als unsichtbarer Superuser arbeiten. Jede Aktion braucht eine nachvollziehbare Identität: Agent, Nutzer, Workspace, Rolle und Zweck.
Nur so kann ein Unternehmen später prüfen, warum ein Tool gerufen wurde und wer die Verantwortung für die Aktion trägt.
Rechte nach Risiko staffeln Nicht jeder Tool-Zugriff ist gleich riskant. Lesen ist anders als Schreiben. Ein Entwurf ist anders als Versand. Eine CRM-Notiz ist anders als ein Vertragsabschluss.
Diese Staffelung macht Autonomie steuerbar.
Stufe 1: lesen und zusammenfassen. Stufe 2: Entwurf vorbereiten. Stufe 3: mit menschlicher Freigabe ausführen. Stufe 4: autonom ausführen in enger Zone. Stufe 5: verboten oder nur manuell. Tool-Use-Risiko-Matrix Ein Security-Modell sollte Tools nicht nach Namen bewerten, sondern nach Auswirkung.
Für jede Stufe braucht es andere Regeln:
So wird Tool-Use nicht pauschal verboten, sondern kontrolliert erweitert.
Niedriges Risiko: Suche, Lesen, Zusammenfassen, Formatieren. Mittleres Risiko: Entwurf erzeugen, Datensatz markieren, interne Notiz vorbereiten. Hohes Risiko: E-Mail versenden, CRM-Feld schreiben, Ticket schliessen, Rechnung vorbereiten. Kritisches Risiko: Zahlung auslösen, Vertrag akzeptieren, Account löschen, Berechtigung verändern. erlaubte Rollen erlaubte Datenquellen erlaubte Zielsysteme maximale Autonomie Freigabeform Log-Pflicht Rollback-Fähigkeit Prompt Injection trifft Tool-Use Ein Agent, der Webseiten, Dokumente oder E-Mails liest, kann dort manipulative Anweisungen finden. Wenn er diese Anweisungen mit Systemanweisungen verwechselt, wird Tool-Use gefährlich.
Deshalb muss der Agent externe Inhalte als Daten behandeln, nicht als Befehle. Tools brauchen zusätzliche Prüfung, wenn Inputs aus untrusted Sources kommen.
OpenAI empfiehlt für Agenten-Workflows, untrusted input nicht direkt Verhalten steuern zu lassen, sondern strukturierte und validierte Felder zu extrahieren. Bei Computer-Use-Szenarien kommen isolierte Browser oder Container, Domain- und Aktions-Allow-Lists sowie menschliche Freigaben für käufliche, destruktive, authentifizierte oder schwer rückgaengig zu machende Aktionen dazu.
Freigaben als Architekturbaustein Freigaben sollten nicht nachträglich eingebaut werden. Sie gehören in den Workflow. Der Agent muss wissen, wann er anhält, was er dem Menschen zeigt und welche Information für eine Entscheidung nötig ist.
Gute Freigaben sind kurz, kontextreich und prüfbar. Schlechte Freigaben sind nur "OK?".
Eine gute Freigabe zeigt:
geplante Aktion betroffenes System Datenquelle Risiko-Stufe erwartetes Ergebnis Rückgaengigmachbarkeit Grund, warum der Agent nicht selbst entscheiden darf Audit Logs müssen hilfreich sein Ein Audit Log sollte nicht nur speichern, dass ein Tool gerufen wurde. Es sollte Zweck, Input-Kategorie, Ergebnis, Kosten, Freigabe und Risiko festhalten.
Das Ziel ist nicht Überwachung um der Überwachung willen. Das Ziel ist, Fehler zu verstehen und Rechte sicher erweitern zu können.
Der SYSTEMS-Blick Agenten-Security ist keine Bremse. Sie ist die Voraussetzung, damit Unternehmen Agenten mehr Arbeit geben können.
Wer Tool-Use, Identität, Rechte und Freigaben sauber baut, muss weniger Angst vor Autonomie haben.
