Die Genehmigungsschuld, die sich in Ihrem KI-Agenten-Rollout verbirgt
Die jüngste gemeinsame Richtlinie zu agentischer KI vom Australian Cyber Security Centre, CISA, NSA und Partnerbehörden gibt eine Empfehlung, die jedes Enterprise-KI-Programm stoppen sollte: Geben Sie Agenten keinen breiten oder uneingeschränkten Zugriff, insbesondere nicht auf sensible Daten und kritische Systeme.
Das klingt offensichtlich. Genau hier scheitern die meisten Agenten-Rollouts stillschweigend.
Das Scheitern ist meist kein dramatischer Entschluss, einem KI-Agenten Domain-Admin-Rechte zu geben. Es sind viele vernünftige Abkürzungen: ein gemeinsames Servicekonto für einen Pilotversuch; ein OAuth-Grant, der breiter ist als nötig; ein Sandbox-Connector, der in der Produktion aktiv bleibt; ein Manager, der das Geschäftsergebnis verantwortet, aber nicht die Zugangsdaten; ein entfallener Genehmigungsschritt, weil er die Demo verlangsamte.
Diese Abkürzungen erzeugen Genehmigungsschulden. Sie wachsen, während das Team die Einführung feiert und einen Geschäftsprozess in eine Sicherheitsentscheidung verwandelt, ohne dass dies explizit geschieht.
Agenten verwandeln Berechtigungen in Verhalten
Ein Chatbot kann Informationen preisgeben. Ein Agent kann Informationen preisgeben, entscheiden, was als Nächstes zu tun ist, ein Tool aufrufen, bei Fehlern erneut versuchen und Arbeit an ein anderes System übergeben. Die Sicherheitsfrage lautet nicht mehr nur: „Kann diese Identität diese Daten lesen?“
Sie lautet: „Kann dieser Agent diese Daten über dieses Tool nutzen, um diese Aktion in dieser Umgebung für diesen genehmigten Zweck auszuführen?“
Das ist eine deutlich anspruchsvollere Frage. Traditionelles IAM wurde für Menschen mit relativ stabilen Rollen und Servicekonten für definierte Workloads entwickelt. Agenten sind zielorientiert. Ihre Berechtigungen können technisch gültig sein, während ihre nächste Aktion außerhalb dessen liegt, was das Unternehmen vorgesehen hat.
Die gemeinsame Richtlinie weist auf die erweiterte Angriffsfläche hin, die durch Agenten-Tools, externe Datenquellen, Speicher und Integrationen entsteht. Sie hebt auch indirekte Prompt-Injektionen hervor: bösartiger Inhalt in E-Mails, Dokumenten oder Webseiten kann einen Agenten beeinflussen, der diese Inhalte lesen und darauf reagieren darf. Dies ist kein theoretisches Modellproblem, sondern die praktische Folge der Anbindung eines autonomen Systems an reale Unternehmenssysteme.
Eine nützliche Regel folgt daraus: Jede Berechtigung, die ein Agent erhält, muss als mögliche Aktion bewertet werden, nicht nur als möglicher Lesezugriff.
Entdeckung ist notwendig. Sie ist keine Governance.
Viele Organisationen beginnen damit, genehmigte KI-Tools zu katalogisieren und Mitarbeiter aufzufordern, Agenten zu registrieren. Was man nicht findet, kann man nicht steuern.
Ein Inventar, das bei Agentenname, Anbieter und Besitzer endet, ist meist nur ein Beruhigungsmittel. Es sagt dem Sicherheitsteam nicht, ob der Agent ein dauerhaftes Zugangskonto nutzt, ob er Daten zwischen Systemen verschieben kann, ob er kürzlich aktiv war oder ob er irreversible Aktionen ohne menschliche Kontrolle ausführen kann.
Ein steuerbarer Agenteneintrag benötigt mindestens fünf Felder:
- **Geschäftsverantwortlicher:** Die verantwortliche Person, die erklären kann, warum der Agent existiert und das Risiko akzeptiert.
- **Genehmigter Zweck:** Ein spezifisches, abgegrenztes Ergebnis. „Unterstützung der Betriebsabläufe“ ist kein Zweck. „Erstellung eines wöchentlichen Berichts über Inventurdifferenzen aus diesen genehmigten Quellen“ schon.
- **Identität und Zugriffsweg:** Jeder OAuth-Grant, API-Schlüssel, Servicekonto, Connector und delegierter Benutzerkontext.
- **Aktionsgrenze:** Was der Agent lesen, erstellen, ändern, senden, genehmigen oder löschen darf, einschließlich der beteiligten Systeme und Umgebungen.
- **Lebenszyklusstatus:** Pilot, genehmigt, Produktion, pausiert, außer Dienst. Auch ruhende Agenten und verwaiste Zugangsdaten benötigen einen Status.
Ist eines dieser Felder unbekannt, ist der Agent nicht bereit für kritische Aufgaben. Er sollte nicht als vertrauenswürdiger Produktionsakteur behandelt werden.
Ersetzen Sie pauschale Genehmigungen durch Aktionsstufen
Der schnellste Weg, Agenten-Governance operational zu machen, ist, nicht „den Agenten“ als einzelnes Objekt zu genehmigen. Genehmigen Sie stattdessen Kategorien von Aktionen.
Beispielsweise darf ein Support-Agent die bestehende Ticket-Historie eines Kunden lesen und eine Antwort entwerfen. Er darf einen Entwurf für ein neues Ticket erstellen. Er sollte jedoch nicht berechtigt sein, Kundendaten zu exportieren, Kontoberechtigungen zu ändern oder Massenmails zu senden, nur weil er Zugriff auf die Support-Plattform hat.
Ein praktisches Stufungsmodell sieht so aus:
1. Beobachten: Suchen, zusammenfassen, klassifizieren und entwerfen. Aktivitäten protokollieren, aber für jede risikoarme Aktion keine Person benötigen. 2. Empfehlen: Änderungen einem menschlichen Verantwortlichen vorschlagen. Der Agent kann Beweise sammeln und die Änderung vorbereiten, aber nicht ausführen. 3. Mit Schutzmaßnahmen ausführen: Rückgängig machbare, begrenzte Änderungen in genehmigten Systemen vornehmen. Transaktionslimits, Umgebungsbeschränkungen und vollständige Audit-Logs durchsetzen. 4. Hochwirksame Aktionen: Zahlungen, Privilegienänderungen, Produktionsbereitstellungen, Massenexporte, externe Kommunikation und Löschungen. Erfordern explizite menschliche Genehmigung und ein eng gefasstes, kurzlebiges Berechtigungszertifikat.
Dieser Ansatz ermöglicht es Teams, schnell zu agieren, ohne so zu tun, als sei jede Agentenaktion gleich riskant. Er gibt Sicherheits- und Compliance-Teams eine überprüfbare Richtlinie.
Die wichtigste Kontrolle ist kurzlebige Autorität
Ein Agent, der dauerhafte, breite Zugangsdaten benötigt, ist meist ein Agent, dessen Design seiner Ambition nicht hinterherkommt.
Nutzen Sie wann immer möglich Just-in-Time-Zugriff. Binden Sie die Autorität an Aufgabe, Umgebung, Datenklassifikation und Zeitfenster. Geben Sie dem Agenten eine eigene Identität statt eines geteilten Benutzerkontos. Lassen Sie die Zugangsdaten mit Abschluss der genehmigten Aufgabe verfallen. Legen Sie Produktionsaktionen hinter einen Genehmigungsworkflow, nicht hinter einen Prompt.
Das ist wichtig, weil Modellverhalten keine Sicherheitsgrenze ist. Ein Systemprompt kann einen Agenten lenken, aber kein API-Token widerrufen oder einen Connector daran hindern, eine gültige Anfrage zu akzeptieren. Die Durchsetzung muss auf Identitäts-, Tool- und Datenebene erfolgen, wo Aktionen tatsächlich stattfinden.
Das bedeutet auch, dass das Logging für Untersuchungen ausgelegt sein muss, nicht für Showeffekte. Protokollieren Sie Agentenidentität, initiierenden Nutzer oder Workflow, aufgerufene Tools, genutzte Datenquellen, Richtlinienentscheidung, Aktionsergebnis und Genehmiger bei kritischen Aktionen. Ein Chat-Transkript allein erklärt kein Sicherheitsereignis.
Bauen Sie die Kontroll-Ebene auf, bevor die Agentenlandschaft unsichtbar wird
Die Behörden hinter der neuen Richtlinie empfehlen, agentische KI-Risiken mit bestehenden Sicherheitsmodellen abzugleichen, statt KI als eigene Disziplin zu behandeln. Das ist der richtige Ansatz. Agenten-Governance gehört zu IAM, Datensicherheit, Anwendungssicherheit, Cloud-Sicherheit und Change Management.
Das Problem ist, dass Enterprise-Agenten heute in SaaS-Plattformen, internen Apps, Coding-Tools, Workflow-Automatisierung und von Mitarbeitern gebauten Prototypen auftauchen. Plattform-spezifische Einstellungen schaffen keine unternehmensweite Kontrolle. Sie erzeugen fragmentierte Sichtbarkeit und inkonsistente Durchsetzung.
Hier wird Shadow KI gefährlich. Nützliche Agenten sind leicht zu erstellen und schwer zu erkennen, sobald sie einen echten Connector nutzen. Ein Marketing-Workflow mit Zugriff auf Kundenlisten, ein browserbasierter Analysten-Agent mit Cloud-Token oder eine lokale Entwickler-Automatisierung können alle produktionsnah werden, bevor die Sicherheit überhaupt eine Änderungsanfrage sieht.
Aona hilft Organisationen, KI-Nutzung im gesamten Umfeld zu entdecken, zu verstehen, welche Tools und Agenten sensible Daten berühren, und Governance anzuwenden, die nicht jedes Team ausbremst. Ziel ist nicht, Agenten zu verbieten, sondern ihre Autorität vor Genehmigungsschulden explizit, begrenzt und prüfbar zu machen.
Die Frage für Sicherheitsverantwortliche diese Woche ist einfach: Welche Ihrer Agenten können heute handeln, und wer hat jede ihrer möglichen Aktionen explizit genehmigt? Wenn die Antwort eine Tabelle, ein Vendor-Console oder „wir glauben, der Besitzer ist noch im Team“ ist, haben Sie Genehmigungsschulden. Beginnen Sie jetzt, diese abzubauen.
