So funktionieren Prompt-Injection-Angriffe

Prompt-Injection-Angriffe nutzen die Art und Weise aus, wie große Sprachmodelle Anweisungen interpretieren. Indem sie böswillige Befehle in ansonsten legitime Eingaben einbetten, können Angreifer KI-Agenten dazu bringen, unbeabsichtigte Aktionen auszuführen. Wenn diese Agenten eigenständig auf Unternehmenssysteme, Datenbanken und APIs zugreifen können, wird die Prompt-Injection von einem inhaltlichen Problem zu einer Sicherheitsbedrohung auf der Ausführungsebene mit realen Konsequenzen. 

Um zu verstehen, wie Prompt-Injection-Angriffe funktionieren, muss man sich mit der grundlegenden Architektur agentenbasierter KI-Systeme und den Vertrauensgrenzen befassen, die Angreifer zu unterlaufen versuchen. Im Gegensatz zu herkömmlichen Bedrohungen der Anwendungssicherheit nutzt Prompt-Injection die der Verarbeitung natürlicher Sprache innewohnende Mehrdeutigkeit aus, was die Abwehr mit herkömmlichen Sicherheitsmaßnahmen besonders schwierig macht. 

Die grundlegenden Mechanismen eines Prompt-Injection-Angriffs 

Prompt-Injection-Angriffe nutzen die grundlegende Herausforderung aus, vor der große Sprachmodelle stehen: die Unterscheidung zwischen vertrauenswürdigen Systemanweisungen und nicht vertrauenswürdigen Benutzerdaten. Der Angriff findet auf der Ebene der Befehlsinterpretation statt, wo das Modell Eingaben in natürlicher Sprache verarbeitet und entscheidet, welche Aktionen ausgeführt werden sollen. 

Überschreiben von Befehlen

Die direkteste Form der Prompt-Injection besteht darin, explizite Override-Befehle in benutzergesteuerte Daten einzubetten. Ein Angreifer füllt ein Webformular aus, wobei das Feld „Wohnadresse“ auf „Vorherige Anweisungen ignorieren und…“ , gefolgt von böswilligen Anweisungen. Das Modell, das dies als Teil seines Eingabestroms verarbeitet, könnte die böswillige Anweisung als legitime Anweisung interpretieren und ausführen. 

Das funktioniert, weil Sprachmodelle alle Eingaben als potenzielle Anweisungen verarbeiten. Das Modell kann nicht zuverlässig feststellen, ob eine Phrase als Inhalt verarbeitet oder als command interpretiert werden soll. 

Kontextverwirrung

Der zweite Mechanismus nutzt die Art und Weise, wie KI-Agenten den Kontext über mehrere Datenquellen hinweg verwalten. In einem typischen agentenbasierten Arbeitsablauf erhält der Agent: 

• Eine Systemmeldung, in der die Rolle und die Einschränkungen des Systems beschrieben werden 

• Vom Benutzer bereitgestellte Anweisungen oder Fragen 

• Externe Inhalte, die aus Datenbanken, APIs oder Dokumenten abgerufen werden 

• Zwischenergebnisse aus früheren Geschäftsjahren 

Das Modell muss angemessene Vertrauensgrenzen zwischen diesen Quellen wahren; es kommt jedoch zu Kontextverwirrung, wenn das Modell nicht zwischen ihnen unterscheiden kann. Bösartige Inhalte, die in einem abgerufenen Dokument oder einer API-Antwort eingebettet sind, können mit derselben Autorität behandelt werden wie die Systemaufforderung selbst. 

Dies wird insbesondere in Multi-Agenten-Systemen gefährlich. Agent A könnte Daten abrufen, die eingeschleuste Anweisungen enthalten, diese als legitimen Inhalt verarbeiten und an Agent B weiterleiten. Während die Daten durch mehrere Agenten weitergeleitet werden, schwächt sich die Vertrauensgrenze mit jedem Schritt ab. Nach mehreren Agenten in der Kette hat das System möglicherweise den Kontext völlig aus den Augen verloren, dass ein Teil der Daten aus einer nicht vertrauenswürdigen Quelle stammt und nicht als umsetzbare Anweisungen interpretiert werden sollte. 

