Turnkey führt Managed Secrets für den Zugriff von KI-Agenten auf Zugangsdaten ein

Turnkey hat Managed Secrets eingeführt und erweitert damit seine auf Enklaven basierende Wallet-Infrastruktur um API-Schlüssel, Passwörter, Zahlungsdaten und Wiederherstellungsinformationen, die Anwendungen und KI-Agenten für ihren Betrieb benötigen. Mit der Ankündigung vom 29. Oktober wendet sich das Unternehmen über die Verwaltung privater Schlüssel hinaus einem umfassenderen Problem zu: Software soll handlungsfähig sein, ohne dass wiederverwendbare Zugangsdaten über die gesamte Infrastruktur verstreut werden.

Mit dem Produkt können Teams festlegen, welcher Dienst Zugangsdaten abrufen darf und ob dafür eine Genehmigung durch einen Menschen oder mehrere Parteien erforderlich ist. Bei Finanzanwendungen könnte das bedeuten, einem autorisierten Handels-Backend einen API-Schlüssel für eine Kryptobörse bereitzustellen und ihn zugleich aus der Unterhaltung und der Ausführungsumgebung eines KI-Assistenten herauszuhalten.

Zugriff auf Zugangsdaten hinter die Grenze einer Enklave verlagern

In Umgebungsvariablen oder Konfigurationsdateien gespeicherte Zugangsdaten lassen sich von Software bequem verwenden. Wird jedoch der Prozess kompromittiert, der sie ausliest, können ihre Inhalte offengelegt werden. Ein Tresor kann Speicherung und Zugriffskontrollen zentralisieren. Die entscheidende Frage bleibt, an welcher Stelle Zugangsdaten lesbar werden und welchen Systemen man in diesem Moment vertrauen muss.

Managed Secrets führt die Autorisierungsprüfungen innerhalb der sicheren Enklaven von Turnkey durch. Ein Client verschlüsselt ein Geheimnis vor dem Import; anschließend verschlüsselt die Enklave es für die Speicherung erneut. Geht eine Anfrage ein, prüft die Enklave die geltenden Richtlinien und Genehmigungen, bevor sie das Ergebnis mit dem Schlüssel des vorgesehenen Empfängers verschlüsselt. Anfragender und Empfänger können unterschiedliche Dienste sein.

Diese Trennung ist wichtig. Eine Anwendung kann einen Vorgang anstoßen und Genehmigungen einholen, ohne dadurch selbst in die Lage versetzt zu werden, die für dessen Ausführung benötigten Zugangsdaten zu entschlüsseln. Die Signatur einer genehmigenden Person autorisiert die Freigabe; sie gewährt nicht automatisch Zugriff auf das freigegebene Geheimnis.

Die Kryptografie hinter Import und Export

Die Dokumentation zum sicheren Kanal von Turnkey beschreibt ein Protokoll auf Basis der hybriden Verschlüsselung mit öffentlichem Schlüssel (Hybrid Public Key Encryption, HPKE). Es kombiniert einen Schlüsselaustausch mit öffentlichen Schlüsseln und authentifizierte Verschlüsselung, damit sensible Daten verschlüsselt durch zwischengeschaltete Systeme übertragen werden können. Beim Import überprüft der Client das von der Enklave signierte Schlüsselmaterial; beim Export wird mit einem öffentlichen Schlüssel verschlüsselt, der in der signierten Anfrage angegeben ist.

Empfängerschlüssel sind für den einmaligen Gebrauch vorgesehen. Turnkey weist darauf hin, dass Clients diese Regel selbst einhalten müssen: Das Protokoll kann nicht verhindern, dass ein fehlerhafter Client seinen Zielschlüssel wiederverwendet. Damit ist neben der Enklave auch die Implementierung des Clients Teil des Sicherheitsmodells.

Auf der Produktseite von Managed Secrets wird für jedes Secret eine AES-256-GCM-Verschlüsselung gespeicherter Daten angegeben. Die API unterstützt sowohl einzelne Zugangsdaten als auch Anfragen für mehrere Secrets. Stapel-Exporte scheitern vollständig, wenn für auch nur eines der angeforderten Secrets die Autorisierung fehlt. So wird verhindert, dass ein nur teilweise genehmigtes Datenpaket freigegeben wird.

Warum es weiterhin auf den Empfänger ankommt

