Secure Enclave und Touch ID für Geheimnisse von KI-Agenten

Ein KI-Coding-Agent sollte eine Aktion anfordern können, ohne jemals die Zugangsdaten zu erhalten, die sie autorisieren. Das ist die Sicherheitsanforderung, um die herum sich die Architektur lohnen sollte. Secure Enclave und Touch ID können einen Teil davon auf einem Mac durchsetzen, aber nur, wenn das Geheimnis hinter einer Grenze bleibt, die der Agent nicht lesen kann.

Eine Mac-Abfrage mit dem Hinweis, ein Agent dürfe auf «GitHub» zugreifen, ist noch kein Sicherheitsdesign. Ein kopiertes ghp_...-Token, ein exportiertes AWS_SESSION_TOKEN oder ein in einen Tool-Aufruf eingefügter privater SSH-Schlüssel verleiht dem Agenten dauerhafte Macht. Keine spätere Touch-ID-Abfrage kann sie zurücknehmen. Die schwierige Aufgabe besteht nicht darin, die Zeichenkette zu verschlüsseln. Sie besteht darin, sie Software vorzuenthalten, die beliebigen Text weiterleitet.

Ich habe diesen Fehler in mehreren Varianten gesehen: ein Token in .env, ein Zugangsdatenhelfer, der ein Passwort ausgibt, ein in einen Container eingehängter privater Schlüssel und anschließend die Anweisung an einen Agenten, «alle verfügbaren Zugangsdaten zu verwenden». Jede dieser Entscheidungen wirkt vorübergehend. Jede macht das Geheimnis zu einem Teil des Arbeitsbereichs des Agenten.

Die Secure Enclave macht ein Bearer-Token nicht sicher, wenn man es weitergibt

Die Secure Enclave kann kryptografische Operationen schützen. Sie macht ein Bearer-Token jedoch nicht harmlos, nachdem ein Prozess es gelesen hat. Dieser Unterschied entscheidet, ob Touch ID ein Entwicklergeheimnis schützt oder nur eine zeremonielle Abfrage vor dem Leck einfügt.

Apple beschreibt die Secure Enclave als isolierte Hardware, die private Schlüssel erzeugen und verwenden kann, ohne ihren Klartext dem Hauptprozessor offenzulegen. Eine dokumentierte Einschränkung ist entscheidend: Private Schlüssel der Secure Enclave werden dort erzeugt, können keine vorhandenen privaten Schlüssel im Klartext importieren und unterstützen bestimmte Signatur- und Schlüsselaustausch-Operationen mit P-256. Ein API-Token ist keiner dieser privaten Schlüssel. Meist handelt es sich um eine undurchsichtige Zeichenkette, die ein entfernter Dienst von jedem akzeptiert, der sie vorlegt. Die Apple Developer Documentation, «Protecting keys with the Secure Enclave», beschreibt sowohl die Isolation als auch ihre Grenzen klar.

Damit bleiben drei verschiedene Objekte, die häufig zu einem einzigen zusammengefasst werden:

• Ein privater Schlüssel der Secure Enclave ist nicht exportierbares Schlüsselmaterial für begrenzte kryptografische Operationen.
• Ein Schlüsselbund-Element sind verschlüsselte Anwendungsdaten, deren Zugriff macOS einschränken kann.
• Ein Bearer-Credential ist ein kopierbarer Wert, der überall Zugriff gewährt, wo ein Dienst ihn akzeptiert.

Wer diese Begriffe gleichsetzt, baut schlechte Designs. Ein Schlüssel der Secure Enclave kann eine Challenge signieren, ohne sich selbst preiszugeben. Ein Schlüsselbund-Element kann die Anwesenheit der Person verlangen, bevor das System seine Daten zurückgibt. Ein Bearer-Token wird in dem Moment zu einem gewöhnlichen Geheimnis, in dem ein Prozess seine Bytes erhält.