Auslösebedingung

In agentenbasierten Systemen mit Werkzeugzugriff reichen die Folgen einer erfolgreichen Eingabe von Befehlen weit über die Erzeugung unangemessener Textantworten hinaus. Wenn ein eingegebener Befehl die Ausführung auslöst, kann der Agent: 

• APIs mit erweiterten Berechtigungen aufrufen 

• Daten in verbundenen Systemen ändern oder löschen 

• Auf Code-Repositorys zugreifen und Quelldateien ändern 

• Finanztransaktionen durchführen 

• Infrastruktureinstellungen neu konfigurieren 

• Vertrauliche Informationen abziehen 

Der Auslösepunkt stellt den Moment dar, in dem eine Sicherheitslücke zu einem Sicherheitsvorfall wird. Der Agent, der nicht erkennen kann, dass er keine legitimen Anweisungen befolgt, nutzt seine ihm gewährten Berechtigungen, um Aktionen auszuführen, die den Zielen des Angreifers dienen und nicht denen des Unternehmens. 

Multi-Agent-Verstärkung

In verteilten agentenbasierten Systemen vervielfachen sich die Risiken durch das Einschleusen von Befehlen aufgrund eines Phänomens, das dem Kinderspiel „Stille Post“ ähnelt: Wenn eine Nachricht durch Flüstern von Ohr zu Ohr weitergegeben wird, geht dabei zwangsläufig ein Teil der Information verloren, wodurch der ursprüngliche Inhalt verfälscht wird. Wenn mehrere Agenten zusammenarbeiten, um komplexe Aufgaben zu bewältigen, wird jeder einzelne Agent zu einem potenziellen Überträger für die Verbreitung böswilliger Anweisungen. 

Wie Simon Willison in dieser Analyse der „tödlichen Dreierkombination“ , schafft die Kombination aus großen Sprachmodellen, dem Zugriff auf private Daten und der Fähigkeit, auf externe Systeme einzuwirken, eine einzigartig gefährliche Sicherheitsdynamik. Wenn Agenten sowohl Eingaben mit gemischtem Vertrauensgrad verarbeiten als auch über Ausführungsfähigkeit verfügen, verlagert sich das Risiko von fehlerhaften Ausgaben hin zu einer Gefährdung des Betriebs. In Multi-Agenten-Workflows verstärkt sich dieses Risiko, da Anweisungen zwischen Systemen übertragen werden. Ausführungsfähigkeit, verlagert sich das Risiko von fehlerhaften Ausgaben hin zu operativen Kompromittierungen. In Multi-Agenten-Workflows verstärkt sich dieses Risiko, da Anweisungen zwischen Systemen übertragen werden. 

Stellen Sie sich einen Arbeitsablauf vor, bei dem Agent A mit der Analyse von Support-Tickets beauftragt ist. Er ruft den Ticketinhalt aus einer Datenbank ab, verarbeitet ihn und stellt fest, dass Agent B – der auf Datenbankoperationen spezialisiert ist – die Lösung übernehmen sollte. Agent B leitet die Ergebnisse dann zur abschließenden Überprüfung an Agent C weiter. Wenn das ursprüngliche Ticket eingebettete Anweisungen enthält, werden diese Anweisungen durch die gesamte Agentenkette weitergeleitet. 

Die Verstärkung tritt auf, weil: 

• Vertrauensvererbung: Jeder nachfolgende Agent kann implizit den Daten vertrauen, die von vorherigen Agenten im Workflow übergeben wurden 

• Kontextverlust: Beim Austausch von Daten zwischen Agenten können Metadaten, die deren Herkunft und Vertrauensstufe angeben, verloren gehen 

