KI-Agenten zwingen Zero Trust, das Netzwerk zu verlassen
Die neuesten Leitlinien zum Umgang mit dem Cyberrisiko agentischer KI treffen einen Punkt, auf den Unternehmenssicherheitsteams bereits reagieren sollten: Ein KI-Agent ist nicht einfach ein weiterer Anwendungsbenutzer.
Er liest nicht vertrauenswürdige Inhalte, erstellt einen Plan und verwendet Anmeldedaten, um systemübergreifend zu handeln. Diese Kombination bricht eine bequeme Annahme vieler Zero-Trust-Programme: dass eine authentifizierte Identität innerhalb eines genehmigten Workflows ausreichend vorhersehbar ist.
Das ist sie nicht.
Ein menschlicher Mitarbeiter kann eine breite Rolle haben. Ein konventioneller Dienst hat eine enge Funktion. Ein Agent nimmt eine schwierige und riskante Mittelstellung ein. Er kann den Zugriff einer Person erben, eine bösartige E-Mail oder ein Dokument verarbeiten, ein verbundenes Tool aufrufen und verschiedene Varianten einer Aktion ausprobieren. Seine Identität kann gültig sein, während sein nächster Schritt völlig außerhalb der Absicht der Person liegt, die ihn gestartet hat.
Deshalb verändert sich die Unternehmens-KI-Diskussion. Die Frage ist nicht mehr nur, ob das Modell genehmigt ist. Es geht darum, ob jede Aktion, die das Modell auslösen kann, ausdrücklich autorisiert, begrenzt und beobachtbar ist.
Zero Trust muss für jeden Werkzeugaufruf gelten
Ein gutes Zero-Trust-Programm verlangt eine Verifizierung, bevor Zugriff gewährt wird. Agentische KI benötigt dasselbe Prinzip auf feinerer Ebene: vor jedem folgenschweren Werkzeugaufruf.
Betrachten Sie einen Agenten, der einem Beschaffungsteam bei der Prüfung von Lieferantenverträgen hilft. Ein Dokument lesen und eine Zusammenfassung erstellen ist geringes Risiko. Einen Entwurf im Vertragssystem erstellen ist folgenreicher. Die Zahlungsdaten eines Lieferanten ändern, einen Ordner mit Verträgen exportieren oder eine Nachricht extern senden ist nochmals anders.
Diese Aktionen sollten nicht durch denselben dauerhaften OAuth-Zugriff geschützt sein, nur weil sie in einem Workflow erscheinen.
Behandeln Sie jede Aktion als Entscheidung mit fünf Eingaben:
- **Agenten-Identität:** Welcher spezifische Agent und welche Version stellt die Anfrage?
- **Menschlicher und geschäftlicher Kontext:** Wer hat sie initiiert und welche genehmigte Aufgabe wird ausgeführt?
- **Datenkontext:** Welche Daten werden gelesen, geschrieben oder gesendet und wie sensibel sind sie?
- **Werkzeug und Umgebung:** Welcher Connector ist beteiligt und handelt es sich um ein Sandbox- oder Produktivsystem?
- **Auswirkung der Aktion:** Ist die Anfrage reversibel, begrenzt und intern oder verändert sie Geld, Berechtigungen, Datensätze oder externe Kommunikation?
Eine Richtlinien-Engine muss nicht jeden risikoarmen Workflow verlangsamen. Sie muss jedoch eine Suche von einer Zahlungsänderung unterscheiden können. Wenn nicht, hat die Organisation eine Umgebungsberechtigung erteilt: Anmeldedaten, die technisch gültig, aber für die jeweilige Aufgabe zu breit sind.
Die Eingabeaufforderung ist nicht die Richtliniengrenze
Teams versuchen immer noch, Agentenrisiken mit besseren Anweisungen zu lösen. Sie schreiben eine Regel wie „Kundendaten niemals extern senden“ und verbinden dann den Agenten mit E-Mail, Dateispeicher und CRM über ein langlebiges Token.
Das ist eine Anweisung, keine Durchsetzung.
Indirekte Prompt-Injektion macht die Lücke deutlich. Ein Agent kann feindliche Anweisungen in einer Webseite, einem Ticket, einer Tabelle oder einem Dokument finden. Selbst ein gut gestaltetes Modell kann manipuliert werden, um einen unsicheren Werkzeugaufruf zu wählen. Entscheidend ist nicht, ob der Agent angewiesen wurde, sich zu verhalten, sondern ob der Connector eine Aktion ablehnt, die gegen die Richtlinie verstößt.
Für folgenschwere Arbeiten verlagern Sie die Grenze aus dem Chat in Identitäts- und Zugriffskontrollen. Verwenden Sie dedizierte Agenten-Identitäten. Geben Sie kurzlebige Anmeldedaten, die an eine Aufgabe gebunden sind. Beschränken Sie Werkzeugbereiche auf das kleinste nützliche Set. Erfordern Sie eine Genehmigung für irreversible, extern sichtbare oder wertvolle Aktionen.
Das ist vertraute Sicherheitsentwicklung. Der Unterschied ist die Geschwindigkeit, mit der Agentenentwickler jetzt einen Workflow erstellen können, der all diese Grenzen überschreitet, ohne eine traditionelle Änderungsanforderung zu öffnen.
Schatten-KI wird zu Schatten-Autorität
Die meisten Organisationen haben ihre KI-Governance-Arbeit mit der Inventarisierung von Modellen und genehmigten Chat-Tools begonnen. Das bleibt wichtig. Aber das schwierigere Problem ist zu entdecken, wo KI Autorität erlangt hat.
Ein browserbasierter Assistent, der ein Cloud-Dokument öffnen kann, ein No-Code-Workflow mit Postfach-Connector, ein Programmieragent mit Entwickler-Token und ein Vertriebssystem, das ein CRM aktualisieren kann, bergen unterschiedliche Risiken. Keines muss wie eine formale „KI-Plattform“ aussehen, um produktionsnah zu sein.
Das ist die nächste Form von Schatten-KI: nicht nur nicht genehmigte Modellausführung, sondern unbeobachteter KI-Systemzugriff.
Ein nützliches Inventar sollte daher mehr als nur Anbieter und Eigentümer erfassen. Für jeden Agenten oder KI-gestützten Workflow sollten Sicherheitsverantwortliche beantworten können:
- Auf welche Daten kann er zugreifen, auch über nachgelagerte Connectoren?
- Welche Aktionen kann er ausführen und in welchen Umgebungen?
- Welche Identität, welches Token oder welcher delegierte Benutzerkontext ermöglicht diese Aktionen?
- Welches Ereignis löst ihn aus und welche nicht vertrauenswürdigen Inhalte können ihn beeinflussen?
- Was stoppt ihn, wenn die Aufgabe, der Benutzerzugang oder die geschäftliche Genehmigung abläuft?
Wenn die Antwort nur in einer Anbieter-Admin-Konsole oder im Gedächtnis eines Projektverantwortlichen lebt, hat die Governance die Nutzung noch nicht eingeholt.
Bauen Sie ein Aktionsprotokoll, keine weitere Tabelle
Die praktische Antwort ist ein Aktionsprotokoll: ein lebendiges Verzeichnis, das Entdeckung, Identität, Datenzugriff, Werkzeugberechtigungen und Richtlinienentscheidungen verbindet. Es sollte den Weg vom initiierenden Benutzer und Geschäftszweck bis zur genauen Aktion zeigen, die ein Agent versucht hat, und ob die Kontrolle sie erlaubt, blockiert oder eskaliert hat.
Das gibt Sicherheitsteams etwas, das sie betreiben können. Es unterstützt die Vorfallreaktion bei unerwartetem Agentenverhalten. Es ermöglicht Compliance-Teams, Aufsicht nachzuweisen. Und es gibt Geschäftsteams einen Weg, nützliche Agenten einzusetzen, ohne auf ein pauschales Ja oder Nein warten zu müssen.
Beginnen Sie mit vier Aktionsstufen:
1. Lesen und Entwurf: Erlauben Sie Aktionen innerhalb genehmigter Datenbereiche; protokollieren Sie sie. 2. Empfehlen: Lassen Sie den Agenten eine Änderung vorbereiten, die Ausführung bleibt jedoch bei einer Person. 3. Begrenzte Ausführung: Erlauben Sie reversible Aktionen mit Transaktions-, Ziel- und Zeitlimits. 4. Ausführung mit hohem Einfluss: Erfordern Sie einen expliziten Genehmiger und eine Just-in-Time-Berechtigung für Geldbewegungen, Privilegienänderungen, Produktionsänderungen, Massenexporte, Löschungen oder externe Sendungen.
Wichtig ist das Wort Ausführung. Eine Modellrisikobewertung kann sagen, ob ein Werkzeug geeignet ist. Sie kann nicht allein kontrollieren, was ein verbundener Agent um 2 Uhr morgens mit einem gültigen Token tut.
Machen Sie Autorität sichtbar, bevor sie zum Vorfall wird
Agentische KI kann Teams deutlich beschleunigen. Die vernünftige Reaktion ist nicht, sie zu verbieten oder jede Anfrage manuell prüfen zu lassen. Es ist, Autorität bewusst zu gestalten.
Aona hilft Sicherheits- und Governance-Teams, KI-Nutzung in der Umgebung zu entdecken, zu identifizieren, wo Agenten und Werkzeuge auf sensible Daten zugreifen können, und Kontrollen anzuwenden, die auf Daten-, Identitäts- und Aktionsebene durchsetzbar sind. [Sehen Sie, wie Aona KI-Governance angeht](https://aona.ai/?utm_source=blog&utm_medium=internal&utm_campaign=agent-zero-trust) und [entdecken Sie unsere Ressourcen zu Schatten-KI](https://aona.ai/resources?utm_source=blog&utm_medium=internal&utm_campaign=agent-zero-trust).
Die Leitlinien dieser Woche sind ein nützlicher Anstoß für eine direkte Frage: Kann Ihr Team die nächste folgenschwere Aktion eines Agenten einem benannten Eigentümer, einer aktuellen Genehmigung und einer zeitlich begrenzten Berechtigung zuordnen? Wenn nicht, haben Sie noch kein Zero Trust für KI-Agenten. Sie haben Vertrauen, das nicht geprüft wurde.