Deshalb ist «Wir speichern das Token im Schlüsselbund» für einen Agenten keine vollständige Antwort. Damit ist die Speicherung im Ruhezustand erklärt. Offen bleibt, wer das Token anfordern kann, welcher Prozess es erhält, ob dieser Prozess es an einen Kindprozess weitergeben kann und ob er es nach stdout schreiben darf.

Apples Hinweise zum Schlüsselbund machen die Grenze deutlich. Keychain Services können vor der Rückgabe eines Elements eine Authentifizierung verlangen. Die Secure Enclave liefert für die biometrische Prüfung lediglich ein Bestanden- oder Nicht-bestanden-Ergebnis. Weder die App noch das Betriebssystem erhält die Fingerabdruckdaten. Das schützt die biometrische Vorlage sehr gut. Es sagt jedoch nichts darüber aus, was eine autorisierte App anschließend mit den zurückgegebenen Passwort-Bytes macht.

Bitten Sie Touch ID nicht, ein Problem zu lösen, nachdem Sie dem Agenten bereits ein Geheimnis gegeben haben.

Ein besseres Modell hat zwei Ebenen. Der Tresorprozess kann eine Zugangsinformation abrufen oder verwenden, nachdem die Person seine Sperre erfüllt hat. Der Agent kann eine Aktion anfordern, indem er eine Zugangsdatenbezeichnung und ein Ziel nennt. Er kann die Zugangsdaten jedoch weder lesen noch ersetzen oder ein anderes Tool auffordern, sie auszugeben. Der Tresorprozess führt die HTTP-Anfrage oder SSH-Authentifizierung aus und gibt ein bewusst begrenztes Ergebnis zurück.

Das ist eine engere Schnittstelle. Genau darum geht es.

Die Grenze muss vor stdout und Umgebungsvariablen liegen

Entwicklergeheimnisse entweichen durch gewöhnliche Datenwege, lange bevor ein Angreifer die Verschlüsselung überwinden muss. Umgebungsvariablen, die Vererbung an Kindprozesse, Shell-Trace-Ausgaben, Debug-Protokolle, Absturzberichte, Tool-Antworten und kopierte Terminalausgaben verwandeln ein geschütztes Geheimnis in ein transportables.

Ich formuliere das so deutlich, weil der Fehler sehr vorhersehbar ist: Wenn ein Agent printenv ausführen, .env lesen, einen Zugangsdatenhelfer aufrufen oder einen API-Schlüssel als MCP-Tool-Ergebnis erhalten kann, besitzt er die Zugangsdaten. Ob die ursprüngliche Speicherung den Schlüsselbund, einen Passwortmanager oder eine verschlüsselte Datei verwendet hat, ändert an der Bedrohung nichts mehr.

Betrachten Sie diesen häufigen Ablauf:

Agent -\u003e runs a shell command -\u003e credential helper reads Keychain
      -\u003e helper prints token -\u003e shell captures stdout
      -\u003e agent receives token -\u003e token appears in context or logs

Die Schlüsselbundabfrage kann genau wie vorgesehen funktioniert haben. Das System hat die Mac-Benutzerin oder den Mac-Benutzer authentifiziert. Anschließend hat der Helfer ein geschütztes Element in Text umgewandelt, den der Agent über denselben Kanal erhielt wie Compilerfehler und Testausgaben.

An diesem Punkt scheitert das Design.

Ein sicherer Weg für Zugangsdaten sieht deutlich anders aus:

Agent -\u003e requests \"POST api.example.com/releases\" using credential \"release-bot\"
      -\u003e gateway asks for authorization if required
      -\u003e gateway obtains or uses credential internally
      -\u003e gateway sends HTTPS request with Authorization header
      -\u003e agent receives status, selected headers, and response body

Der Agent erhält das Ergebnis der authentifizierten Aktion, nicht den Autorisierungs-Header. Das klingt nach einer kleinen Entscheidung bei der API. Tatsächlich trennt sie delegierte Ausführung von der Verteilung von Geheimnissen.