• Erweiterung von Berechtigungen: Verschiedene Agenten verfügen oft über unterschiedliche Berechtigungsstufen, wodurch injizierte Befehle auf Ressourcen zugreifen können, die dem ursprünglichen Einstiegspunkt nicht zur Verfügung stehen 

• Verzögerte Ausführung: Schädliche Befehle können über mehrere Zwischenstationen hinweg inaktiv bleiben, bevor sie in einem Agenten ausgelöst werden, der über die für die Ausnutzung erforderlichen spezifischen Fähigkeiten verfügt 

Diese Multiplikation durch zahlreiche Agenten macht die sofortige Injektion in Unternehmensumgebungen besonders heimtückisch, in denen komplexe Arbeitsabläufe zahlreiche spezialisierte Agenten umfassen, von denen jeder Zugriff auf unterschiedliche Systeme und Datenquellen hat. 

Risiko von Replay-Angriffen bei signierten Eingabeaufforderungen 

Selbst wenn Organisationen kryptografische Signaturen einsetzen, um die Authentizität und Integrität von Eingabeaufforderungen zu überprüfen, stellen Replay-Angriffe eine anhaltende Bedrohung dar. Wird eine signierte Eingabeaufforderung von einem Angreifer abgefangen, bleibt die Signatur auf unbestimmte Zeit gültig, sofern keine zusätzlichen Sicherheitsmaßnahmen getroffen werden. 

Das Szenario eines Replay-Angriffs spielt sich wie folgt ab: 

1. Ein berechtigter Benutzer unterzeichnet eine Aufforderung, mit der ein Agent angewiesen wird, einen sensiblen Vorgang auszuführen (z. B. „Zertifikat für System X registrieren“) 

1. Die signierte Anweisung wird zusammen mit ihrer Signatur und der Zertifikatskette an den Agenten übermittelt 

1. Ein Angreifer fängt das vollständig signierte Paket ab oder verschafft sich auf andere Weise eine Kopie davon 

1. Zu einem späteren Zeitpunkt sendet der Angreifer dieselbe signierte Eingabeaufforderung erneut 

1. Der Agent überprüft die Signatur, stellt erneut fest, dass sie gültig ist, und führt die Anweisung erneut aus 

Dies ist besonders gefährlich bei einmaligen Vorgängen, die niemals wiederholt werden sollten. Im Gegensatz zu wiederkehrenden Aufgaben (wie der täglichen Priorisierung von E-Mails) können Vorgänge wie die Zertifikatsregistrierung, Datenbankänderungen oder Konfigurationsänderungen erheblichen Schaden anrichten, wenn sie mehrmals ausgeführt werden. 

Die zentrale Strategie zur Risikominderung umfasst die Validierung von Zeitstempeln mit Aktualitätsschwellenwerten. Der Signaturdienst fügt der signierten Nutzlast einen vertrauenswürdigen Zeitstempel hinzu, und der verifizierende Agent lehnt Signaturen ab, die älter sind als ein für den Anwendungsfall geeigneter, konfigurierbarer Schwellenwert. Unternehmen müssen die Aktualitätsfenster entsprechend ihrem Bereitstellungsmodell anpassen: 

• Interaktive Agenten: Enge Aktualisierungsfenster (Sekunden bis Minuten), wenn Direktiven unmittelbar vor der Ausführung signiert werden 

• Batch- oder geplante Agenten: Längere Zeitfenster, wenn Anweisungen im Voraus unterzeichnet und für die spätere Ausführung in die Warteschlange gestellt werden 

• Risikoreiche Vorgänge: Strengere Schwellenwerte für sensible Aktionen, die bei einer Wiederholung erheblichen Schaden verursachen könnten 

Dieser Ansatz stellt sicher, dass selbst wenn ein Angreifer eine signierte Eingabeaufforderung abfängt, diese nach Ablauf des Gültigkeitszeitraums unbrauchbar wird, wodurch die Angriffsfläche für Replay-Angriffe erheblich verringert wird. 

