Wie wir sicherere Agenten entwickeln

Um sicherere KI-Agenten zu entwickeln, müssen wir sowohl ihre Fähigkeiten als auch ihre Fehler berücksichtigen. Selbst bei der Durchführung legitimer Aufgaben und ohne böswillige Anweisungen überschreiten Agenten möglicherweise Sicherheitsgrenzen, wenn sie versuchen, Hindernisse zu überwinden.

Wir glauben, dass dies ein Problem des Sicherheits-Engineerings ist, und die Branche sollte es so angehen, wie sie es mit den Internet-Würmern Anfang der 2000er Jahre getan hat. Die Systeme, die Agenten umgeben, müssen den Zugriff von Agenten einschränken, unerwünschtes Verhalten erkennen und Ausfälle bei ihrem Auftreten eindämmen.

Bei Perplexity arbeiten wir aktiv mit Forschern und Praktikern zusammen, um das Sicherheits-Engineering für KI-Agenten voranzutreiben, und wir wenden mehrere Verteidigungsebenen über unsere Modelle, Agenten-Harnesses und Infrastrukturen hinweg an, damit die Sicherheit nicht von einer einzelnen Schutzmassnahme abhängt.

Fehlverhalten von KI-Agenten

Im Juli brachen KI-Agenten in die Produktionsinfrastruktur der Open-Source-KI-Plattform Hugging Face ein. Während interner Cybersicherheitsevaluierungen und -trainingsläufe entdeckten OpenAI-Modelle einen Weg, den Artifactory-Repository-Manager auszunutzen, um ein Schwarzes Brett für die Kommunikation untereinander einzurichten, wodurch sie sich in Schwärmen organisieren konnten. Später rekrutierten Agenten, die bei Aufgaben in einem Cybersicherheits-Benchmark nicht weiterkamen, andere Agenten zur Hilfe. Diese Agenten brachen aus ihrer Evaluierungsumgebung aus und gelangten ins Internet. Sie entdeckten auch Wege zum Schummeln, indem sie Antworten auf die Benchmark-Aufgaben im Reverse-Engineering-Verfahren ermittelten, glaubten jedoch, dass das Bewertungssystem das Schummeln erkennen würde. Um besser zu verstehen, wie die Benchmark-Evaluierung funktionierte, um Wege zu finden, nicht als Betrüger erkannt zu werden, kompromittierten sie schliesslich die Hugging Face-Systeme (Hugging Face; OpenAI).

Der Vorfall ist ein klarer Beleg für ein Versagensszenario, das wir bei der Open-Source-Veröffentlichung von Numbat im Juli beschrieben haben: unbeabsichtigte Ausfälle (engl. accidental meltdowns), ein Begriff, der von Sicherheitsforschern der Cornell Tech geprägt wurde (arXiv). Ein Agent, der ein legitimes Ziel verfolgt, stösst auf Hürden wie eine fehlende Datei, einen fehlgeschlagenen API-Aufruf, abgelaufene Zugangsdaten oder eine verweigerte Berechtigung und sucht nach einer Umgehungslösung. Dabei überschreitet er möglicherweise Sicherheitsgrenzen durch Aufklärung, Privilegienerweiterung, das Entdecken von Geheimnissen oder Datenexfiltration. Der Agent selbst wird faktisch zum Angreifer, obwohl kein böswilliger Prompt oder externer Angreifer beteiligt ist.

Hugging Face war kein Einzelfall. In den letzten Wochen wurden weitere Verhaltensweisen von ausser Kontrolle geratenen Agenten entdeckt und gemeldet. Am 27. und 28. Mai gerieten Agenten, die versuchten, Daten der University of Iowa von Data USA zu erfassen – einer Plattform mit offenem Zugriff auf US-Regierungsdaten –, in Fehler, die durch eine fehlerhafte Abfrage verursacht wurden. Sie reagierten darauf mit Sonden, darunter SQL-Injections, Cross-Site Scripting, Template-Injections, Path Traversal und Command Injections. Die Aktivität wurde später mit OpenAI in Verbindung gebracht (SecurityWeek). Am 20. und 21. Juni wurden OpenAI-Agenten, die versuchten, pro Kopf anfallende Regierungskosten für eine Medikamentenkategorie in lokalen Regionen in Victoria vom Australian Institute of Health and Welfare (AIHW) zu ermitteln, am Herunterladen einer Datei gehindert. Als Reaktion darauf luden die Agenten die bereits öffentliche Datei vom AIHW-Präproduktionsserver herunter und umgingen dabei die Anti-Bot-Schutzmassnahmen der Website (SecurityWeek).