Dasselbe gilt für SSH. Übergeben Sie einem Agenten keinen Pfad zu ~/.ssh/id_ed25519, keinen SSH_AUTH_SOCK, der ohne sichtbare Grenze beliebige Challenges signieren kann, und keinen Befehl, der einen Schlüssel aus einem sicheren Speicher ausgeben kann. Lassen Sie einen eng begrenzten Helfer die SSH-Verbindung herstellen und den angeforderten Befehl ausführen. Geben Sie stdout, stderr, den Exit-Status und Informationen zur Host-Identität zurück. Halten Sie den privaten Schlüssel aus dem Prozessbaum des Agenten heraus.

Das kostet etwas. Manche Entwicklertools gehen davon aus, dass sie Zugangsdaten direkt lesen können. Ein Gateway bedeutet daher Adapter, engere Tool-APIs und gelegentliche Reibung bei ungewöhnlichen Authentifizierungsabläufen. Diese Engineering-Kosten zahle ich lieber einmal, als ein Produktions-Token zu rotieren, nachdem es in einem Agentenprotokoll aufgetaucht ist.

Verwechseln Sie eine verschlüsselte Festplatte nicht mit einem kontrollierten Ausführungspfad.

Touch ID beweist Anwesenheit, nicht Absicht

Touch ID kann beweisen, dass eine Person zu einem bestimmten Zeitpunkt eine Sperre freigegeben hat. Es kann nicht beweisen, dass sie den nächsten Befehl des Agenten verstanden hat, dass der Befehl der Absicht des Repositorys entspricht oder dass das Ziel sicher ist.

Apples Framework LocalAuthentication gibt der App bewusst nur ein begrenztes Ergebnis: Das Framework arbeitet mit der Secure Enclave zusammen und gibt Erfolg oder Misserfolg zurück. Die aufrufende App liefert den Begründungstext und wählt die Authentifizierungsrichtlinie. Diese Trennung ist richtig. Das System sollte nicht so tun, als könne es die Absicht einer Anwendung aus einem biometrischen Ereignis herauslesen.

Behandeln Sie Touch ID bei Agentenarbeit als Sperre für eine Fähigkeit, nicht als Genehmigung eines Textes. Eine Karte mit «Diesem Agenten erlauben, Produktionszugangsdaten zu verwenden» liefert einem Menschen zu wenig Informationen. Eine Karte, die den signierten Prozess, den Zielhost, die Bezeichnung der Zugangsdaten und die Dauer der Genehmigung für einen Aufruf oder einen Lauf nennt, gibt der Person eine brauchbare Entscheidungsgrundlage.

Ich bevorzuge drei getrennte Zeitpunkte für die Autorisierung:

1. Entsperren Sie den Tresor. Solange er gesperrt ist, schlägt jede Aktion mit Geheimnissen fehl. Es darf keinen Zweig «ungeschützte Alternative verwenden» geben.
2. Genehmigen Sie einen neuen Agentenprozess für die Dauer seines Laufs. Die Genehmigung sollte die Codesignatur-Autorität nennen, nicht nur einen veränderlichen Prozessnamen wie node oder python.
3. Verlangen Sie für jede Nutzung von Zugangsdaten mit irreversibler Reichweite die Anwesenheit der Person, etwa bei einem Produktions-Deployment-Token, einer Cloud-Owner-Rolle oder einem SSH-Schlüssel, der eine ganze Flotte verändern kann.

Eine sitzungsbezogene Genehmigung ist die richtige Voreinstellung für Coding-Agenten. Ein neuer Prozess ist eine sinnvolle Grenze: Ein frischer Start kann eine andere Binärdatei, einen anderen Arbeitsbereich, andere vererbte Umgebungsvariablen oder eine andere MCP-Konfiguration verwenden. Eine dauerhafte Genehmigung macht spätere Aktionen gerade dann unsichtbar, wenn ihre Herkunft schwerer zu prüfen ist.

Eine Genehmigung pro Aufruf sollte selten bleiben, aber kompromisslos gelten, wenn die Zugangsdaten großen Schaden verursachen können. Ein Token, das nur einen schreibgeschützten Issue-Tracker öffnet, braucht keine Fingerabfrage für jedes GET. Eine SSH-Zugangsinformation, die kubectl apply in der Produktion ausführen kann, schon. Die daraus entstehende Unterbrechung ist beabsichtigt.