Die Aussage „Agenten können Zugangsdaten nutzen, ohne sie zu sehen“ beschreibt ein Integrationsmuster und ist keine Garantie dafür, dass jeder empfangende Prozess keinen Klartext lesen kann. In der Entwicklerdokumentation von Turnkey steht ausdrücklich, dass Klartext innerhalb der Enklave sowie auf dem Client vorhanden sein kann, der ein Secret importiert oder exportiert.

Hält ein separater Ausführungsdienst den Empfängerschlüssel, kann er Zugangsdaten entschlüsseln und verwenden, ohne dass das Modell darauf zugreifen kann. Hält die Laufzeitumgebung des Agenten selbst diesen Schlüssel, kann sie die Zugangsdaten entschlüsseln. Deshalb müssen der Empfänger, sein Arbeitsspeicher und seine Protokolle weiterhin geschützt werden.

Es gibt eine zweite Grenze: Richtlinien können den Kontext einer Anfrage prüfen, etwa eine angegebene Checkout-Domain. Turnkey überprüft jedoch nicht unabhängig, ob diese Angabe stimmt. Eine signierte Behauptung belegt, wer sie aufgestellt hat. Anwendungen benötigen weiterhin vertrauenswürdige Prüfungen, die diese Behauptung mit dem tatsächlichen Vorgang verknüpfen.

Genehmigungen, die sich an einen Arbeitsablauf anpassen lassen

Teams können den direkten Abruf erlauben, die Genehmigung einer Anfrage durch eine Person verlangen oder eine Zustimmung durch mehrere Agentenrollen voraussetzen. Richtlinien lassen sich ändern, ohne das zugrunde liegende Secret erneut importieren zu müssen. So kann ein Arbeitsablauf zunächst eng überwacht werden und später ausgewählte Anfragen automatisieren.

Der Leitfaden für programmierbare Zugriffssteuerung von Turnkey zeigt, wie ein Browser-Agent und ein Zahlungs-Agent gemeinsam eine Anfrage signieren. Nur der Zahlungs-Agent erhält entschlüsselbare Kartendaten. Vor der Genehmigung prüft die Browser-Komponente, ob die vorgeschlagene Domain mit der Seite übereinstimmt, die sie gerade verwendet. Das Beispiel zeigt, warum unabhängige Rollen und Prüfungen wichtiger sind, als lediglich zwei Genehmigungen zu zählen.

Für Agentenrollen lassen sich zeitlich begrenzte Sitzungszugangsdaten mit eingeschränkten Berechtigungen verwenden. So können Betreiber eine einzelne laufende Instanz widerrufen. Der Widerruf künftiger Zugriffe kann jedoch kein Geheimnis löschen, das ein Empfänger bereits entschlüsselt hat. Die Rotation nachgelagerter Zugangsdaten bleibt daher eine separate betriebliche Sicherheitsmaßnahme.

Von Wallet-Infrastruktur zu Finanzautomatisierung

Die bestehende Sicherheitsarchitektur von Turnkey nutzt AWS Nitro Enclaves und verbindet Hardware-Isolierung mit reproduzierbaren Builds und Fernattestierung. Reproduzierbarkeit ermöglicht den Vergleich von Software-Builds, während die Attestierung Nachweise über den im Enclave ausgeführten Code liefert. Managed Secrets überträgt diese Grundlage auf Zugangsdaten, die über Blockchain-Signaturschlüssel hinausgehen.

Das Unternehmen nennt Handelsunternehmen, Fintech-Backends, Entwickler von KI-Agenten und MPC-Verwahrer als vorgesehene Nutzer. Zugangsdaten für Börsen und OAuth-Token ermöglichen den fortlaufenden Zugriff auf Dienste; Sicherungskopien von Keyshares und Wiederherstellungsschlüssel dienen der Ausfallsicherheit. Dabei handelt es sich um unterschiedliche Anwendungsfälle mit jeweils eigenen Anforderungen an Genehmigungen und Empfänger – auch wenn sie dieselbe Speicherinfrastruktur nutzen.

Für Teams aus dem Finanztechnologiebereich liegt die Bedeutung darin, klarer zwischen dem Anfordern einer Aktion, der Autorisierung des Zugriffs und dem Erhalt nutzbarer Zugangsdaten zu unterscheiden. Managed Secrets stellt die Infrastruktur für diese Trennung bereit. Der daraus entstehende Schutz hängt von eng gefassten Richtlinien, zuverlässigen Genehmigenden und einem gut geschützten Dienst ab, der das Geheimnis letztlich verwendet.