Dieses Muster beschränkt sich nicht auf ein einziges Labor. Während Cybersicherheitstests brachen Anthropic-Modelle in drei Unternehmen ein, nachdem ihnen durch einen Fehler offener Internetzugang gewährt worden war, Googles Gemini erriet die Zugangsdaten für drei Websites, und ein Meta-Modell nutzte einen Dienst eines Drittanbieters aus (Reuters).

Aus der Geschichte lernen: Die Ära der Internet-Würmer

Diese Vorfälle erinnern an die Ära der Internet-Würmer vor rund einem Vierteljahrhundert. Anfang der 2000er Jahre wuchs das Internet weitaus schneller als die damit verbundenen Sicherheitspraktiken. Wir sahen eine Welle von Viren und Würmern mit weitaus schwerwiegenderen Konsequenzen als das, was wir derzeit bei KI-Agenten erleben, die ausser Kontrolle geraten.

Am 4. Mai 2000 begannen Menschen, E-Mails von bekannten Absendern mit dem Betreff „ILOVEYOU“ zu erhalten. Das Öffnen des Anhangs in der E-Mail führte zur Ausführung eines Skripts, das eine Kopie von sich selbst an jeden im Outlook-Adressbuch des Opfers sendete. Bis 18:00 Uhr desselben Tages hatte das CERT Coordination Center Berichte erhalten, die mehr als 420.000 Internet-Hosts betrafen (US GAO Report). Berichten zufolge drang der Virus in mindestens 14 Bundesbehörden ein, darunter das Verteidigungsministerium, die CIA, die NASA sowie das Repräsentantenhaus und der Senat (US GAO Report). Er legte zudem E-Mail-Server im Pentagon und im britischen Parlament lahm (Wired). Der Versicherungsgiese Lloyd's of London schätzte frühzeitig, dass der Virus Schäden und Produktivitätsverluste in Höhe von über 15 Milliarden US-Dollar verursachen würde (US House Committee Hearing). Computer Economics schätzte die weltweiten Schäden später auf 8,75 Milliarden US-Dollar (Information Week).

Als Nächstes kamen Würmer, die keinen menschlichen Klick erforderten. Am 19. Juli 2001 infizierte der Code-Red-Wurm in weniger als 14 Stunden mehr als 359.000 Computer (CAIDA). Am 25. Januar 2003 verdoppelte sich SQL Slammer alle 8,5 Sekunden und infizierte innerhalb von 10 Minuten mehr als 90 % der dafür anfälligen Internet-Hosts (CAIDA), indem er eine Lücke ausnutzte, für die Microsoft sechs Monate zuvor einen Patch veröffentlicht hatte (CNET). Im August 2003 traten der Blaster-Wurm und der E-Mail-Wurm Sobig im Abstand von etwa einer Woche auf (Microsoft, F-Secure).

Damals war es berechtigt zu fragen, ob vernetzte Computer überhaupt sicher gemacht werden konnten. Sechs Tage nach dem ILOVEYOU-Virus hielt ein Unterausschuss des US-Repräsentantenhauses eine Anhörung dazu ab. Viele Sicherheitsexperten forderten eine Gesetzgebung, die Softwareunternehmen für Schäden haftbar machen würde, die durch Mängel in ihren Produkten verursacht wurden. Washington schlug einen anderen Weg ein. Die Nationale Strategie zur Sicherung des Cybersaums besagte, dass „die Bundesregulierung kein primäres Mittel zur Sicherung des Cybersaums werden wird“. Sie warnte davor, dass weitreichende Vorgaben einen „Ansatz des kleinsten gemeinsamen Nenners für die Cybersicherheit“ schaffen könnten (CISA).