Die verbreitete Alternative ist eine große Richtliniendatei: Erlauben Sie Befehle, die diesem regulären Ausdruck entsprechen, erlauben Sie Domains aus dieser Liste, lehnen Sie Argumente mit bestimmten Wörtern ab. Das wirkt skalierbar, weil Abfragen durch Automatisierung ersetzt werden. Gleichzeitig entsteht eine zweite Programmiersprache, die Shell-Quoting, Umleitungen, Wrapper, Symlinks, curl --config, codierte Payloads, die Erweiterung entfernter Befehle und jedes neue Tool modellieren muss, das ein Agent installiert.

Ich würde Produktionsrechte nicht hinter eine Grammatik stellen, die nach Freitag niemand mehr prüft.

Verwenden Sie stattdessen eine kleine Entscheidungskaskade: gesperrt oder entsperrt, dieser Lauf genehmigt oder nicht, für diese Zugangsdaten eine neue Genehmigung erforderlich oder nicht. Diese Kontrollen haben bei einer späteren Untersuchung eine sichtbare Bedeutung.

Zugriffskontrollen des Schlüsselbunds haben scharfe Kanten

Ein biometrisch geschütztes Schlüsselbund-Element ist nur dann nützlich, wenn Sie die Zugriffsbeschränkung bewusst auswählen, das Fallback-Verhalten verstehen und verhindern, dass der autorisierte Prozess zu einem Ausgabegerät für Geheimnisse wird.

Apple dokumentiert SecAccessControlCreateWithFlags, um Zugänglichkeits- und Autorisierungsanforderungen an ein Schlüsselbund-Element zu binden. Für ein lokales Entwicklergeheimnis, das nicht über Backup oder iCloud Keychain übertragen werden soll, ist kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly meist die sinnvolle Speicherklasse. Sie verlangt einen Gerätecode und macht das Element unzugänglich, wenn der Code entfernt wird. Der Zusatz ThisDeviceOnly verhindert außerdem die Übertragung auf ein anderes Gerät.

Wenn ein Geheimnis eine biometrische Prüfung erfordern muss, verwenden Sie ein Zugriffskontroll-Flag, statt eine Abfrage um einen gewöhnlichen Schlüsselbundabruf herumzubauen. Dieser vereinfachte Swift-Ausschnitt speichert ein generisches Passwort, das nur die aktuell registrierte biometrische Gruppe freigeben kann:

import Security

let access = SecAccessControlCreateWithFlags(
    kCFAllocatorDefault,
    kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
    .biometryCurrentSet,
    nil
)!

let item: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.example.agent-gateway",
    kSecAttrAccount: "release-bot",
    kSecAttrAccessControl: access,
    kSecValueData: Data(token.utf8)
]

let status = SecItemAdd(item as CFDictionary, nil)
precondition(status == errSecSuccess)

biometryCurrentSet ist strenger als biometryAny. Es bindet den Zugriff an die derzeit registrierten Fingerabdrücke oder Gesichtsdaten. Eine Änderung der registrierten biometrischen Merkmale macht das geschützte Element ungültig. biometryAny akzeptiert jedes registrierte biometrische Merkmal und bietet nicht dieselbe Warnung bei Änderungen der Registrierung. Apple führt beide Flags in SecAccessControlCreateFlags auf. Wählen Sie das erste, wenn ein neuer Fingerabdruck eine bewusste erneute Bereitstellung erzwingen soll.

Für den Abruf braucht es einen Authentifizierungskontext und eine Vorgabe für den Vorgang, die die Aktion verständlich benennt:

import LocalAuthentication
import Security

let context = LAContext()
context.localizedReason = "Use release-bot for the requested deployment action"

let query: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.example.agent-gateway",
    kSecAttrAccount: "release-bot",
    kSecReturnData: true,
    kSecMatchLimit: kSecMatchLimitOne,
    kSecUseAuthenticationContext: context,
    kSecUseOperationPrompt: "Authorize credential use"
]

