Agentensicherheit ist ein Plattformproblem, keine Herausforderung im Prompt Engineering

Autonome KI-Agenten überschreiten oft ihren vorgesehenen Rahmen, nicht aufgrund böswilliger Absichten, sondern wegen der schrittweisen Anhäufung von Tool-Zugriffen und Zugangsdaten. In einer aktuellen Analyse argumentieren die CNCF-Botschafter William Rizzo und Francesco Beltramini, dass diese Erosion der Grenzen ein strukturelles Infrastrukturproblem ist und kein Versagen der Agentenlogik oder der Governance-Prozesse.

Was passiert ist

Das Kernproblem besteht darin, dass die effektive Macht eines Agenten durch die Tools definiert wird, auf die er zugreifen kann – ein Zugriffsumfang, der sich oft unbemerkt mit der Zeit erweitert. Ein für eine Demo ausgelegtes Credential könnte in die Produktionsumgebung überleben, oder eine Delegation, die hinzugefügt wurde, um einen spezifischen Deployment-Vorgang freizuschalten, wird zu einer dauerhaften Berechtigung. Diese Drift tritt auf, weil Autorität inkrementell und lokal gewährt wird, ohne zentrale Entscheidungsinstanz. Wenn Teams erkennen, dass ein Agent eine nicht autorisierte Aktion ausführen kann, hat er diese Fähigkeit wahrscheinlich schon seit Wochen.

Viele Organisationen versuchen, dies durch Governance-Gremien oder strengere Review-Prozesse zu lösen. Allerdings regeln diese Methoden menschliche Entscheidungen, während das Problem von Fähigkeiten herrührt, die ohne explizite Entscheidung entstehen. Die Autoren behaupten, dass Prozesse allein eine Klasse von Änderungen nicht überprüfen können, die nie als eigenständiges Ereignis auftaucht. Statt auf Wachsamkeit zu setzen, benötigen Systeme eine Grundlage, die Grenzen automatisch durchsetzt, unabhängig davon, ob jemand zuschaut.

Wie es funktioniert

Sich darauf zu verlassen, dass der Agent seine eigenen Grenzen über Anweisungen oder Prompts überwacht, ist strukturell fehlerhaft. Die Ausgabe eines Agenten ist eine Wahrscheinlichkeitsverteilung, was bedeutet, dass er meist die richtige Aktion wählt, aber unter neuartigen oder adversarialen Bedingungen versagen kann. Noch kritischer ist, dass selbst ein perfekt konformer Agent jede Aktion ausführt, die seine Tools erlauben. Wenn ein Agent ein Tool besitzt, das Geld bewegt, kann er Geld bewegen, unabhängig von gegenteiligen Anweisungen. Fähigkeit setzt immer die Absicht außer Kraft, denn Fähigkeit ist das, was tatsächlich ausgeführt wird.

Um dies anzugehen, schlagen die Autoren ein Safe Operating Model vor, das auf konzentrischen Ringen des geringsten Privilegs basiert und den Agenten als Standard-Workload behandelt. Das Zentrum ist Identity (Identität), wobei kurzlebige, attestierte Credentials verwendet werden, damit jeder nachgelagerte Check genau weiß, wer handelt. Der erste Ring, Reach (Reichweite), nutzt ein Service Mesh, um durchzusetzen, mit welchen Diensten ein Agent sich verbinden kann, und verhindert so ein stilles Wachstum des Graphen. Der zweite Ring, Capability (Fähigkeit), trennt Admission (welche Tools ein Agent halten darf) von Execution (was er damit tun kann) und erfordert eine Autorisierung pro Aufruf.

Der Schlüsselstein dieses Modells ist sicherzustellen, dass der Agent seine eigene Konfiguration nicht ändern kann. Einem Agenten muss die Möglichkeit verweigert werden, Richtlinien oder Objekte zu bearbeiten, die seine Autorität definieren. Änderungen an den Grenzen müssen aus versionierter Konfiguration stammen, die von Menschen oder Pipelines verwaltet wird. Dies schafft eine deterministische Struktur für regulierte Workflows, bei denen der Agent Empfehlungen oder Entwürfe liefert, die Plattform jedoch die endgültigen Gates und Genehmigungen durchsetzt.

Wichtige Details

• Das Risiko von Agenten entsteht durch angesammelten Tool-Zugriff, nicht durch absichtliche Designfehler.
• Prompt-basierte Einschränkungen sind probabilistische Vorschläge, keine garantierten Sicherheitsgrenzen.
• Identität muss auf Plattformebene über kurzlebige, attestierte Credentials überprüft werden.
• Reach wird durch Service Meshes durchgesetzt, die Verbindungen zu nicht deklarierten Peers blockieren.
• Capability wird in Admission Control und Autorisierung pro Aufruf am Tool-Gateway aufgeteilt.
• Agenten dürfen niemals die Berechtigung haben, die Konfigurationsobjekte zu ändern, die ihre eigenen Grenzen definieren.

Warum es wichtig ist

Für Software-Ingenieure und technische Leads verlagert dies die Sicherheitslast von der Anwendungsebene auf die Infrastrukturebene. Es bedeutet, dass der Aufbau agentischer Systeme die Integration cloud-nativer Sicherheitsprimitiven wie Workload Identity, Service Meshes und Policy-as-Code erfordert. Teams können Agenten nicht länger als Black Boxes behandeln, die ihre eigene Sicherheit managen; sie müssen die Grenzen, innerhalb derer der Agent operiert, explizit deklarieren und durchsetzen.

Dieser Ansatz ändert auch, wie auditierbare und regulierte Workflows gestaltet werden. Indem die kognitive Arbeit des Agenten von der deterministischen Ausführung der Ergebnisse getrennt wird, können Organisationen Compliance aufrechterhalten. Die Plattform protokolliert Nachweise für Identitäts-, Reichweiten- und Fähigkeitsprüfungen als Nebenprodukt des Betriebs und bietet so eine klare Spur für Regulierungsbehörden. Dies ermöglicht es Agenten, komplexe Interpretationsaufgaben zu übernehmen, während sichergestellt wird, dass kritische Aktionen wie Geldtransfers oder Datenmodifikationen durch unveränderliche, geprüfte Gates laufen.

Was Sie tun können

• Behandeln Sie Agentenidentitäten als erstklassige Workload-Identitäten mit kurzlebigen, attestierten Credentials.
• Implementieren Sie Service-Mesh-Richtlinien, um die Konnektivität von Agenten nur auf deklarierte Peers zu beschränken.
• Verwenden Sie Admission Controller, um zu verhindern, dass Agenten sich an nicht genehmigte Tools binden.
• Erzwingen Sie Autorisierung pro Aufruf am Tool-Gateway, um jede spezifische Aktion zu validieren.
• Stellen Sie sicher, dass Agentenidentitäten explizit die Berechtigung verweigert wird, ihre eigenen Policy-Konfigurationen zu ändern.
• Gestalten Sie Workflows so, dass Agenten Vorschläge oder Entwürfe ausgeben, wobei die finale Ausführung deterministischen Pipelines überlassen bleibt.