Ich halte den Widerspruch für real, aber nicht für total. Er löst sich nicht auf, lässt sich aber ziemlich weit entschärfen, wenn man ein paar Annahmen verschiebt.

Wo du recht hast

Prompt Injection ist kein Bug, den man einfach patcht. Sie folgt daraus, dass ein Sprachmodell Anweisungen und Daten im selben Kanal verarbeitet. Es gibt bislang keine Methode, die zuverlässig garantiert, dass ein Modell eingebettete Anweisungen in Inhalten ignoriert. Training, Klassifikatoren und Filter senken die Erfolgsquote von Angriffen, aber ein adaptiver Angreifer findet oft trotzdem einen Weg. Wer sich auf "das Modell merkt es schon" verlässt, hat keine Sicherheitsgarantie, sondern eine Wahrscheinlichkeit.

Wo ich den Widerspruch anders einordne

Der Denkfehler liegt meiner Meinung nach in der Gleichsetzung von Autonomie mit Rechten. Entscheidend ist nicht, wie selbstständig ein Agent arbeitet, sondern welchen Schaden eine manipulierte Aktion maximal anrichten kann. Das lässt sich architektonisch begrenzen, ohne den Agenten ständig zu überwachen. Die wichtigsten Ansätze:

1. Die "tödliche Trias" aufbrechen. Gefährlich wird es vor allem, wenn ein Agent gleichzeitig (a) Zugriff auf private Daten hat, (b) nicht vertrauenswürdige Inhalte liest und (c) nach außen kommunizieren oder handeln kann. Fehlt eines der drei, ist der klassische Datenabfluss stark erschwert. Ein Agent, der das offene Web liest, aber keine privaten Daten sieht und nichts versenden kann, ist weitgehend harmlos. Ein Agent mit E-Mail-Zugriff, der nur intern arbeitet und nichts nach draußen schicken kann, ebenfalls.

2. Trennung von Rollen (Dual-LLM- bzw. Plan-then-Execute-Muster). Ein Modell mit Werkzeugrechten sieht nie unvertrauenswürdigen Text direkt. Ein zweites, rechteloses Modell verarbeitet die fremden Inhalte und gibt nur streng strukturierte Ergebnisse zurück (etwa ein Feld "Rechnungsbetrag: Zahl"). Ansätze wie CaMeL von Google DeepMind gehen noch weiter: Kontroll- und Datenfluss werden getrennt, und eine klassische Programmlogik erzwingt, dass nicht vertrauenswürdige Daten nie bestimmen, welche Aktion ausgeführt wird. Das bietet echte, nicht nur statistische Garantien, kostet aber Flexibilität.

3. Deterministische Kontrollen außerhalb des Modells. Sicherheit darf nicht im Prompt stehen, sondern in der Infrastruktur: Sandboxing, Egress-Filter (nur freigegebene Domains), kurzlebige und eng gefasste Tokens, Ausgabelimits, Schreibzugriffe nur auf definierte Ordner. Das Modell kann dann manipuliert werden, aber der Rahmen hält trotzdem.

4. Abgestufte Autonomie statt Alles-oder-nichts. Reversible, risikoarme Aktionen (lesen, entwerfen, in einer Sandbox rechnen) laufen vollautomatisch. Irreversible oder folgenreiche Aktionen (Geld überweisen, Mails extern versenden, Daten löschen) brauchen eine Freigabe. Das ist kein Verlust der Autonomie, sondern eine Verlagerung der Aufsicht auf wenige, gut verständliche Entscheidungspunkte statt auf jeden Zwischenschritt.

5. Beobachtbarkeit als Voraussetzung. Dein Punkt zur Überwachung ist berechtigt, aber lösbar, wenn man Überwachung nicht als "Mitlesen in Echtzeit" versteht. Vollständige, manipulationssichere Protokolle aller Aktionen, Diffs statt Rohlogs, automatische Anomalieerkennung und die Möglichkeit, Aktionen zurückzurollen, ermöglichen eine nachträgliche Kontrolle. Das ist wie bei menschlichen Mitarbeitern mit Prokura: Man schaut nicht jedem über die Schulter, aber Buchführung und Vier-Augen-Prinzip existieren.

Was bleibt: Restrisiko

Auch mit all dem bleibt ein Restrisiko, und es lässt sich nicht auf null bringen. Die ehrliche Antwort lautet also: Es gibt keinen "sicheren" Agenten im Sinne einer Garantie, aber es gibt vertretbare Einsatzszenarien, in denen der Worst Case begrenzt und akzeptabel ist. Das ist in der Sicherheitstechnik übrigens der Normalfall. Auch menschliche Mitarbeiter lassen sich täuschen (Phishing, Social Engineering), und wir lösen das ebenfalls durch Rechtebegrenzung, Prozesse und Kontrolle, nicht durch Unfehlbarkeit.

Praktische Konsequenzen

• Den Nutzen anders rechnen. Wenn die Frage lautet "Wie viel Autonomie gebe ich?", ist sie falsch gestellt. Besser: "Welche Aufgaben haben einen begrenzten Schadensradius, und was ist bei den anderen der Preis der Absicherung?" Viele Aufgaben (Recherche, Zusammenfassungen, Code in der Sandbox, Entwürfe) sind schon heute mit gutem Nutzen und überschaubarem Risiko machbar.
• Hochrisikokombinationen meiden. Ein Agent mit Zugriff auf Postfach, Dateien und offenes Web plus Versandrechten ist nach heutigem Stand schlicht nicht verantwortbar, egal wie gut das Modell ist.
• Nicht jede Aufgabe eignet sich. Bei sehr offenen, weitreichenden Aufgaben mit hohen Rechten ist die Autonomie derzeit tatsächlich nicht sicher zu haben. Das ist eine unbequeme, aber ehrliche Grenze, und die Werbeversprechen vom "digitalen Mitarbeiter, der alles erledigt" überdehnen den heutigen Stand.
• Anbieter in die Pflicht nehmen. Transparenz über Zwischenschritte, sinnvolle Standardeinstellungen und eingebaute Schutzmechanismen sollten Produktmerkmale sein, nicht Nutzerpflichten.

Mein Fazit

Der Widerspruch besteht, wenn man Autonomie mit unbegrenzten Rechten und totaler Unüberwachtheit gleichsetzt. Dann gilt: entweder nützlich oder sicher, nicht beides. Wenn man Autonomie als selbstständiges Abarbeiten innerhalb eines technisch erzwungenen Rahmens versteht, gibt es einen Weg, der allerdings kleiner ausfällt als das Marketing verspricht. Der Gewinn liegt weniger in "der Agent macht alles" als in "der Agent macht viel, und seine Fehler und Manipulationen bleiben begrenzt, sichtbar und umkehrbar". Das ist weniger spektakulär, aber ein tragfähiger Weg.

Wenn du magst, kann ich das an einem konkreten Szenario durchspielen, etwa einem E-Mail-Agenten oder einem Coding-Agenten, und zeigen, wo genau man die Grenzen ziehen würde.