var result: CFTypeRef?
let status = SecItemCopyMatching(query as CFDictionary, &result)

Der Code ist in einer Hinsicht absichtlich unvollständig: Er sagt nicht, was mit result geschehen soll. Eine gewöhnliche App könnte es in Data umwandeln, einen Authorization-Header erstellen und fortfahren. Ein Agenten-Gateway muss sicherstellen, dass die Daten in dem Prozess bleiben, der den authentifizierten Aufruf ausführt. Geben Sie sie nicht über die MCP-Antwort zurück. Speichern Sie sie nicht in einer temporären Datei. Protokollieren Sie sie nicht, wenn die Anfrage fehlschlägt.

Seien Sie vorsichtig bei Wiederverwendungszeiträumen. Apples Beispiel zeigt, dass eine erfolgreiche Touch-ID-Prüfung ein kürzlich erfolgtes Entsperren des Geräts für eine konfigurierbare Dauer wiederverwenden kann, bis zu fünf Minuten. Diese Bequemlichkeit erspart gewöhnlichen Apps doppelte Abfragen. Bei einem Kontrollpunkt für Agenten kann sie jedoch genau den Moment bewusster Genehmigung beseitigen, den Sie erzwingen wollten. Verwenden Sie für Zugangsdaten, die bei jeder Verwendung geschützt werden müssen, kein Kulanzfenster, außer Sie haben diese Entscheidung bewusst getroffen und dokumentiert.

Eine weitere Grenze muss erwähnt werden. Biometrie kann fehlschlagen, nicht verfügbar sein oder nach mehreren Fehlversuchen gesperrt werden. Apple bietet Richtlinien, die einen Fallback auf den Gerätecode erlauben, und Richtlinien, die Biometrie verlangen. Entscheiden Sie, welche davon zu Ihrer Sicherheitsaussage passt. Wenn Sie sagen «Touch ID bei jedem Produktions-Deployment», verändert ein still akzeptierter anderer Fallback die Aussage und sollte auch den Text der Benutzeroberfläche verändern.

Folgen Sie einer schädlichen Anweisung bis zu dem Punkt, an dem sie gewinnt

Ein Agent braucht keinen spektakulären Exploit, um Zugangsdaten zu missbrauchen. Eine plausible Anweisung, eine weitreichende Fähigkeit und ein Ausgabekanal, der mehr zurückgibt als beabsichtigt, genügen.

Stellen Sie sich einen Coding-Agenten vor, der bei einem Pull Request hilft. Er liest ein von einem Angreifer hinzugefügtes Repository-Dokument. Darin steht, dass die Release-Prüfung ein Hilfsskript ausführen muss. Das Skript verwendet die bestehende Cloud-CLI-Sitzung der Entwicklerin oder des Entwicklers, listet Deployment-Zugangsdaten auf und sendet eine codierte Anfrage an einen externen Endpunkt. Der Agent darf Shell-Befehle ausführen und hat AWS_PROFILE, GH_TOKEN oder Zugriff auf einen SSH-Agenten geerbt.

Der erste Fehler passierte, bevor das Skript lief: Die Entwicklerperson hat dem Agenten Umgebungszugangsdaten gegeben. Der zweite passierte, als der Tool-Runner dem Agenten beliebige Netzwerkziele überließ. Der dritte passierte, als Protokolle und Befehlsausgaben Authentifizierungsmaterial oder Sitzungsdetails in den Kontext des Agenten zurückgaben.

Touch ID bei der Anmeldung hätte dieses Design nicht gerettet. Die Person kann sich vor einer Stunde authentifiziert haben und anschließend weggegangen sein. Ein Schlüsselbund-Element, das nur durch «Gerät entsperrt» geschützt ist, kann einem Prozess zugänglich werden, den die Person für diese Aufgabe nie autorisieren wollte. Apple weist selbst darauf hin, dass der Zugriff bei entsperrtem Gerät für manche Anwendungsfälle nicht restriktiv genug ist.

Ändern wir nun die Architektur. Der Agent fordert eine Aktion mit diesen Feldern an:

