Der erste Prototyp soll nur eingehende Supportanfragen sortieren. Damit er Kundendaten lesen und Tickets ergänzen kann, bekommt er den API-Schlüssel der vorhandenen Integration. Dieser Schlüssel darf allerdings weit mehr: Tickets löschen, Benutzer verwalten und sämtliche Anhänge herunterladen. Für den schnellen Test fällt das kaum auf. Sobald der Agent regelmäßig arbeitet, ist aus einer Abkürzung ein dauerhaft privilegierter Zugang geworden.
So beginnen viele riskante Anbindungen. Das Sprachmodell steht im Mittelpunkt der Diskussion, während die eigentliche Sicherheitsentscheidung in einer Konfigurationsdatei steckt. Zu prüfen sind die erreichbaren Schnittstellen, die freigeschalteten Methoden und die Identität hinter jedem Aufruf. Ein Agent kann nur den Schaden anrichten, den seine Werkzeuge und Berechtigungen zulassen. Sind diese großzügig gewählt, wird jede Fehlentscheidung unnötig teuer.
KI-Agenten unterscheiden sich an dieser Stelle von klassischen Automatisierungen. Ein festes Skript führt einen vorgegebenen Ablauf aus. Ein Agent wählt abhängig von Eingaben und Zwischenergebnissen selbst, welches Werkzeug er als Nächstes nutzt. Er kann fremde Texte aus E-Mails, Dokumenten oder Websites verarbeiten. Darin können fehlerhafte Anweisungen oder gezielte Manipulationsversuche stecken. Die Zugriffsarchitektur muss damit rechnen, dass ein plausibel klingender Werkzeugaufruf fachlich falsch ist.
Die passende Antwort ist kein pauschales Verbot. Unternehmen können Agenten produktiv mit CRM, Dokumentenablage, Warenwirtschaft oder Entwicklungswerkzeugen verbinden. Sie sollten ihnen aber keine digitale Generalschlüsselkarte ausstellen. Jede Aufgabe braucht eine begrenzte Identität, passende Rechte, eine kurze Gültigkeit und einen kontrollierten Weg für kritische Aktionen.
Ein Sprachmodell allein verschickt keine Überweisung und ändert keinen Kundendatensatz. Erst eine angebundene Funktion macht aus Text eine Aktion. Das kann ein einfacher HTTP-Aufruf sein, eine Datenbankabfrage, ein Kommando auf einem Server oder der Zugriff über ein Agentenprotokoll.
Für die Sicherheitsbetrachtung reicht es nicht, die Modellantwort zu prüfen. Der gesamte Pfad zählt: Eingabe, Kontext, Werkzeugauswahl, Autorisierung, Zielsystem und Rückgabe. An jeder Stelle können Annahmen falsch sein. Eine manipulierte E-Mail kann eine Anweisung enthalten, die der Agent als Arbeitsauftrag missversteht. Ein Tool kann zu viele Parameter akzeptieren. Das Zielsystem kann wiederum Rechte gewähren, die der Agent für seine Aufgabe nie benötigt.
OWASP beschreibt dieses Muster als „Excessive Agency“. Die Ursache liegt typischerweise in zu vielen Funktionen, zu weitreichenden Berechtigungen oder zu großer Autonomie. Das ist eine hilfreiche Einordnung, weil sie den Blick von der Qualität eines einzelnen Prompts auf die technische Wirkung verschiebt.
Wir prüfen daher zuerst, was ein Agent tatsächlich ausführen kann. Die Liste seiner verfügbaren Werkzeuge ist aussagekräftiger als eine lange Beschreibung dessen, was er laut Systemprompt tun soll. Ein Prompt ist eine Verhaltensanweisung. Eine serverseitig erzwungene Berechtigung ist eine Grenze.
Ein Agent sollte weder mit dem Konto eines Mitarbeiters noch mit einem gemeinsam verwendeten Administratorzugang arbeiten. Solche Konten vermischen menschliche und automatisierte Aktionen. Bei einem Vorfall bleibt unklar, wer eine Änderung ausgelöst hat. Wird ein Mitarbeiterkonto gesperrt, bricht nebenbei die Automation.
Sauberer ist eine eigene technische Identität pro Agent oder klar abgegrenztem Anwendungsfall. Im Ticketsystem könnte sie beispielsweise agent-support-triage heißen. Diese Identität erhält nur die Rollen, die für das Lesen neuer Anfragen und das Setzen einer Klassifikation nötig sind.
Eine einzige Agentenidentität für alle Abteilungen spart anfangs Konfiguration, schafft später aber dasselbe Problem wie ein geteiltes Servicekonto. Marketing, Buchhaltung und IT hinterlassen denselben technischen Absender. Rechte sammeln sich über Monate an, weil niemand weiß, welche Integration noch welche Funktion verwendet.
Für jede Identität brauchen wir einen Eigentümer. Er entscheidet über neue Rechte, überprüft die Nutzung und kann den Zugang stilllegen. Das Konto trägt einen erkennbaren Zweck und ein Ablauf- oder Prüfdatum. Technische Konten ohne Ansprechpartner bleiben sonst oft jahrelang aktiv.
Die Identität des Agenten darf die Identität des auslösenden Nutzers ergänzen, nicht verdecken. Wenn ein Mitarbeiter eine Aktion anstößt, sollte das Protokoll beide Seiten kennen: den Agenten als technischen Aufrufer und den Menschen oder Prozess als Auftraggeber.
Die Rolle „CRM-Zugriff“ ist für einen Agenten zu ungenau. Ein Vertriebsassistent soll vielleicht Kontakte suchen, Gesprächsnotizen vorbereiten und einen Entwurf für eine Aktivität anlegen. Er muss keine Kontakte exportieren, Eigentümer ändern oder Datensätze endgültig löschen.
Wir zerlegen den gewünschten Ablauf deshalb in konkrete Operationen. Für jede Operation wird festgehalten, welche Daten gelesen, welche Felder geschrieben und welche Zielobjekte angesprochen werden. Aus dieser Tabelle entsteht die technische Policy. Das ist etwas mehr Arbeit als das Aktivieren einer Standardrolle, zeigt aber früh, wenn die API keine ausreichend feinen Rechte anbietet.
Lesen und Schreiben gehören getrennt. Ein Rechercheagent kann auf freigegebene Dokumente zugreifen, ohne Upload- oder Löschrechte zu besitzen. Ein Assistent zur Rechnungsprüfung darf Belege lesen und Auffälligkeiten markieren; die Freigabe einer Zahlung bleibt außerhalb seines Tokens.
Auch innerhalb einer Aktion lässt sich der Umfang begrenzen. Ein Agent benötigt möglicherweise Schreibzugriff auf das Feld „interne Zusammenfassung“, nicht auf Bankverbindung, Vertragsstatus oder Berechtigungsrollen. Gut gestaltete Vermittlungsdienste bieten dafür eigene schmale Funktionen statt einer universellen Methode wie updateRecord(type, id, data).
NIST beschreibt Least Privilege als Beschränkung auf die Ressourcen und Autorisierungen, die eine Einheit für ihre Funktion braucht. Für Agenten übersetzen wir das sehr wörtlich. Erlaubt wird nicht alles, was im normalen Ablauf praktisch sein könnte, sondern das Minimum für den definierten Auftrag.
Viele Unternehmens-APIs wurden für klassische Integrationen gebaut. Ihre Tokens gelten monatelang und ihre Berechtigungen sind grob. Der Agent direkt an einer solchen Schnittstelle müsste einen leistungsfähigen Schlüssel erhalten und die vollständige API-Beschreibung verarbeiten.
In Projekten setzen wir lieber einen kleinen Dienst dazwischen. Er stellt dem Agenten nur die benötigten Funktionen bereit, validiert Parameter und ruft das Zielsystem mit einer kontrollierten Identität auf. Aus „beliebigen CRM-Datensatz ändern“ wird dann beispielsweise „Zusammenfassungsentwurf an offenem Supportticket speichern“.
Diese Schicht kann Objektarten, Felder und Mandanten fest vorgeben. Sie prüft Längen, Dateitypen und erlaubte Statuswechsel. Freitext aus dem Modell landet nicht ungefiltert in einem SQL-Statement oder Shell-Kommando. Das Zielsystem erhält eine technisch normale Anfrage, deren Spielraum vor dem Aufruf feststeht.
Der zusätzliche Dienst wirkt zunächst wie mehr Architektur für eine kleine Automation. Er lohnt sich, sobald eine vorhandene API deutlich mehr kann als der Agent. Neben der Sicherheit verbessert er Wartung und Tests. Änderungen am Zielsystem werden an einer Stelle aufgefangen, während die Werkzeugschnittstelle des Agenten stabil bleibt.
Ein Proxy ist allerdings keine Ausrede für einen mächtigen Backend-Schlüssel. Auch dessen Identität wird auf die nötigen Rechte begrenzt. Wenn die Zielplattform keine passende Autorisierung erlaubt, erzwingt der Vermittlungsdienst wenigstens fachliche Regeln und eine vollständige Protokollierung.
Bei den ersten Versuchen werden Agentenwerkzeuge oft direkt aus einer Entwicklungsumgebung übernommen. Ein Server stellt zehn Funktionen bereit, obwohl der geplante Ablauf nur zwei davon verwendet. Für das Modell bleiben die übrigen Methoden sichtbar und grundsätzlich auswählbar. Ein alter Testaufruf kann damit noch Monate nach dem Prototyp erreichbar sein.
Wir führen deshalb einen freigegebenen Werkzeugkatalog pro Agent. Darin stehen Funktion, Eigentümer, Version, zulässiger Zweck und technische Policy. Neue Werkzeuge erscheinen nicht automatisch in der produktiven Umgebung. Sie durchlaufen denselben Review wie eine neue API-Berechtigung, einschließlich Negativtests und Prüfung der zurückgegebenen Daten.
Bei Plugin- oder MCP-basierten Integrationen wird gern angenommen, die Beschreibung eines Tools sei harmloser Text. Sie beeinflusst jedoch die Werkzeugauswahl des Modells. Änderungen an Namen, Parametern oder Beschreibungen können das Verhalten verschieben, selbst wenn die zugrunde liegende API gleich bleibt. Produktive Versionen werden daher festgelegt und Updates kontrolliert eingespielt.
Ein Tool darf seine Fähigkeiten nicht während eines Laufs beliebig erweitern. Liefert ein externer Dienst dynamisch neue Methoden oder verweist auf weitere Server, entscheidet eine Allowlist, welche davon angenommen werden. Der Agent selbst ist nicht befugt, den eigenen Werkzeugbestand zu vergrößern.
Rückbau gehört ebenfalls zum Prozess. Wird eine Funktion ersetzt, verschwindet die alte Variante aus Konfiguration, Policy und Zugangsdaten. OWASP nennt liegen gebliebene Erweiterungen ausdrücklich als Beispiel für übermäßige Funktionalität. In der Praxis ist das Bereinigen meist unspektakulär, verhindert aber, dass längst vergessene Testwege den Schutz einer ansonsten sauber begrenzten Anbindung umgehen.
Ein API-Schlüssel ohne Ablaufdatum ist bequem. Er liegt dann in einer Umgebungsvariable, einem Workflow oder einem Secret Store und wird über Jahre nicht angefasst. Gelangt er in ein Protokoll oder an einen falschen Prozess, bleibt das Zeitfenster für Missbrauch groß.
Besser sind kurzlebige Zugriffstokens, die für einen konkreten Lauf oder einen kurzen Zeitraum ausgestellt werden. Ein vertrauenswürdiger Broker prüft Identität, Aufgabe und Zielsystem. Danach erstellt er ein Token mit passendem Scope und enger Gültigkeit. Der Agent selbst benötigt keinen dauerhaft nutzbaren Schlüssel zum Fachsystem.
OAuth bietet dafür etablierte Bausteine. RFC 9700 empfiehlt, die Privilegien eines Zugriffstokens auf den Anwendungsfall zu begrenzen und Tokens an bestimmte Ressourcendienste zu binden. Wo die Infrastruktur es unterstützt, erschweren sendergebundene Tokens die Wiederverwendung eines gestohlenen Werts.
Kurzlebig bedeutet nicht automatisch sicher. Ein zehnminütiges Token mit Administratorrechten kann in zehn Minuten viel verändern. Laufzeit, Funktionen, Zielsystem und Datenumfang müssen gemeinsam begrenzt werden.
Statische Schlüssel verschwinden selten sofort aus einer bestehenden Landschaft. Dann gehören sie in einen Secret Manager, werden regelmäßig rotiert und dürfen weder in Prompts noch in Tool-Ausgaben oder Logs erscheinen. OWASP empfiehlt für Secrets eine möglichst kurze Lebensdauer, automatische Rotation, Widerrufbarkeit und klar begrenzte Sichtbarkeit.
Ein Scope namens write klingt beschränkt, kann aber für mehrere APIs gelten. Wird dasselbe Token von CRM, Dokumentenspeicher und Administrationsdienst akzeptiert, reicht ein Fehlaufruf weit über den vorgesehenen Bereich hinaus.
Wir binden Tokens deshalb an eine Zielgruppe, im OAuth-Kontext meist als Audience bezeichnet. Der Ressourcendienst prüft bei jedem Aufruf, ob das Token für ihn ausgestellt wurde. Ein für die Ticket-API bestimmter Zugang darf an der Benutzerverwaltung wertlos sein.
Mandanten- und Objektgrenzen gehören ebenfalls in die Policy. Ein Agent für einen bestimmten Kundenbereich benötigt keinen Zugriff auf alle Mandanten. Ein Dokumentenassistent bekommt einen freigegebenen Ordner oder eine definierte Sammlung, nicht die Wurzel der Unternehmensablage.
Netzwerkregeln ergänzen diese Kontrollen. Eine Agentenumgebung sollte nur die benötigten Ziele erreichen. Freier Internetzugang erleichtert Datenabfluss und macht es schwieriger, fremde Inhalte von erlaubten Geschäftssystemen zu unterscheiden. Egress-Regeln oder ein API-Gateway können Domains und Dienste begrenzen.
Auf Netzwerkstandorte allein verlassen wir uns nicht. NISTs Zero-Trust-Modell richtet Autorisierungsentscheidungen an Identitäten und Ressourcen aus, statt einem Dienst wegen seines internen Netzes pauschal zu vertrauen. Das passt zu Agenten, die zwischen Cloudsystemen, internen APIs und externen Quellen arbeiten.
Ein Agent kann einen Antwortentwurf erstellen und ihn als Entwurf speichern. Das endgültige Versenden an tausend Empfänger ist eine andere Risikoklasse. Ähnlich verhält es sich mit Bestellvorschlag und Bestellung, Dateiauswahl und Löschung oder Codeänderung und Produktivdeployment.
Für solche Übergänge bauen wir einen serverseitigen Freigabeschritt ein. Der Agent reicht Aktion, Ziel, relevante Parameter und eine verständliche Vorschau ein. Ein berechtigter Mitarbeiter bestätigt oder verwirft sie. Erst die Freigabe erzeugt ein kurzlebiges Recht zur konkreten Ausführung.
Eine Chatfrage wie „Soll ich fortfahren?“ ist dafür zu schwach. Das Modell könnte die Antwort falsch zuordnen oder den Schritt in einem späteren Lauf anders interpretieren. Die Freigabe muss technisch an Aktion und Parameter gebunden sein. Ändert sich der Betrag oder Empfängerkreis, verfällt sie.
Die Oberfläche darf den Prüfer nicht mit Rohdaten überladen. Sie zeigt klar, was sich ändern wird, welche Systeme betroffen sind und welche Folgen zu erwarten sind. Bei vielen gleichartigen Freigaben entsteht sonst Gewöhnung, und der Mensch klickt nur noch auf Bestätigen.
Nicht jede Schreibaktion braucht einen Menschen. Das würde den Nutzen einer Automation zerstören. Wir legen Schwellen nach Wirkung und Reversibilität fest. Eine interne Klassifikation lässt sich automatisch setzen. Eine externe Veröffentlichung, Berechtigungsänderung oder endgültige Löschung verlangt eine stärkere Kontrolle.
Ein Agent liest eine Webseite, auf der zwischen normalen Absätzen die Anweisung steht, interne Dokumente an eine fremde Adresse zu senden. Ob das Modell diese Anweisung zuverlässig ignoriert, darf nicht die letzte Schutzlinie sein.
Mit sauberer Autorisierung scheitert der Versuch an mehreren Grenzen. Der Rechercheagent besitzt keinen Zugriff auf interne vertrauliche Ablagen. Sein Versandwerkzeug akzeptiert keine beliebigen Empfänger oder ist gar nicht verfügbar. Die Netzwerkumgebung erreicht die genannte Domain nicht. Eine verdächtige Werkzeugfolge löst einen Alarm aus.
Diese Kontrollen machen Prompt Injection nicht unsichtbar und ersetzen keine Filterung. Sie reduzieren aber die Folgen eines erfolgreichen Angriffs. Das ist im Betrieb wertvoller als das Versprechen, jede manipulierte Formulierung vorab erkennen zu können.
Externe Inhalte behandeln wir als Daten, nicht als autorisierte Befehle. Toolbeschreibungen und Systemregeln legen fest, welche Quellen Anweisungen erteilen dürfen. Der Vermittlungsdienst prüft trotzdem jeden Aufruf unabhängig davon, wie überzeugend seine Begründung klingt.
Ein gewöhnliches API-Log zeigt Zeitpunkt, Route und Statuscode. Bei einem Agenten reicht das oft nicht. Nach einer unerwarteten Änderung müssen wir nachvollziehen können, welcher Lauf sie ausgelöst hat, welcher Nutzer den Auftrag gab und welche Toolentscheidung zur Aktion führte.
Ein brauchbarer Audit-Eintrag enthält eine Lauf-ID, Agentenidentität, auslösende Identität, Werkzeugname, Zielsystem, betroffene Objekte, Entscheidung der Autorisierung und Ergebnis. Bei einer Freigabe kommen Prüfer, Zeitpunkt und gebundene Parameter hinzu.
Prompts und vollständige Dokumentinhalte speichern wir nicht automatisch. Darin können personenbezogene Daten, vertrauliche Texte oder Zugangsdaten vorkommen. Für die Nachvollziehbarkeit reichen oft Hashwerte, Referenzen, klassifizierte Ereignisse und gezielt maskierte Ausschnitte. Aufbewahrungszeit und Zugriffsrechte werden festgelegt.
Secrets dürfen nie im Klartext protokolliert werden. Das klingt selbstverständlich, scheitert aber schnell an Debug-Ausgaben kompletter HTTP-Header oder Toolparameter. Logging-Bibliotheken brauchen Filter, und die Filter selbst müssen getestet werden.
Wir trennen Betriebsmetriken von Audit-Daten. Latenz und Tokenverbrauch helfen beim Betrieb; sie erklären keine Berechtigungsentscheidung. Ein revisionsfähiges Ereignisprotokoll wiederum eignet sich nicht als vollständiges Debug-Archiv. Beide Datensätze haben andere Nutzer und Schutzanforderungen.
Protokolle entfalten ihren Wert erst durch Auswertung. Auffällig sind etwa viele verweigerte Aktionen, Zugriffe außerhalb üblicher Zeiten, neue Zielobjekte oder ungewöhnlich große Datenmengen. Für diese Muster braucht es Alarme und einen benannten Empfänger.
Ein erfolgreicher Demoablauf beweist wenig. Der Agent erhält eine saubere Anfrage, findet den erwarteten Datensatz und ruft das richtige Werkzeug auf. Interessant wird der Test, wenn Informationen fehlen, zwei Kunden denselben Namen tragen oder ein Zielsystem widersprüchliche Daten liefert.
Wir testen absichtlich Aufgaben außerhalb des erlaubten Bereichs. Der Supportagent soll einen Benutzer sperren, einen Datensatz eines anderen Mandanten lesen oder eine Datei an einen freien Empfänger senden. Die Ablehnung muss aus der technischen Policy kommen, nicht aus einer höflichen Modellantwort.
Auch indirekte Anweisungen gehören in die Testfälle. Eine E-Mail, ein PDF oder eine abgerufene Website enthält einen Text, der zur Nutzung eines anderen Werkzeugs auffordert. Danach prüfen wir, welche Aktionen der Agent versucht und wo die Architektur sie stoppt.
Ausfälle liefern weitere Erkenntnisse. Der Test deckt auch den Ausfall des Tokenbrokers, eine abgelaufene Freigabe und eine fehlende Antwort des Zielsystems nach einem Schreibvorgang ab. Wiederholungen dürfen keine doppelten Bestellungen oder Nachrichten erzeugen. Dafür sind idempotente Operationen und eindeutige Auftragskennungen hilfreich.
Der Test umfasst ebenso den Widerruf. Ein kompromittiertes Konto oder fehlerhafter Agent muss schnell stillgelegt werden können. Wir prüfen, wie lange bereits ausgestellte Tokens noch gelten und ob wartende Aufträge nach der Sperrung ausgeführt werden.
Berechtigungen beschreiben meist Funktionen, aber selten Mengen. Ein Agent mit Leserecht kann technisch korrekt handeln und trotzdem zehntausende Dokumente abrufen. Das verursacht Kosten, belastet Systeme und vergrößert bei einem Fehler den Datenabfluss.
Quoten gehören deshalb zur Policy. Pro Lauf lassen sich Zahl der Werkzeugaufrufe, Datensätze, Empfänger oder übertragene Bytes begrenzen. Zeitbudgets verhindern Schleifen, in denen der Agent denselben Fehler immer neu zu lösen versucht.
Bei Schreibvorgängen setzen wir fachliche Grenzwerte. Ein Einkaufsagent darf Vorschläge bis zu einem bestimmten Betrag vorbereiten. Eine Sammelaktion über viele Objekte wechselt automatisch in einen Freigabemodus. Diese Regeln liegen außerhalb des Modells und gelten auch bei einer ungewöhnlichen Eingabe.
Die passende Grenze entsteht aus dem Prozess, nicht aus einer allgemeinen Agenteneinstellung. Ein Recherchelauf darf viele Seiten lesen, aber nichts versenden. Ein Benachrichtigungsagent benötigt Versandzugriff, erhält dafür einen kleinen, fest definierten Empfängerkreis.
In einer gewachsenen Umgebung stehen selten sofort feingranulare Tokens und ein zentraler Policy-Dienst bereit. Das ist kein Grund, den gemeinsamen Admin-Schlüssel unverändert zu lassen. Schon die Trennung einer Agentenidentität vom vorhandenen Integrationskonto verbessert Zuordnung und Widerruf.
Als Nächstes entfernen wir ungenutzte API-Methoden aus der Tooldefinition und sperren sie im Vermittlungsdienst. Schreibrechte werden von Leserechten getrennt. Besonders wirkungsvolle Aktionen erhalten einen Freigabeschritt.
Danach folgen kürzere Tokenlaufzeiten, Audience-Bindung und automatische Rotation. Die Reihenfolge richtet sich nach dem Risiko. Ein Agent mit Zugriff auf öffentliche Produktinformationen braucht weniger Aufwand als ein System, das Kundendaten verarbeitet oder Bestellungen auslösen kann.
Gerade bei bestehenden Anwendungen zeigt sich oft, dass die API selbst zu grob geschnitten ist. Dann lohnt sich eine kleine fachliche Schnittstelle. Davon profitieren die Agentenanbindung und andere Automationen, weil Validierung und Berechtigungslogik nicht länger in jedem Client stecken.
Während des Umbaus bleiben alte Schlüssel sichtbar im Inventar. Jeder Zugang erhält Zweck, Eigentümer, Ablauftermin und geplanten Ersatz. Erst wenn Aufrufe über die neue Identität stabil laufen, wird der bisherige Schlüssel widerrufen.
Nach dem Umbau beginnt die regelmäßige Rechteprüfung. Wir vergleichen die vergebenen Scopes mit den tatsächlich protokollierten Aufrufen. Eine seit Monaten ungenutzte Funktion wird nicht vorsorglich behalten, sondern entfernt. Benötigt der Prozess sie später wieder, kann der Eigentümer sie begründet neu beantragen.
Auch organisatorische Änderungen lösen eine Prüfung aus. Wechselt der verantwortliche Fachbereich, endet ein Pilot oder verarbeitet der Agent eine neue Datenklasse, passen die bisherigen Annahmen möglicherweise nicht mehr. Die technische Identität bleibt zwar dieselbe, ihre Aufgabe hat sich aber verändert. Genau dieser schleichende Funktionszuwachs macht aus eng begrenzten Prototypen mit der Zeit weitreichende Integrationen.
Für einen ersten produktiven Anwendungsfall wählen wir eine Aufgabe mit begrenzter Wirkung. Der Agent darf Informationen aus einem freigegebenen Bereich lesen und einen Entwurf erzeugen. Die Veröffentlichung oder Änderung im Fachsystem bleibt zunächst bei einem Menschen.
Vor dem Start dokumentieren wir seine Identität, erreichbaren Dienste, erlaubten Funktionen und Mengengrenzen auf einer Seite. Das Team benennt einen Eigentümer und einen Weg zur sofortigen Sperrung. Jede Aktion erhält eine Lauf-ID, die sich vom Auftrag bis zum Zielsystem verfolgen lässt.
Nach einigen Wochen zeigen die Protokolle, welche Funktionen tatsächlich genutzt werden und wo Freigaben unnötig bremsen. Rechte können gezielt erweitert werden, wenn ein klarer Bedarf und passende Kontrollen vorliegen. Vorratsberechtigungen vergeben wir nicht.
Die technische Leitfrage bleibt schlicht: Welche maximale Wirkung hat ein falscher Werkzeugaufruf? Wenn die Antwort eine große Datenmenge, externe Kommunikation oder irreversible Änderung umfasst, ist die Aufgabe noch zu breit geschnitten. Dann verkleinern wir Tool, Token oder Autonomie, bevor der Agent mehr Verantwortung erhält.