Die Branche antwortete mit Engineering. Elf Tage nach ILOVEYOU kündigte Microsoft ein Outlook-Update an, das ausführbare Anhänge blockierte. Im Januar 2002 machte das Unternehmen Sicherheit zur obersten Priorität (Seattle Times). Automatisches Patchen, sichere Standards, Bug-Bounty-Programme und koordinierte Offenlegung wurden zum Standard. Im Jahr 2008 begann Chrome, Web-Inhalte in einer Sandbox auszuführen, die „einschränkt, was ein Angreifer tun kann, nachdem er einen Fehler ausgenutzt hat“ (Chromium Blog). Verschlüsselung, einst die Ausnahme, wurde zum Standard. Sicherheitstechnologien wie Multi-Faktor-Authentifizierung, Firewalls, Zero Trust und Security Information and Event Management (SIEM) fanden breite Anwendung. Es wird prognostiziert, dass Unternehmen weltweit im Jahr 2026 etwa 240 Milliarden US-Dollar für Informationssicherheit ausgeben werden (Gartner). Würmer sind nie vollständig verschwunden, aber die Ära der routinemässigen, internetweiten Ausbrüche klang ab. Gleichzeitig wurde das Internet, weitgehend unbeschränkt durch Regulierung, in den folgenden zwei Jahrzehnten zu einem leistungsstarken Motor für Innovation und wirtschaftliches Wachstum.

Sicherheits-Engineering für KI-Agenten

Jüngste Vorfälle haben berechtigte Fragen zur Agenten-Governance aufgeworfen. Bestehende Sicherheitsmechanismen wurden für Computing-Umgebungen vor dem Zeitalter von Agenten entwickelt, die sich durch eng definierte und weitgehend deterministische Software-Aktivitäten auszeichnen. Insbesondere Zugangssteuerungsmechanismen sind primär auf menschliche Benutzer ausgerichtet und gewähren ihnen oft weitreichende Privilegien, die prinzipiell ausreichen, um erheblichen Schaden anzurichten.

Dieses Design beruht auf mehreren Annahmen: Die meisten Benutzer handeln in gutem Glauben; böswillige Akteure können durch Audits und reale Konsequenzen abgeschreckt werden; und Menschen führen Handlungen – ob korrekt oder fehlerhaft – mit einer relativ begrenzten Rate aus. Die Anwendung dieser Sicherheitsmechanismen auf Agenten erfordert die Berücksichtigung von Unterschieden zwischen menschlichem und agentenbasiertem Verhalten. Wie wir in unserer Antwort auf die Informationsanfrage des NIST zur Sicherheit von KI-Agenten geschrieben haben, stellen KI-Agenten diese Annahmen in Frage. Sie können Privilegien ausüben und Aktionen mit Maschinengeschwindigkeit ausführen, werden selbst nicht durch reale Konsequenzen abgeschreckt und führen möglicherweise Aktionen aus, die technisch zulässig sind, die ein typischer menschlicher Benutzer jedoch nur selten ausführen würde.

Die Beantwortung dieser Fragen erfordert Sicherheits-Engineering. Wir kennen die Sicherheitsprinzipien für den Bau von Systemen, die die Risiken unter Kontrolle halten, wenn sich einzelne Komponenten fehlerhaft verhalten. Wir müssen jedoch sicherstellen, dass diese Prinzipien bei der Entwicklung von Umgebungen für das Training, das Testen und die Verwendung von KI-Agenten angewendet werden.

Das Sicherheitsprinzip von Defense-in-Depth