{
  "channel": "http",
  "credential": "release-bot",
  "method": "POST",
  "url": "https://api.example.com/releases",
  "body": {"branch": "feature/fix-ci"}
}

Das Gateway löst release-bot intern auf. Es vergleicht das angeforderte Ziel mit der Aktion, die es ausführen wird, fragt bei Bedarf nach einer Genehmigung, fügt den Header selbst ein und protokolliert anschließend die Aktion. Der Agent erhält den HTTP-Status und eine bereinigte Antwort. Den Header-Wert sieht er nie.

Das Repository-Dokument kann den Agenten weiterhin dazu bringen, ein schlechtes Deployment anzufordern. Deshalb sind die Prüfung von Ziel und Aktion wichtig. Das Dokument kann den Agenten aber nicht dazu bringen, ein Token zu stehlen, das er nie besessen hat. Nach dem genehmigten Aufruf kann es das Token auch nicht gegen einen anderen Dienst verwenden.

Das ist eine echte Verringerung des Schadensradius, keine Magie. Ein kompromittierter Agent mit einer Genehmigung zum Deployment kann weiterhin etwas Schädliches deployen. Das System begrenzt den Diebstahl von Zugangsdaten und macht die Aktion zuordenbar. Es löst weder schädliche Codeprüfung noch ersetzt es menschliches Urteilsvermögen.

Bei der Prüfung von Agenten-Setups suche ich nach der frühesten Stelle, an der eine Anweisung zu einer Geheimnis-Zeichenkette werden kann. Dort gehört die Korrektur meistens hin.

Fähigkeits-Handles sind sicherer als Geheimnis-Zeichenketten

Ein Agent sollte eine benannte Fähigkeit mit strukturierten Aktionsparametern anfordern. Ein vertrauenswürdiger lokaler Prozess löst diese Fähigkeit anschließend in eine Zugangsinformation auf und führt den Seiteneffekt aus.

Das Wort «Fähigkeit» wird oft ungenau verwendet. Hier bedeutet es eine Referenz, die nur innerhalb des Gateways nützlich ist, etwa release-bot, staging-ssh oder billing-read. Es handelt sich nicht um einen Token-Alias, den der Agent gegen das Token eintauschen kann. Es ist keine Vorlagenvariable, die in einen Umgebungswert erweitert wird. Es ist ein Selektor, den ein Prozess erhält, der den alleinigen Zugriff auf die Zugangsdaten behält.

Diese Entscheidung zwingt zu Disziplin bei der Tool-Schnittstelle. HTTP-Tools sollten Methode, URL, für den Agenten sichere Header und den Body akzeptieren. Die Zugangsdaten dürfen erst nach der Validierung und innerhalb des Gateways eingefügt werden. SSH-Tools sollten Host, Benutzer, Befehl und die ausgewählte Identität der Zugangsdaten akzeptieren und dann einen Helfer aufrufen, der den Authentifizierungspfad besitzt. Sie sollten weder einen IdentityFile-Pfad zurückgeben noch eine allgemeine Operation «Geheimnis lesen» anbieten.

Hier gewinnt eine langweilige Schnittstelle. Eine allgemeine Shell, die jede Entwickler-Zugangsinformation erbt, unterstützt am ersten Tag mehr Tools. Gleichzeitig wird es fast unmöglich festzustellen, welcher Agent welches Konto für welche ausgehende Anfrage verwendet hat. Eine begrenzte HTTP- und SSH-Schnittstelle bietet anfangs weniger Möglichkeiten, bewahrt aber die Fakten, die für eine Sicherheitsentscheidung nötig sind.

Sallyport folgt diesem Modell: Der Agent verwendet den mitgelieferten sp mcp-Stdio-Shim, um HTTP- oder SSH-Aktionen anzufordern. Die App hält API- und SSH-Zugangsdaten in ihrem verschlüsselten Tresor und führt die Aktion selbst aus. Der Agent erhält das Ergebnis, nicht die Zugangsdaten im Klartext.