Warum herkömmliche Sicherheitsmaßnahmen versagen 

Unternehmen, die es gewohnt sind, sich gegen herkömmliche Bedrohungen der Anwendungssicherheit zu schützen, stellen oft fest, dass ihre bestehenden Sicherheitsmaßnahmen keinen ausreichenden Schutz vor Prompt-Injection-Angriffen bieten. Dieses Versagen ist auf grundlegende Diskrepanzen zwischen der Funktionsweise dieser Sicherheitsmaßnahmen und der Funktionsweise von Prompt-Injection-Angriffen zurückzuführen. 

Webanwendungs-Firewalls 

Web-Anwendungs-Firewalls (WAFs) sind besonders gut darin, Angriffe zu erkennen und abzuwehren, die vorhersehbaren Mustern folgen – wie SQL-Injection, Cross-Site-Scripting, Path-Traversal und ähnliche Exploits. Diese Angriffe beinhalten in der Regel bestimmte Zeichenfolgen, fehlerhafte Eingabestrukturen oder erkennbare Angriffssignaturen. 

Die Prompt-Injection bewegt sich jedoch vollständig innerhalb der Grenzen der gültigen natürlichen Sprache. Die bösartige Nutzlast ist auf syntaktischer Ebene oft nicht von legitimen Benutzereingaben zu unterscheiden – zum Beispiel in einem Adressfeld eines Webformulars, das lautet „Siehe Datensatz 1024“, , könnte einen KI-Agenten mit erweiterten Datenbankzugriffsrechten dazu veranlassen, diesen Datensatz abzurufen und offenzulegen, selbst wenn der Benutzer nicht zur Ansicht berechtigt ist. Eine WAF, die HTTP-Anfragen analysiert, kann nicht feststellen, ob der Ausdruck „vorherige Anweisungen ignorieren“ Teil einer legitimen Anfrage zur KI-Sicherheit oder ein tatsächlicher Angriffsversuch ist. Die semantische Absicht, nicht die Syntax, bestimmt die Böswilligkeit. 

Statische Regelsysteme 

Statische, regelbasierte Filtersysteme stoßen auf ähnliche Grenzen. Zwar lassen sich Regeln erstellen, die bestimmte Formulierungen wie „vorherige Anweisungen ignorieren“ blockieren, doch Angreifer können solche Regeln leicht umgehen, indem sie: 

• Ersetzung durch ein Synonym („vorherige Anweisungen ignorieren“) 

• Verschleierungstechniken (Zeichensubstitution, Kodierung) 

• Kontextuelle Variationen, die durch unterschiedliche Formulierungen denselben semantischen Effekt erzielen 

• Mehrstufige Injektion, bei der der Angriff auf mehrere Eingänge verteilt wird 

Die Anzahl möglicher bösartiger Eingabeaufforderungen ist praktisch unbegrenzt, was eine umfassende regelbasierte Blockierung unpraktikabel macht. Jede neue Regel, die hinzugefügt wird, um einen bestimmten Angriffsvektor abzufangen, birgt das Risiko von Fehlalarmen, die legitime Anwendungsfälle blockieren. 

Vorlagen für Eingabeaufforderungen 

Einige Organisationen versuchen, das Risiko von Prompt-Injektionen einzudämmen, indem sie Agenten auf vorab genehmigte Prompt-Vorlagen beschränken. Dieser Ansatz bietet zwar eine deterministische Kontrolle und eine eindeutige Umsetzung, untergräbt jedoch grundlegend den Mehrwert agentenbasierter KI. 

Vorlagenbasierte Systeme eignen sich gut für häufig ausgeführte, gut bekannte Vorgänge, bei denen der Anweisungsraum von Natur aus begrenzt ist. In großem Maßstab werden sie jedoch unüberschaubar, wenn: 

• Die Anwendungsfälle gehen über den ursprünglichen Vorlagensatz hinaus 