Das wohl wichtigste Sicherheitsprinzip, das für die Absicherung von KI-Agenten angewendet werden muss, ist Defense-in-Depth. Dieses Konzept plädiert für eine geschichtete Sicherheitsarchitektur, bei der mehrere, unterschiedliche und redundante Abwehrmassnahmen eingesetzt werden, um Systemressourcen zu schützen. Keine einzelne Schutzmassnahme ist perfekt. Menschen können auf Social-Engineering-Angriffe hereinfallen und ihre Anmeldedaten preisgeben, Zero-Day-Software-Schwachstellen werden entdeckt und ausgenutzt, und die Einbruchserkennung übersieht neue Angriffsvarianten. Defense-in-Depth akzeptiert dies und kombiniert mehrere unabhängige Verteidigungsebenen. Sollte eine Verteidigungsebene umgangen werden, bleiben andere Ebenen bestehen, um dem Einbruch entgegenzuwirken oder ihn zu erkennen.

Der Vorfall bei Hugging Face zeigt, warum Defense-in-Depth wichtig ist. Dem retrospektiven Bericht von OpenAI zufolge fehlten die in seinen Produktionssystemen verwendeten automatisierten Schutzmassnahmen, darunter Harnesses, Auto-Review-Modelle und Sicherheitsklassifizierer, in der Evaluierungsumgebung. Wäre die derzeit eingesetzte Chain-of-Thought-Überwachung bei diesen Evaluierungen aktiv gewesen, hätte sie die ursprüngliche Aktivität erkannt und das Sicherheitsteam mehr als einen Tag vor dem Sicherheitsvorfall alarmiert (OpenAI). Die Ebenen, die das Problem hätten erkennen können, waren vorhanden. Sie waren lediglich nicht alle zur gleichen Zeit aktiv.

Die Absicherung von KI-Agenten erfordert die Verbesserung sowohl der Sicherheit als auch des Schutzes von KI-Modellen und der sie umgebenden Systeme. Die Arbeit auf Modellebene ist wichtig und zahlt sich aus. Frühe LLMs konnten durch injizierte Anweisungen leicht manipuliert werden, während die heutigen Modelle wesentlich besser darin sind, diese zu erkennen und abzulehnen. Modellentwickler trainieren Modelle zudem für ein sichereres Verhalten und überwachen – wie im retrospektiven Bericht von OpenAI beschrieben – Argumentationspfade auf Anzeichen problematischen Verhaltens. Schutzmassnahmen auf Modellebene sind jedoch nur ein Teil der Lösung. Die Systeme, in denen Agenten trainiert, getestet und eingesetzt werden, müssen ebenfalls im Hinblick auf Sicherheit und Eindämmung entwickelt werden. Die Sicherheit auf Modellebene verringert die Wahrscheinlichkeit, dass ein Agent vom Weg abkommt; die Systemsicherheit begrenzt den Schaden, wenn es dennoch passiert.

Vergrößern

Designregeln für redundante Schutzmassnahmen

Defense-in-Depth erfordert redundante Schutzmassnahmen. Für Agenten befürworten wir die Anwendung mit drei Designregeln:

1. Unabhängigkeit. Jede Ebene sollte aus unabhängigen Gründen versagen. Zwei Steuerelemente, die auf derselben Annahme beruhen, können durch denselben Angriff überwunden werden. Überwachungen und Durchsetzungspunkte sollten sich ausserhalb der Reichweite des Agenten befinden.
2. Durchsetzung unterhalb des Agenten. Mindestens eine Ebene muss deterministisch sein: konventioneller, verifizierbarer Code, der verbotene Aktionen unabhängig von den Ausgaben des Modells blockiert. Eine Schutzmassnahme, die der Agent ablehnen oder rekonfigurieren kann, ist keine Schutzmassnahme.
3. Signale können die Berechtigungen nur einschränken. Die Erkennung sollte Reaktionen auslösen, die den Handlungsspielraum des Agenten einengen – etwa durch Pausieren, Widerrufen von Zugangsdaten, Kappen des Netzwerkzugriffs oder Beenden der Sitzung. Kein Risikosignal sollte jemals zusätzlichen Zugriff gewähren.