Die Einschränkung ist ehrlich. Ein Tool, das nur HTTP und SSH kennt, deckt nicht automatisch jede Desktop-Anwendung, jeden Datenbankclient, jede Paketregistrierung oder jede lokale Binärdatei in einer Entwicklerumgebung ab. Das Hinzufügen eines Kanals sollte die Gestaltung seines Aktionsmodells, seines Verhaltens zur Bereinigung, seiner Autorisierungsregeln und seiner Audit-Felder erfordern. Ein allgemeiner Schalter «alles mit meiner Anmeldung ausführen» ist leichter zu veröffentlichen und schwerer zu verteidigen.

Verwenden Sie eindeutige Bezeichnungen für Zugangsdaten, die ihre vorgesehene Reichweite erkennen lassen. prod-deployer ist besser als token-4. github-readonly-org ist besser als github. Die Bezeichnung wird Teil der menschlichen Entscheidung und des Audit-Datensatzes. Unklarheit wird damit zu einem betrieblichen Problem statt zu einer Frage des Namensstils.

Halten Sie das Anforderungsformat so eng, dass das Gateway es ohne Interpretation anzeigen kann. Eine prüfende Person versteht POST https://api.example.com/releases. Die Wirkung eines Base64-Blocks, der durch einen Shell-Wrapper geleitet wird, lässt sich nicht zuverlässig erkennen.

Ein Audit-Protokoll muss die Aktion beschreiben, ohne das Geheimnis zu kopieren

Ein Gateway für Zugangsdaten braucht zwei Arten von Datensätzen: den Agentenlauf, der eine Berechtigung erhalten hat, und jede von ihm versuchte Nebenwirkung. Ein einziger Strom von Terminalprotokollen kann beides nicht liefern, ohne entweder Kontext zu verlieren oder sensible Daten offenzulegen.

Protokollieren Sie den Lauf, wenn ein neuer Agentenprozess Zugriff anfordert. Erfassen Sie die dem Gateway verfügbare Prozessidentität, seine Codesignatur-Autorität, die Startzeit, die Genehmigungsentscheidung und den Widerrufsstatus. Wenn die Person den Lauf widerruft, müssen spätere Anfragen dieses Prozesses fehlschlagen, auch wenn der Prozess weiterläuft.

Protokollieren Sie jede Aktion separat. Für HTTP sollten die Bezeichnung der Zugangsdaten, Methode, Ziel, Status, Zeitmessung und eine sorgfältig ausgewählte Zusammenfassung des Bodys erhalten bleiben. Für SSH sollten Bezeichnung der Zugangsdaten, Host, entfernter Benutzer, Befehl, Exit-Code und Zeitmessung erfasst werden. Protokollieren Sie keine Authorization-Header, Bearer-Werte, Bytes privater Schlüssel, vollständigen Anfrage-Bodies mit Kundendaten oder uneingeschränkte Befehlsausgaben.

Protokolle mit Geheimnissen werden zu einem weiteren Tresor mit schlechteren Zugriffskontrollen.

Manipulationsnachweise sind wichtig, weil ein Vorfall mit einem Agenten häufig mit einer strittigen Zeitleiste beginnt: «Hat der Agent diesen Endpunkt aufgerufen?» «War die Sitzung genehmigt?» «Hat jemand die lokale Historie bearbeitet?» Ein hashverkettetes Ereignisprotokoll liefert eine konkrete Grundlage für die spätere Prüfung. Die Prüfung sollte funktionieren, ohne jedes Ereignis entschlüsseln zu müssen. Andernfalls müsste die Person, die die Integrität prüft, zuerst die sensiblen Daten erhalten, die das Protokoll schützen sollte.

Sallyport erstellt seine Journale für Sitzungen und Aktivitäten aus einem schreibblinden, verschlüsselten und hashverketteten Audit-Protokoll. sp audit verify prüft die Kette offline, ohne einen Tresorschlüssel zu benötigen. Das ist nützlich, weil die Prüfung der Integrität keinen Zugriff auf Entwicklergeheimnisse erfordern sollte.

