Wie gibt ein geheimer Broker einem KI-Agenten Zugangsdaten, ohne sie in Prompts offenzulegen?

Ein geheimer Broker hält Zugangsdaten aus Prompts heraus, indem er die Workload des Agenten authentifiziert und eine auf den erforderlichen Umfang begrenzte Autorisierung erst an der Grenze zur externen Anfrage injiziert.

Ein KI-Agent für zu Hause muss möglicherweise einen Kalender lesen oder ein Backup hochladen. Werden API-Schlüssel jedoch in seinem Prompt, Speicher, seiner Umgebung oder Tool-Ausgabe abgelegt, können sie durch Injection zugänglich werden. Ein Broker überprüft die Identität der Workload und den genehmigten Aufgabenkontext, beschafft ein kurzlebiges Zugangstoken, fügt es innerhalb eines kontrollierten Proxys oder Tool-Adapters ein und gibt nur das Ergebnis des Dienstes zurück.

Workload-Identität ersetzt den Besitz eines statischen Schlüssels

Der Agent weist nach, welcher genehmigte Prozess, Container, Service-Account oder welche signierte Workload die Anfrage stellt. Der Broker ordnet diese Identität Richtlinien zu, anstatt einem Bearer-Schlüssel zu vertrauen, der dort gespeichert ist, wo ihn generierter Code oder der Modellkontext lesen kann.

Eine Analyse von Workload-Identität für Agenten erläutert Attestierung und Machine-to-Machine-Authentifizierung für Agenten, die keine dauerhaften Zugangsdaten besitzen sollten. Der Identitätsnachweis ermöglicht es, die Autorisierung von der Laufzeit-Workload statt von Behauptungen im Gespräch abhängig zu machen. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.

Die Identität allein gewährt keinen Zugriff auf jeden Dienst. Die Richtlinie bindet die Workload weiterhin an Benutzer, Ziel, Vorgang, Ressourcenbereich und Zeitfenster. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung darauf reagiert.

Der Broker stellt ein begrenztes, kurzlebiges Zugangstoken aus oder injiziert es

Nach der Richtlinienfreigabe tauscht der Broker die Identität gegen ein Token mit begrenztem Umfang oder ruft ein Geheimnis in geschütztem Speicher ab. Ein Proxy fügt den Autorisierungs-Header der ausgehenden Anfrage hinzu, nachdem die vom Modell generierten Parameter validiert wurden.

Sicherheitsempfehlungen für kurzlebige, broker-gestützte Zugangsdaten empfehlen, mit keinen Zugangsdaten zu beginnen und einen Broker zu verwenden, der kurzlebige Token für die jeweilige Aufgabe bereitstellt. Dadurch werden sowohl die Dauer der Offenlegung als auch die nach einer Kompromittierung verfügbaren Vorgänge begrenzt. Diese Grenze sollte unter realistischen Betriebsbedingungen separat gemessen werden.

Das Modell sieht ein Tool-Schema und eine bereinigte Antwort, nicht das Token. Auch Protokolle, Fehler, Traces, Befehlszeilen und Wiederholungen müssen Autorisierungsmaterial schwärzen, sonst verschiebt die Architektur das Leck lediglich. Die praktische Konsequenz zeigt sich, wenn mehrere Quellen um begrenzten Kontext konkurrieren.

Richtlinie und Widerruf begrenzen den Missbrauch von Zugangsdaten

Ziellisten, Methodenbeschränkungen, Ressourcenkennungen, Benutzerfreigaben, Ratenbegrenzungen, Audience-Claims, Ablaufzeiten und Einmal-Token begrenzen, wie die injizierte Berechtigung verwendet werden kann. Der Broker kann die zukünftige Ausstellung widerrufen, ohne Prompts oder Images neu erstellen zu müssen.

Eine Erläuterung zur Grenze der Zugangsdaten-Injection argumentiert, dass jedes Geheimnis, das in das Kontextfenster gelangt, offengelegt werden kann, und verlagert die Verwaltung der Zugangsdaten außerhalb des Agenten. Das Muster verringert das Risiko einer Offenlegung und bewahrt zugleich kontrollierte authentifizierte Aufrufe. Diese Abhängigkeit sollte in der endgültigen Schnittstelle ausdrücklich sichtbar bleiben.

Die Fehlergrenze ist eine zu weit gefasste Broker-Richtlinie oder ein Proxy, der beliebige vom Agenten ausgewählte Anfragen signiert. Verborgene Zugangsdaten hindern einen durch Prompt-Injection manipulierten Agenten nicht daran, legitime Berechtigungen zu missbrauchen. Daher müssen Anfragesemantik und Seiteneffekte weiterhin validiert werden.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verfolge ein Zugangstoken von der Identität bis zum Ablauf

Dokumentiere für jedes Agenten-Tool die Workload-Identität, den anfragenden Benutzer, das Ziel, den erlaubten Vorgang, den Ressourcenbereich, den Freigabestatus, die Token-Audience, die Gültigkeitsdauer, den Injektionspunkt, die Bereinigung der Antwort, die Audit-Kennung, den Widerrufspfad und das Fallback-Verhalten. Das Ergebnis muss daher mit den ursprünglichen Belegen abgeglichen werden.

Vergleiche die Kontrolle mit den Berechtigungen für Agenten-Tools. Teste Prompt-Anfragen nach Geheimnissen, Umgebungs-Dumps, umgeleiteten Zielen, Wiederholungen nach Ablauf, erweiterten Ressourcenkennungen, Fehlerprotokollierung, Tool-Wiederholungen und einen kompromittierten Sandbox-Prozess. Dieser Unterschied bleibt bei späteren Tests im Haushalt sichtbar.

Bestanden ist der Test nur, wenn unverschlüsselte Zugangsdaten niemals in für das Modell sichtbare Daten gelangen und nicht autorisierte Varianten von Anfragen am Broker oder Proxy fehlschlagen. Halte Token kurzlebig, Richtlinien aufgabenspezifisch und Protokolle bereinigt. Nicht umkehrbare Vorgänge müssen hinter einer unabhängig gebundenen Freigabe liegen. Das Zwischenergebnis muss überprüfbar bleiben, bevor die Automatisierung darauf reagiert.