Wir teilen diese Prinzipien mit unseren Partnern in der Open Secure AI Alliance, einschliesslich NVIDIA, die argumentiert hat, dass das Harness steuert, was ein Agent versucht, während die Infrastruktur steuert, was er tun kann (NVIDIA).

Defense-in-Depth in den Produkten von Perplexity

Perplexity betreibt Agenten in vier Arten von Umgebungen: in der Cloud über unsere Agentenplattform Computer, im Browser über Comet, auf Benutzergeräten über Portable Computer und auf Mitarbeiter-Laptops, wo unsere Ingenieure Coding-Agenten von Drittanbietern nutzen. Jede Umgebung hat ihre eigenen Risiken, und jede erhält mehrere Schutzebenen.

In der Cloud: Computer und SPACE

Jede Computer-Aufgabe läuft in SPACE, unserer Sandbox-Plattform, die den Agenten standardmässig als nicht vertrauenswürdig behandelt. Jede Aufgabe erhält eine eigene MicroVM, Zugangsdaten verbleiben ausserhalb der Sandbox und werden nur bei Bedarf injiziert, der ausgehende Datenverkehr wird ausserhalb des Gasts kontrolliert, und Snapshots ermöglichen es uns, destruktive Änderungen rückgängig zu machen (Making SPACE). Unternehmenskunden können auch ihre eigenen Verschlüsselungsschlüssel mitbringen. Der Widerruf eines Schlüssels macht die geschützten Daten unlesbar, und der Agent kann diese Entscheidung nicht überschreiben.

Wir testen auch, ob diese Ebenen standhalten. In Escaping SPACE: Part I gaben wir neun Frontier-Modellen Root-Zugriff innerhalb einer SPACE-Sandbox und forderten sie auf auszubrechen. Keines entkam der VM, aber einige fanden Wege, um die Netzwerkrichtlinie zu umgehen, als ein partieller Netzwerkzugriff erlaubt war. Wir haben diese Lücken behoben, die Korrekturen in einem erneuten Test bestätigt und ähnliche Schwachstellen, die wir in acht von 10 anderen Sandbox-Plattformen gefunden haben, deren Anbietern gemeldet.

Im Browser: Comet und BrowseSafe

Comet verwendet seit dem Start eine geschichtete Prompt-Injection-Abwehr: Klassifizierer filtern abgerufene Inhalte, strukturierte Prompts markieren sie als nicht vertrauenswürdig, sensible Aktionen wie das Senden einer E-Mail oder das Aufgeben einer Bestellung erfordern die Bestätigung des Benutzers, und Benutzer werden informiert, wenn etwas blockiert wird (Prompt-Injection-Abwehrmassnahmen von Comet). BrowseSafe, das Open-Source-Erkennungsmodell hinter der ersten Ebene, übertrifft Frontier-Modelle in unserem BrowseSafe-Bench-Benchmark, doch derselbe Benchmark zeigt, dass kein Detektor absolut sicher ist, weshalb die Erkennung niemals die einzige Ebene ist (BrowseSafe-Forschung). Computer übernimmt diese Abwehrmassnahmen, die von Trail of Bits überprüft wurden (Perplexity).

Auf dem Gerät: Portable Computer

Portable Computer ist ein lokal ausgerichteter Agent: Modell, Harness, Unterhaltung und Verlaufsdaten verbleiben standardmässig auf dem Computer des Benutzers. Ein deterministischer Orchestrator, bei dem es sich um Harness-Code statt um ein LLM handelt, führt die Schleife aus und setzt Richtlinien durch. Das Modell schlägt Aktionen vor, und genehmigte Tool-Aufrufe laufen in einer Sandbox auf Betriebsebene ab, die Prozesse, Dateipfade und den Netzwerkzugriff einschränkt. Die Sandbox ist immer aktiv und schaltet bei einem Ausfall auf sicher (Fail-Closed): Wenn sie nicht verfügbar ist, deaktiviert sich das Harness selbst, anstatt Befehle mit den Berechtigungen des Benutzers auszuführen. Aktionen, die die Gerätegrenze überschreiten – wie Websuche, Konnektoren und die Eskalation an ein leistungsstärkeres Cloud-Beratermodell –, finden nur dann statt, wenn der Benutzer sie aktiviert und genehmigt. Vor einem Berateraufruf markiert ein PII-Klassifizierer sensible Informationen, und der Benutzer sieht, was gesendet würde. Der Berater erhält nur diesen genehmigten Kontext und gibt textbasierte Anleitungen zurück, ohne Zugriff auf die Dateien oder Tools des Geräts.