Eine Hash-Kette verhindert nicht, dass ein kompromittierter Rechner eine schlechte Aktion versucht. Sie erschwert das stille Umschreiben der aufgezeichneten Abfolge und gibt einer Untersuchung eine konsistente Ereignisfolge. Stellen Sie sie nicht als Prävention dar.

Apple Platform Security und die Apple Developer Security-Dokumentation sind hier eine nützliche Lektüre, weil sie Hardwareschutz, Systemkontrollen und die Verantwortung von Anwendungen voneinander trennen. Genau diese Trennung braucht die Sicherheit von Agenten. Sichere Hardware kann den Zugriff absichern, aber die Anwendung entscheidet weiterhin, was sie über das Netzwerk sendet und auf der Festplatte speichert.

Produktionszugriff braucht weniger Wege, nicht klügere Vermutungen

Der sicherste Rollout für KI-Coding-Agenten beginnt mit einer kleinen Gruppe benannter Zugangsdaten, bekannten Zielen, sichtbarer Sitzungsidentität und einer Klasse irreversibler Aktionen, die eine neue Genehmigung erfordert. Ein umfassender Umgebungszugriff lädt dazu ein, das eigene Bedrohungsmodell während eines Ausfalls kennenzulernen.

Verwenden Sie diese Prüfung, bevor Sie einem Agenten den Zugriff auf Zugangsdaten erlauben:

1. Bestätigen Sie, dass der Agent das Geheimnis nicht über Umgebungsvariablen, Dateien, einen Zugangsdatenhelfer, Tool-Ausgaben oder einen Kindprozess lesen kann.
2. Bestätigen Sie, dass der vertrauenswürdige Prozess die HTTP-Anfrage oder SSH-Authentifizierung ausführt und die Zugangsdaten einfügt, nachdem der Agent strukturierte Parameter übermittelt hat.
3. Konfigurieren Sie die Tresorsperre so, dass jede Aktion mit Geheimnissen abgelehnt wird. Testen Sie dies bei gesperrter App, nicht nur bei gesperrtem Mac-Bildschirm.
4. Fordern Sie beim Start eines neuen Agentenprozesses eine neue Sitzungsfreigabe an, und sorgen Sie dafür, dass die Genehmigung seine Signatur-Autorität nennt.
5. Kennzeichnen Sie Zugangsdaten mit Deployment-, Administrations-, destruktiver oder weitreichender SSH-Befugnis so, dass für jede Verwendung eine Genehmigung nötig ist.

Testen Sie die unangenehmen Fälle. Fügen Sie einer Zugangsinformation außerhalb der Produktion ein falsches Geheimnis wie canary-agent-secret-9f31 hinzu. Bitten Sie den Agenten, das Repository zu prüfen, Tests auszuführen und Tool-Ausgaben zu melden. Durchsuchen Sie anschließend sein Protokoll, die Terminal-Historie, temporäre Verzeichnisse, Protokolle, die Umgebung von Kindprozessen und die Audit-Datensätze nach genau dieser Zeichenkette. Taucht sie außerhalb des Tresorprozesses auf, hat das Design dem Agenten einen Weg zum Geheimnis übergeben.

Tun Sie dasselbe für den Widerruf. Genehmigen Sie einen Lauf, führen Sie eine harmlose Anfrage aus, widerrufen Sie den Lauf bei weiterhin geöffnetem Prozess und versuchen Sie dieselbe Anfrage erneut. Die zweite Anfrage muss fehlschlagen, bevor sie den entfernten Dienst erreicht. Eine Widerrufskontrolle, die erst nach einem Neustart wirksam wird, ist Papierarbeit, keine Eindämmung.

Verwenden Sie eine biometrische Abfrage nicht als Dekoration um einen Zugangsdatenexport. Platzieren Sie die Abfrage an der Grenze, an der die Person einen bestimmten Prozess oder eine bestimmte Aktion autorisiert, und halten Sie die Zugangsdaten auf der geschützten Seite. So werden Secure Enclave und Touch ID zu nützlichen Kontrollen für KI-Coding-Agenten statt zu einer beruhigenden Geschichte über Speicherung.