AI Security · 10 Min.
Agentic Security Model 2026: Tool-Use, Identitaet und Freigaben
Sobald Agenten Tools nutzen, wird Security nicht mehr nur Modellschutz. Es geht um Identitaet, Rechte und nachvollziehbare Aktionen.
SYSTEMS Grafik zu Agentic Security Model: Risk -> Guardrail -> Audit. Fokus: Wie baut man ein Security-Modell fuer KI-Agenten, die echte Tools und Daten nutzen?
Kurzfassung
Agenten-Security beginnt, sobald KI Tools nutzen oder Daten veraendern darf. Identitaet, Rechte, Freigaben und Audit Logs muessen gemeinsam entworfen werden. Gute Security ermoeglicht 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 Identitaet, 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 druecken. Deshalb gehoeren Allowlists, Risk-Tiers, Human-in-the-Loop und Audit-Logs in die Architektur, nicht in eine spaetere 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 pruefbar. Ohne sie entsteht ein unsichtbarer Superuser mit natuerlicher Sprache als Interface.
Nutzeridentitaet: Wer hat den Auftrag gestartet? Agentenidentitaet: Welcher Agent fuehrt die Aktion aus? Workspace- oder Mandantenkontext: In welchem Datenraum passiert die Aktion? Tool-Identitaet: Welches System wird beruehrt? Zweckbindung: Warum ist dieser Zugriff fuer 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 veraendern, E-Mails vorbereiten, Daten schreiben oder Workflows starten.
Damit wird die zentrale Frage: Unter welcher Identitaet handelt der Agent und welche Rechte hat er?
Identitaet vor Tool-Zugriff Ein Agent sollte nicht als unsichtbarer Superuser arbeiten. Jede Aktion braucht eine nachvollziehbare Identitaet: Agent, Nutzer, Workspace, Rolle und Zweck.
Nur so kann ein Unternehmen spaeter pruefen, warum ein Tool gerufen wurde und wer die Verantwortung fuer die Aktion traegt.
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 ausfuehren. Stufe 4: autonom ausfuehren 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.
Fuer 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 ausloesen, Vertrag akzeptieren, Account loeschen, Berechtigung veraendern. erlaubte Rollen erlaubte Datenquellen erlaubte Zielsysteme maximale Autonomie Freigabeform Log-Pflicht Rollback-Faehigkeit 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 gefaehrlich.
Deshalb muss der Agent externe Inhalte als Daten behandeln, nicht als Befehle. Tools brauchen zusaetzliche Pruefung, wenn Inputs aus untrusted Sources kommen.
OpenAI empfiehlt fuer 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 fuer kaeufliche, destruktive, authentifizierte oder schwer rueckgaengig zu machende Aktionen dazu.
Freigaben als Architekturbaustein Freigaben sollten nicht nachtraeglich eingebaut werden. Sie gehoeren in den Workflow. Der Agent muss wissen, wann er anhaelt, was er dem Menschen zeigt und welche Information fuer eine Entscheidung noetig ist.
Gute Freigaben sind kurz, kontextreich und pruefbar. Schlechte Freigaben sind nur "OK?".
Eine gute Freigabe zeigt:
geplante Aktion betroffenes System Datenquelle Risiko-Stufe erwartetes Ergebnis Rueckgaengigmachbarkeit Grund, warum der Agent nicht selbst entscheiden darf Audit Logs muessen 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 Ueberwachung um der Ueberwachung willen. Das Ziel ist, Fehler zu verstehen und Rechte sicher erweitern zu koennen.
Der SYSTEMS-Blick Agenten-Security ist keine Bremse. Sie ist die Voraussetzung, damit Unternehmen Agenten mehr Arbeit geben koennen.
Wer Tool-Use, Identitaet, Rechte und Freigaben sauber baut, muss weniger Angst vor Autonomie haben.