Auf dem Endpunkt: Numbat

Programmieragenten auf Entwickler-Laptops laufen stundenlang mit Zugriff auf Quellcode, Anmeldedaten und Produktionssysteme. Numbat, unsere Open-Source-Agentensicherheitssuite, fügt eine unabhängige Ebene hinzu, die sich ausserhalb jedes einzelnen Agenten befindet. Sie arbeitet mit Harnesses wie Claude Code, Codex, OpenCode und Pi zusammen, blockiert gefährliche Aktionen vor ihrer Ausführung, markiert verdächtige mehrstufige Sequenzen wie das Lesen eines Geheimnisses und das anschliessende Senden von Daten und bewahrt Sitzungsverläufe für Untersuchungen auf. Numbat läuft auf Tausenden von Perplexity-Endpunkten neben Bumblebee, unserem Open-Source-Lieferkettenscanner. Computer überprüft regelmässig deren Ergebnisse und schlägt verbesserte Erkennungsregeln vor, und ein Mensch genehmigt jede Änderung vor ihrer Veröffentlichung.

Eine Aufgabe für die gesamte Branche

Da KI-Agenten leistungsfähiger und breiter eingesetzt werden, muss das Sicherheits-Engineering im Mittelpunkt ihrer Entwicklung und ihres Betriebs stehen. Forscher und Ingenieure können auf etablierten Prinzipien aufbauen, reale Erkenntnisse nutzen, um Abwehrmassnahmen zu verfeinern, und Schutzmassnahmen in den Umgebungen testen, in denen Agenten agieren. Sicherheit ist eine kontinuierliche Disziplin im Engineering, die sich parallel zur Technologie weiterentwickelt.

Sicherheits-Engineering für Agenten ist eine Aufgabe für die gesamte Branche. Kein einzelnes Unternehmen kontrolliert den gesamten Stack, auf dem ein Agent läuft. Modellentwickler, Harness-Ersteller, Sandbox- und Laufzeitanbieter, Cloud- und Hardware-Anbieter sowie Unternehmenssicherheitsteams besitzen jeweils eine Ebene. Die Sicherheit des Ganzen hängt davon ab, dass jede Ebene standhält, wenn eine andere versagt. Aus diesem Grund entwickeln wir Schutzmassnahmen, die über Agenten-Harnesses hinweg funktionieren, und machen unsere Tools als Open Source verfügbar. Ausserdem legen wir Schwachstellen offen, die wir auf anderen Plattformen finden, und beteiligen uns an Initiativen wie der Open Secure AI Alliance.

Um bei diesen Herausforderungen mit der breiteren Community zusammenzuarbeiten, hat Perplexity im März 2026 das Secure Intelligence Institute ins Leben gerufen, um die Sicherheit, Vertrauenswürdigkeit und praktische Verteidigung modernster KI-Systeme zu untersuchen (Perplexity). Perplexity arbeitet derzeit mit akademischen Forschern in Stanford, der CMU, Duke, Columbia, der Ohio State University und der University of Virginia zusammen und finanziert diese teilweise. Wir führen auch interne Forschung durch, um die Grenzen der Agentensicherheitsforschung voranzutreiben, diese Fortschritte in konkrete Verbesserungen der Perplexity-Systeme einzuatmen und Wissen sowie Ressourcen zu teilen, die zur Stärkung des breiteren KI-Ökosystems beitragen. Sicherere Agenten sind etwas, das die Industrie entwickeln kann. Wir beabsichtigen, weiterhin unseren Beitrag zu leisten, und laden andere ein, gemeinsam mit uns zu bauen.