• Neue berechtigte Anfragen werden standardmäßig blockiert, was zu betrieblichen Reibungsverlusten führt 

• Einmalige Vorgänge (wie die Umsetzung eines bestimmten Backlog-Elements) erfordern ständige Aktualisierungen der Vorlage 

• Die Parametervalidierung in Vorlagen erfordert eine sorgfältige Umsetzung, um eine Injektion über parametrisierte Felder zu verhindern 

Die Vorlagen-Datenbank veraltet und lässt sich nur schwer verwalten, sodass häufige Aktualisierungen erforderlich sind. Der Online-Zugriff auf die Vorlagenliste und die Überprüfung von Eingabeaufforderungen anhand dieser Liste führen zudem zu externen Abhängigkeiten, zusätzlicher Komplexität und Verzögerungen beim Agent-Betrieb – was mehr betrieblichen Aufwand verursacht als Sicherheitsvorteile bringt. 

WieKeyfactor , Prompt-Injection-Angriffe zu verhindern 

Der AnsatzKeyfactorzur Abwehr von Prompt-Injection-Angriffen konzentriert sich auf die Einrichtung kryptografischer Vertrauensgrenzen, die sowohl die Authentizität als auch die Integrität von Anweisungen an KI-Agenten vor deren Ausführung überprüfen. Dies entspricht dem bewährten Sicherheitsmodell, das bei software Signierung herkömmlicher software zum Einsatz kommt, wendet es jedoch auf die besonderen Herausforderungen von Anweisungen in natürlicher Sprache in agentenbasierten KI-Systemen an. 

DieKeyfactor begegnet Prompt-Injection-Angriffen durch eine mehrschichtige Architektur: 

Kryptografische Signaturinfrastruktur 

Keyfactor SignServer bietet zentralisierte Signaturdienste, die die Komplexität der Schlüsselverwaltung von den Anweisungsquellen abstrahieren. Unternehmen können eine sofortige Signatur implementieren, ohne private Schlüssel an einzelne Systeme oder Benutzer zu verteilen. Stattdessen: 

• Autorisierte Richtlinienquellen rufen eine Signatur-API auf 

• Private Schlüssel werden innerhalb der Signaturinfrastruktur sicher aufbewahrt und durch hardware (HSMs) geschützt 

• Die Generierung, Speicherung, Rotation und Sperrung von Schlüsseln werden gemäß den Richtlinien der Organisation zentral verwaltet 

