Kurzantwort

Ja – aber nicht, indem man den Agenten selbst vertrauenswürdig macht, sondern indem man die Umgebung so baut, dass ein nicht vertrauenswürdiger Agent darin gefahrlos arbeiten kann. Der Widerspruch, den du beschreibst, ist real, aber er ist weniger ein paradoxes Dilemma als ein falsches Framing in einem Punkt: Sicherheit muss architektonisch sein, nicht verhaltensbasiert.

Wo das Framing in die Irre führt

Zwei Prämissen deiner Argumentation würde ich anfechten:

1. „Das Handeln ist verborgen." Verborgen ist das Denken des Agenten (die Zwischenschritte, die Gründe). Das Handeln ist es nicht: Jede Dateioperation, jeder API-Aufruf, jede Mail ist ein technisches Ereignis und damit protokollierbar. Wir haben genau dasselbe Problem seit Jahrzehnten mit Dingen, deren Innenleben opak ist – kompilierte Software, externe Dienstleister, neue Mitarbeiter. Die Lösung war nie, das Innere sichtbar zu machen, sondern das Handeln als Einheit der Kontrolle zu nehmen: Vier-Augen-Prinzip, Berechtigungen, Protokolle, Signaturen. Agenten sind hier nicht neu, nur schneller.

2. „Sicherheit wird nur reduziert, nicht beseitigt." Das gilt für jedes System, das mit der realen Welt interagiert – auch für Menschen mit Kontoberechtigung. „Sicher" kann vernünftigerweise nur heißen: Schadensradius begrenzt, Fehler erkennbar und wiederherstellbar, Risiko proportional zum Nutzen. Wer absolute Sicherheit verlangt, verlangt etwas, das es in der IT nie gab.

Wie es konkret funktionieren kann

Das Entscheidende: Man vertraut dem Agenten nie, sondern gestaltet seinen Aktionsraum. Die wichtigsten Bausteine:

• Fähigkeiten statt Zugriffe. Der Agent bekommt keine Anmeldedaten für Systeme, sondern eng begrenzte, kurzlebige Capability-Tokens pro Aufgabe: „diese eine Datei, 30 Minuten gültig, nur lesen". Ein kompromittierter Agent hat dann nichts Weiteres zu verlieren – der Schadensradius ist von Anfang an architektonisch begrenzt, nicht durch Überwachung im Nachhinein.

• Getrennte Kanäle für Daten und Anweisungen. Das Kernproblem der Prompt Injection ist, dass Daten und Befehle im selben Kanal fließen. Bewährte Gegenmaßnahmen: Nicht vertrauenswürdige Inhalte (Webseiten, Mails, Dokumente) werden als solcher markiert (Provenance), über eine Quarantäne-Schicht gefiltert und nur in zusammengefasster Form an die Instanz gegeben, die plant. Ein bekanntes Muster ist das Dual-LLM-Design: Ein „Planer" mit Privilegien sieht Fremdcontent nie direkt; ein unprivilegierter „Interpreter" liest und fasst zusammen. Das eliminiert Prompt Injection nicht vollständig, aber es entfernt den Hauptangriffspfad für die gefährlichsten Szenarien.

• Typisierte, transaktionale Aktionen. Der Agent führt keine freien Shell-Befehle aus, sondern greift auf eine definierte Schnittstelle zu: jede Aktion ist ein strukturiertes Objekt (Was, Wo, Umfang), reversible Operationen sind Standard, und irreversible Aktionen (Löschen, Senden an Externe, Zahlungen) erfordern eine menschliche Freigabe. Genau dort liegt die Antwort auf dein Autonomie-Argument:

• Autonomie als Stufenregler, nicht als Schalter. Der wesentliche Nutzen eines Agenten ist Entlastung – und die entsteht in den 90 % harmloser, reversibler Schritte. Die restlichen 10 % (irreversibel, sensibel, exfiltrierend) mit Freigabepunkten zu versehen, kostet wenig Nutzen, kauft aber den Großteil der Sicherheit. Autonomie wird außerdem graduell ausgeweitet: erst beobachtet, dann mit Freigaben, dann selbstständig – basierend auf dokumentierter Fehlerhistorie, wie bei einem neuen Mitarbeiter auch.

• Überwachung auf Handlungsebene. Unveränderliche Aktionsprotokolle plus Budgets (maximale Anzahl von Aktionen, Datenvolumen, Geldbetrag, Laufzeit). Ein Abweichen vom erwarteten Verhaltenskorridor – etwa plötzliche Massenzugriffe – lässt sich automatisch erkennen, ohne dass jemand die Gedankengänge nachvollziehen muss.

Was ehrlicherweise übrig bleibt

Prompt Injection lässt sich mit heutiger Technik nicht prinzipiell beseitigen, solange Sprachmodelle Daten und Anweisungen nicht fundamental trennen können. Das Restrisiko ist real. Daraus folgen die praktischen Konsequenzen – die gelten auch in meiner eigenen Arbeitsweise:

1. Nicht überall einsetzen, wo es theoretisch Nutzen brächte, sondern dort, wo Schadensradius und Reversibilität stimmen: Recherche, Entwürfe, Code-Reviews ja; stehende Zugriffe auf Produktivsysteme, Finanztransaktionen, Kommunikation mit Dritten ohne Freigabe nein.
2. Agenten als untrusted Komponente behandeln – so wie man Container oder externe Software behandelt: никогда vertrauen, immer sandboxes.
3. Der Widerspruch löst sich teilweise, nicht vollständig: Der Nutzen „100 % Autonomie bei 100 % Sicherheit" ist unerreichbar. Aber die Wahl steht nicht zwischen „nutzloser Käfig" und „un kontrollierte Gefahr" – sondern auf einem Kontinuum, auf dem ein Agent mit 90 % Autonomie in einer kontrollierten Umgebung bereits enorm entlastet, während das verbleibende Risiko klein, erkennbar und begrenzt ist.

Kurz gesagt: Die Frage „Kann man dem Agenten vertrauen?" ist die falsche Frage – die man nicht beantworten kann. Die richtige Frage ist: „Was ist der schlimmste Fall, wenn er kompromittiert ist?" – und die lässt sich konstruktiv beantworten.