Der KI-Sektor erlebt eine breite Debatte über Governance-Mechanismen und die Evaluierung fortschrittlicher Modelle vor deren Veröffentlichung. Diese großen Diskussionen ignorieren jedoch oft den tatsächlichen Programmcode, der darüber entscheidet, ob ein KI-Agent sensible Aktionen ausführen darf, wie etwa das Senden von E-Mails, das Ändern von Verschlüsselungsschlüsseln, das Zusammenführen von Software-Branches oder das Überweisen von Geldern. Diese Entscheidungen werden nicht von großen Laboren oder regulatorischen Texten getroffen, sondern von einfachen Programmfunktionen, die einen Wahrheitswert (wahr oder falsch) zurückgeben.
Stresstests, die an einem Open-Source-Protokoll zur Überprüfung von Agentenaktionen namens "PIC" durchgeführt wurden, zeigten, dass die Probleme nicht unbedingt aus einem Versagen der Verschlüsselung resultieren, sondern daraus, dass das Protokoll mehrere Formate akzeptiert, die zwar oberflächlich korrekt sind, aber unterschiedliche Interpretationen zulassen. Beispielsweise könnte das strukturelle Schema Hash-Werte in Groß- oder Kleinschreibung akzeptieren, während der Interpreter sie auf Arten verarbeitet, die zu unterschiedlichen Ergebnissen zwischen verschiedenen Systemen führen, ohne dabei die erklärten Standardspezifikationen zu verletzen.
Grenzen von JSON-Schemas bei der Datenvalidierung
JSON-Schemas spielen eine grundlegende, aber begrenzte Rolle bei der Überprüfung der Datenstruktur; sie stellen sicher, dass erforderliche Felder vorhanden sind, die Datentypen korrekt sind und sie den allgemeinen Regeln entsprechen. Das Schema ist jedoch nicht in der Lage, komplexe relationale Regeln durchzusetzen, wie etwa die Garantie, dass ein bestimmter Referenzverweis auf ein eindeutiges Element innerhalb eines Quellen-Arrays zeigt, ohne Duplikate oder Mehrdeutigkeiten.
Unterschiede bei der Implementierung von Suchvorgängen oder dem Abgleich von Identifikatoren zwischen verschiedenen Programmiersprachen führen zu sogenannten Parser-Diskrepanzen. Dies ist eine alte Art von Sicherheitslücke, die bereits bei Protokollen wie HTTP und JWT auftrat, bei denen zwei Komponenten dieselben Eingaben auf unterschiedliche Weise lesen. Bei modernen Agentenprotokollen führen diese Nuancen dazu, dass Aktionen in einem bestimmten Dienst akzeptiert werden, während sie von einem anderen Dienst, der dieselbe Richtlinie und Spezifikation verwendet, abgelehnt werden.
Auswirkungen von Normalisierungsprozessen auf die Protokollsicherheit
Entwickler neigen dazu, Eingaben zu normalisieren, um die Ablehnung wiederherstellbarer Daten zu vermeiden, etwa durch das Entfernen überflüssiger Leerzeichen, die Umwandlung in Kleinbuchstaben oder die Korrektur von Base64-Paddings. Diese Praktiken stellen jedoch an den Grenzen der Authentifizierung ein echtes Risiko dar. Wenn der Interpreter beispielsweise den Namen eines Tools normalisiert oder Leerzeichen entfernt, bevor er ihn mit der Whitelist abgleicht, könnte das System eine Aktion ausführen, die von der signierenden Partei nicht genehmigt wurde, oder die Ausführungsberechtigungen ohne Wissen der Entwickler manipulieren.
Darüber hinaus öffnet das Vertrauen auf Felder, die der Agent selbst sendet, um die Zuverlässigkeit seiner Quelle zu bestätigen, Tür und Tor für das Problem des "Confused Deputy" in digitaler Form. Vertrauen sollte ausschließlich innerhalb der Grenzen der Rechtsdurchsetzung und Verifizierung abgeleitet werden, indem digitale Signaturen überprüft und mit kryptografischen Schlüsseln abgeglichen werden, denen der Betreiber direkt vertraut, unabhängig von den Behauptungen in der Anforderungsnutzlast.
Die Drei-Schichten-Architektur und Vektoren für Implementierungsabgleiche
Um diese Lücken zu vermeiden, ist eine Architektur erforderlich, die klar zwischen drei aufeinanderfolgenden Schichten unterscheidet:
- Schema-Validierung: Zur Ablehnung beschädigter Strukturen und Darstellungen, die nicht dem Netzwerk entsprechen.
- Semantische Validierung: Zur Auflösung von Referenzen, Überprüfung von Abhängigkeiten und Ableitung des tatsächlichen Vertrauens.
- Richtlinienbewertung: Zur endgültigen Entscheidung über die Zulassung oder Blockierung der Aktionsausführung.
Dokumentarische Hinweise reichen nicht aus; es bedarf klarer Werkzeuge für den Implementierungsabgleich, die präzise Eingaben, erwartete Ergebnisse und stabile Fehlercodes für den Umgang mit mehrdeutigen Fällen enthalten. Diese Vektoren gewährleisten eine einheitliche Verhaltensweise über alle Implementierungen hinweg und verhindern, dass die Sicherheit von unterschiedlichen Standardkonfigurationen in verschiedenen Software-Brücken abhängt.