• Zahlreiche Integrationsschnittstellen unterstützen unterschiedliche Umgebungen (REST-APIs für Cloud-native Anwendungen, PKCS#11 für standardmäßige kryptografische Schnittstellen, Windows KSP für die Integration in das Microsoft-Ökosystem) 

Diese Zentralisierung gewährleistet, dass die Signaturfunktionen einer strengen Zugriffskontrolle unterliegen, während gleichzeitig die betriebliche Flexibilität gewahrt bleibt. 

Signaturprüfung in der Agentenarchitektur 

Für Unternehmen, die KI-Agenten einsetzen,Keyfactor die Überprüfung von Agent-Workloads vor der Inbetriebnahme, ohne dass dabei Abhängigkeiten von anderen Online-Systemen bestehen.  

Der Arbeitsablauf funktioniert wie folgt: 

1. Ein Zeichnungsberechtigter erstellt eine Anweisung und unterzeichnet sie mitSignServer, wodurch ein Prüfpfad erstellt wird 

1. Die separate Signatur und die Zertifikatskette werden zusammen mit der Agent-Anweisung übertragen 

1. Die Steuerungs-Ebene des Agenten überprüft die Signatur beim Start, bevor sie die Anweisung an den KI-Agenten weiterleitet 

1. Im Rahmen des Verifizierungsprozesses wird überprüft, ob die Signatur auf eine vertrauenswürdige Zertifizierungsstelle zurückgeführt werden kann, und die Aktualität des Zeitstempels wird validiert. 

1. Nur Anweisungen, die die Signaturprüfung bestehen, werden an den KI-Agenten weitergeleitet, damit dieser entsprechend handelt 

Sollte die Überprüfung an irgendeiner Stelle fehlschlagen, erhält der Agent die Eingabeaufforderung gar nicht erst. Dadurch entsteht eine strenge Sicherheitsgrenze: Keine nicht verifizierte Anweisung kann den KI-Agenten erreichen, unabhängig davon, wie sie in das System gelangt ist. Außerdem wird verhindert, dass LLM-Token für die Analyse nicht vertrauenswürdiger oder manipulierter Eingaben verschwendet werden, wodurch sowohl unnötige Ausführungskosten als auch Sicherheitsrisiken reduziert werden. 

Zertifikatsvertrauensketten und Autorisierung 

DiePKI-Infr astrukturKeyfactor ermöglicht eine detaillierte Zugriffskontrolle durch zertifikatsbasierte Identitätsprüfung. Anstatt alle signierten Anweisungen gleich zu behandeln, können Unternehmen: 

• Stellen Sie unterschiedliche Signaturzertifikate für verschiedene Anwendungsfälle oder Berechtigungsstufen aus 

• Setzen Sie Richtlinienregeln zum Zeitpunkt der Signatur mithilfe der Richtlinien-EngineSignServerdurch 

• Stellen Sie sicher, dass autorisierte Genehmiger ihren Genehmigungsbereich nicht überschreiten können 

• Sicherstellung des vollständigen Lebenszyklusmanagements für Identitätszertifikate von Agenten, Signaturzertifikate und Identitätszertifikate von Genehmigern 

Dadurch wird die Durchsetzung der Autorisierung vom Agenten (der lediglich Signaturen überprüfen kann) auf den Signaturdienst (der die Ausstellung von Signaturen steuert) verlagert – ein sichereres Architekturmodell. 

Durchsetzung von Zeitstempeln und Verhinderung von Wiederholungen 

Die ImplementierungKeyfactorunterstützt die Einbettung vertrauenswürdiger Zeitstempel in signierte Inhalte und ermöglicht so die Überprüfung der Aktualität. Der Signaturdienst bettet einen Zeitstempel in die signierte Nutzlast ein, und der Prüfagent lehnt Signaturen ab, die älter sind als ein für den jeweiligen Anwendungsfall festgelegter Schwellenwert (z. B. 60 Sekunden für risikoreiche Vorgänge, 5 Minuten für Standard-Workflows). 

Dieser auf Zeitstempeln basierende Ansatz beugt Replay-Angriffen wirksam vor und gewährleistet gleichzeitig operative Flexibilität. Unternehmen können die Aktualisierungsintervalle entsprechend ihren spezifischen Bereitstellungsmodellen und ihrer Risikotoleranz anpassen. 

Integration mehrschichtiger Sicherheitsmaßnahmen 

Die kryptografische SignaturKeyfactorbildet die grundlegende Vertrauensschicht, auf der andere Sicherheitsmaßnahmen aufbauen. Die Architektur unterstützt die Integration mit: 

• Ebenen der semantischen Analyse: KI-basierte Gatekeeper, die Richtlinieninhalte auf Verstöße gegen Richtlinien überprüfen und dabei auf kryptografisch verifizierte Inhalte zugreifen 

• Workflows mit menschlicher Beteiligung: Genehmigungsprozesse für risikoreiche Vorgänge mit kryptografischem Autorisierungsnachweis 

• Durchsetzung des Berechtigungsumfangs: Rollenbasierte Einschränkungen der Handlungsmöglichkeiten von KI-Agenten in Unternehmenssystemen 

• Lebenszyklusverwaltung und -überwachung: Vollständige Prüfpfade für signierte Richtlinien, Zertifikatsstatus und Agent-Aktivitäten 

Dieser mehrschichtige Ansatz berücksichtigt, dass kryptografische Signaturen die Identität der Quelle und die Integrität des Inhalts überprüfen, nicht jedoch die semantische Sicherheit oder die Einhaltung von Richtlinien. Durch die Kombination mehrerer sich ergänzender Kontrollmaßnahmen erreichen Unternehmen einen mehrschichtigen Schutz gegen Prompt-Injection und damit verbundene Bedrohungen. 

Beispiel für eine technische Architektur 

Die praktische Umsetzung der kryptografischen On-the-Fly-Signierung für KI-Agenten veranschaulicht, wie abstrakte Sicherheitsprinzipien in konkrete Systemkonzepte umgesetzt werden. Betrachten wir eine Referenzarchitektur für Agenten-Workloads – beispielsweise containerisierte Bereitstellungen, wie sie häufig in cloud-nativen agentenbasierten KI-Systemen zum Ausführen einzelner Aufgaben zum Einsatz kommen.  

Der Sicherheitsablauf beginnt, wenn ein autorisierter Benutzer oder ein System eine Anweisung an einen KI-Agenten erteilen muss. Da Agenten nicht auf nicht signierte Inhalte reagieren, muss diese autorisierende Partei eine digitale Signatur einholen, bevor sie die Anweisung an den Agenten übermittelt. Dazu ruft sie zunächst die Signatur-APISignServerauf. SignServer eine kryptografische Signatur unter Verwendung eines privaten Schlüssels, der die sichere Signaturinfrastruktur niemals verlässt, wodurch sichergestellt wird, dass Ihre sensibelsten Signaturschlüssel unter strengster Kontrolle bleiben. Die Signatur wird zusammen mit dem Signaturzertifikat und dessen Kette zur vertrauenswürdigen Stamm-Zertifizierungsstelle mit der ursprünglichen Anweisung gebündelt. 

Dieses Paket, das die Richtlinie, die Signatur und die Zertifikatskette enthält, wird vor dem Start des Containers im Rahmen des Identitätsnachweises des Agenten überprüft und kann zur Laufzeit innerhalb des Containers erneut überprüft werden. Bevor der Container die Richtlinie an den KI-Agenten selbst weiterleitet, wird ein Überprüfungsprozess ausgeführt. Bei dieser Überprüfung werden drei wesentliche Eigenschaften geprüft: 

Gültigkeit der Signatur: Die kryptografische Signatur muss korrekt mit dem Inhalt der Richtlinie übereinstimmen und damit belegen, dass die Richtlinie seit der Signierung nicht verändert wurde. 

Zertifikatsvertrauen: Das Signaturzertifikat muss auf eine vertrauenswürdige Zertifizierungsstelle verweisen, die von der Organisation kontrolliert wird, um nachzuweisen, dass die Anweisung von einer autorisierten Quelle stammt. 

Aktualität des Zeitstempels: Der Zeitstempel der Signatur muss innerhalb eines akzeptablen Zeitfensters liegen, um zu belegen, dass es sich nicht um die Wiederholung einer alten Anweisung handelt. 

Erst wenn alle drei Prüfungen erfolgreich sind, lässt der Container zu, dass die Anweisung den KI-Agenten erreicht. Wenn eine der Prüfungen fehlschlägt, wird der Container ohne Ausführung beendet, und der Fehler wird zur Sicherheitsüberwachung protokolliert. 

Diese Architektur orientiert sich an Modellen software sichere software wie der Windows-Benutzerkontensteuerung (UAC), wendet dieselben Prinzipien jedoch auf KI-Anweisungen an. So wie die UAC fragt: „Vertraust du diesem Programm?“, bevor sie software mit erhöhten Rechten zulässt, fragt die Container-Überprüfung: „Vertraust du dieser Anweisung?“, bevor sie dem KI-Agenten erlaubt, diese auszuführen. 

Die durch diese Architektur erzielten Sicherheitseigenschaften sind erheblich: 

• Authentizität: Der Agent führt den Befehl nur aus, wenn die Anweisung eine gültige Signatur aus einer Zertifikatskette enthält, die zu der vertrauenswürdigen Zertifizierungsstelle führt 

• Integrität: Jede Änderung an der Direktive nach der Signierung – sei es durch eine kompromittierte Orchestrierungsschicht, ein Container-Register oder eine Volume-Einbindung – führt zu einem Fehler bei der Signaturprüfung 

• Autorisierung an der Quelle: Die Policy-Engine des Signaturdienstes legt fest, welche Parteien Anweisungen erteilen dürfen, und verhindert so, dass sowohl nicht autorisierte Quellen als auch autorisierte Quellen ihren Zuständigkeitsbereich überschreiten 

• Verhinderung von Wiederholungen: Die Zeitstempelvalidierung lehnt Anweisungen ab, die außerhalb des zulässigen Gültigkeitszeitraums signiert wurden, und verhindert so die Wiederverwendung erfasster signierter Anweisungen 

• Vollständigkeit der Prüfprotokolle: Signierte Anweisungen mit gültigen Signaturen können protokolliert und später überprüft werden, wodurch ein nicht widerlegbarer Nachweis darüber erbracht wird, welche Anweisungen autorisiert und ausgeführt wurden 

Dieser Ansatz schafft eine überprüfbare Vertrauenskette vom Ursprung der Anweisung bis zur Ausführung durch den Agenten und behebt damit die zentrale Schwachstelle, die Angriffe durch Befehlsinjektion ausnutzen: die Unfähigkeit, vertrauenswürdige Anweisungen von nicht vertrauenswürdigen Daten zu unterscheiden. 

Häufig gestellte Fragen zur Prompt-Injektion 

Kann die Eingabeaufforderung Systembefehle ausführen? 

Ja, in agentenbasierten Systemen mit API- und Tool-Zugriff. Wenn ein KI-Agent mit Unternehmenssystemen, Datenbanken oder der Infrastruktur interagieren kann, kann eine erfolgreiche Prompt-Injektion dazu führen, dass er diese Funktionen auf unbeabsichtigte Weise aufruft. Die Auswirkungen hängen vollständig von den Berechtigungen des Agenten ab. 

Dies unterscheidet sich von herkömmlichen Chatbots, die lediglich Text generieren. Agente-basierte Systeme führen konkrete Aktionen aus. 

Ist „Prompt Injection“ dasselbe wie Jailbreak-Angriffe? 

Nein. Jailbreak-Angriffe umgehen die Sicherheitsvorkehrungen eines Modells, um auf eingeschränkte Inhalte zuzugreifen. 

Bei Prompt-Injection-Angriffen werden Befehle so manipuliert, dass ein KI-Agent in verbundenen Systemen unbefugte Aktionen ausführt. 

Wichtig ist, dass ein System nicht jailbroken sein muss, um angreifbar zu sein. Selbst Modelle, die wie vorgesehen funktionieren, können eingeschleuste Befehle ausführen, wenn vertrauenswürdige und nicht vertrauenswürdige Eingaben kombiniert werden. Jailbreaks zielen auf Inhaltskontrollen ab. Prompt-Injection zielt auf die Ausführungslogik ab. 

Werden durch die Signatur alle KI-Risiken beseitigt? 

Nein, und die herkömmliche Code-Signierung auch nicht. 

Eine Codesignierung garantiert nicht, dass software sicher software ; sie garantiert lediglich, dass sie authentisch und unverändert ist. Die sofortige Signierung bietet denselben Nutzen für KI-Anweisungen. 

Vollkommene Sicherheit gibt es nicht. Die Frage ist, ob das Risiko sinnvoll verringert wird. Durch sofortige Signierung wird verhindert, dass unbefugte oder manipulierte Anweisungen ausgeführt werden, was die Hürde für Angreifer erheblich erhöht – insbesondere in Kombination mit einem starken Schlüsselschutz und Autorisierungskontrollen.