macOS Keychain für autonome Programmierwerkzeuge

macOS Keychain schützt Zugangsdaten gut, solange niemand sie benutzt. Für ein autonomes Programmierwerkzeug ist das noch keine vollständige Sicherheitsgrenze. Sobald ein Prozess ein API-Token oder einen privaten Schlüssel abrufen kann, kann er die Daten gewöhnlich auch kopieren, ausgeben, versenden oder weiterverwenden, nachdem der Betreiber die Aufgabe für beendet hält.

Bei einem Agenten wiegt dieser Unterschied schwerer als bei einer herkömmlichen Desktop-Anwendung. Ein Mensch wählt einen Menübefehl und sieht das unmittelbare Ergebnis. Ein Agent deutet Text, ruft Werkzeuge auf, verarbeitet deren Ausgabe und kann stundenlang weiterarbeiten. Keychain-Speicherung beantwortet: „Wer darf dieses Geheimnis lesen?“ Vermittelte Ausführung beantwortet die schwierigere Frage: „Darf genau dieser Prozess jetzt genau diese Aktion ausführen, ohne das Geheimnis jemals zu erhalten?“ PAM-Sitzungsauthentifizierung beantwortet eine verwandte, aber andere Frage darüber, wer eine Anmeldesitzung eröffnet hat. Wer diese drei Kontrollen gleichsetzt, hinterlässt Lücken, die in einer Vorführung unsichtbar und nach einem Vorfall nur mühsam zu rekonstruieren sind.

Keychain schützt gespeicherte Zugangsdaten, nicht jede Nutzung

Keychain verschlüsselt gespeichertes geheimes Material und vermittelt den Zugriff über macOS-Sicherheitsdienste. Ein Token ist dort viel besser aufgehoben als in einer .env-Datei, im Shell-Verlauf, in einem Repository oder in der Agentenkonfiguration. Ein Eintrag kann Zugriffskontrollen tragen, und das System kann vor der Freigabe die Anwesenheit des Benutzers verlangen. Das schützt tatsächlich vor einfachem Dateidiebstahl und unbefugtem Lesen.

Die Grenze endet mit der Offenlegung. Gibt ein Hilfsprogramm das Token als Text zurück, befindet es sich danach im Hilfsprogramm, auf dem IPC-Weg und im empfangenden Prozess. Es kann in einer Debugmeldung, einem Ausnahmeobjekt, einem Transkript, einem Absturzbericht, im Auslagerungsspeicher, in einer kopierten Umgebung, einem Kindprozess oder einer bösartigen ausgehenden Anfrage auftauchen. Keychain kann diese Bytes nicht zurückholen. Späteres Sperren macht ein bereits in den Speicher kopiertes Bearer-Token nicht ungültig.

Apples Dokumentation zu Keychain Services beschreibt das Speichern und Abrufen von Passwörtern, Schlüsseln und Zertifikaten. Diese Formulierung ist präzise: Der Abruf ist ein vorgesehener Ausgang. Keychain verwandelt nicht jedes Geheimnis in einen nicht exportierbaren Signaturschlüssel. Manche kryptografischen Schlüssel lassen sich mit Zugriffskontrollen anlegen und über Sicherheits-APIs verwenden, ohne ihr privates Material zu exportieren. Ein allgemeines API-Token muss jedoch irgendwo zu einem HTTP-Header werden. Entscheidend ist, welche vertrauenswürdige Komponente diese Anfrage erstellt und sendet.

Das lässt sich mit einem Wegwerfwert statt eines Produktionstokens prüfen. Speichere ihn, lass ihn über genau denselben Ausführungspfad wie beim Agenten abrufen und untersuche, was der Prozess mit den zurückgegebenen Bytes tun kann:

security find-generic-password -a agent-test -s example-api -w

Die Ausgabe besteht aus dem Geheimnis und einem Zeilenumbruch:

test_token_7f3a...

Kann der Agent oder eine von ihm gesteuerte Shell den Befehl erfolgreich ausführen, hat die Speicherschicht ihre Entscheidung schon getroffen. Eine geschwärzte Terminalanzeige ändert nur, was ein Mensch sieht. Der Prozess kann die Ausgabe weiterhin umleiten, kodieren oder in eine Anfrage schreiben.

Ein erlaubter Leser kann zum Exporteur werden

Der riskante Akteur ist oft kein unbekannter Angreifer, sondern das absichtlich zugelassene Programmierwerkzeug. Ein autonomer Prozess braucht breiten Zugriff auf Dateien, Build-Werkzeuge, Paketbefehle und Netzwerkclients. Erhält derselbe Prozess lesbare Zugangsdaten, können eine Prompt-Injection, eine kompromittierte Abhängigkeit oder ein falscher Befehl normalen Zugriff in einen Export verwandeln.

Codesignatur-Anforderungen können einschränken, welche Anwendung einen Keychain-Eintrag liest. Sie helfen gegen einen anderen, unsignierten oder anders signierten Prozess. Sie helfen viel weniger, wenn die zugelassene Anwendung erweiterbar ist, Shells startet, Plugins lädt, nicht vertrauenswürdige Anweisungen aus Repositories annimmt oder ein Werkzeugprotokoll anbietet. Gerade die signierte Binärdatei kann das vom Angreifer beeinflusste Verhalten ausführen.

Hinzu kommt Delegation. Liest ein zugelassenes Desktop-Hilfsprogramm ein Token und reicht es per Standardeingabe an den Agenten weiter, sieht Keychain das Hilfsprogramm und nicht den Endverbraucher. Legt das Hilfsprogramm das Token in eine Umgebungsvariable, kann jedes Kind mit geerbter Umgebung es erhalten. Die erste Zugriffsentscheidung sagt nichts darüber, welche spätere Operation beabsichtigt war.

Eine brauchbare Prüfung verfolgt das Geheimnis als Datenstrom und nicht als Kästchen im Architekturdiagramm. Vier Fragen müssen beantwortet werden:

• Welcher Prozess erhält zuerst den Klartext?
• Können Kindprozess, Plugin, Shell-Befehl oder Transkript eine Kopie erhalten?
• Darf der Empfänger Ziel, HTTP-Methode, Pfad oder SSH-Host wählen?
• Welches Ereignis beendet seine Befugnis, und löscht es bereits offengelegtes Material?

Teams beantworten häufig nur die erste Frage. Dann wirkt der Entwurf im Ruhezustand geschützt, verhält sich nach dem Start aber wie eine langlebige Klartext-Zugangsdatenquelle.

PAM belegt eine Anmeldung, nicht die Absicht des Agenten

Pluggable Authentication Modules, kurz PAM, ermöglichen einem Dienst eine Authentifizierungsrichtlinie an der Anmeldegrenze. Unter macOS verwenden Dienste wie sudo, login und Wege zur Fernanmeldung benannte PAM-Konfigurationen. Ein PAM-Stack kann einen Benutzer authentifizieren, ein Konto prüfen, Zugangsdaten etablieren und eine Sitzung öffnen oder schließen. Damit lässt sich entscheiden, ob jemand eine privilegierte Betriebssystemsitzung beginnen darf.

PAM vermittelt normalerweise nicht jeden HTTP-Aufruf eines bereits laufenden Agenten. Nach der Authentifizierung handelt der Prozess mit seiner Betriebssystemidentität und seinen Fähigkeiten. Kann er ein Token lesen, bindet PAM die frühere Touch-ID-Geste oder Passworteingabe nicht an eine spätere Einzelanfrage. Ohne eine weitere Komponente versteht PAM auch nicht, dass POST /releases empfindlicher ist als GET /status.

Das Wort „Sitzung“ benennt mehrere voneinander unabhängige Lebensdauern. Eine PAM-Sitzung kann eine Anmeldung oder sudo-Aktivität umgeben. Eine Terminalsitzung kann in einem Fenster bestehen bleiben. Eine Agentensitzung kann einen Prozesslauf, ein Gespräch oder eine fortgesetzte Aufgabe meinen. Eine API-Sitzung kann der Lebensdauer eines Bearer-Tokens entsprechen. Das Ende einer Sitzung beendet die anderen nicht automatisch.

Ein konkreter Fehlerablauf: Ein Betreiber authentifiziert sich für eine Shell, startet einen Agenten und erlaubt Keychain-Zugriff. Der Agent liest ein Deployment-Token. Stunden später schließt der Betreiber das sichtbare Gespräch, doch ein Kindprozess lebt mit dem Token in seiner Umgebung weiter. PAM hat die ursprüngliche Sitzung korrekt authentifiziert und Keychain den Abruf richtig genehmigt. Beide verhindern die weitere Nutzung nicht, weil keiner die Lebensdauer der Aktion besitzt.

PAM passt zur Entscheidung, ob ein Betriebssystemkonto eine Sitzung aufbauen darf. Die Authentifizierung beweist keine frische menschliche Absicht für jede Aktion innerhalb dieser Sitzung. Diese Bedeutung besitzt PAM nicht.

Authentifizierung und Autorisierung beantworten andere Fragen

Authentifizierung stellt fest, wer ein Akteur ist oder wenigstens welche Zugangsdaten er vorgelegt hat. Autorisierung entscheidet, was er in einem bestimmten Kontext tun darf. Geheimspeicherung bewahrt Material bis zu einem erlaubten Abruf oder einer kryptografischen Operation. Die Kontrollen unterstützen sich, ersetzen sich aber nicht.

Bei autonomen Werkzeugen muss der Akteur genau benannt werden. „Der Benutzer“ ist zu ungenau. Betreiber, signierte Agenten-Binärdatei, neu gestarteter Agentenprozess, MCP-Server, Shell-Kind und entferntes API-Konto sind verschiedene Akteure. Gilt eine Genehmigung gleichzeitig für alle, muss der Entwurf das offen sagen.

Für Alltagsarbeit ist der Prozesslauf oft die sinnvollste Einheit. Der Betreiber kann einen erkannten Prozess bis zu seinem Ende autorisieren und für einen neuen Lauf neu entscheiden. So erbt ein stiller Neustart keine alte Genehmigung. Bei besonders empfindlichen Zugangsdaten sollte jede einzelne Nutzung eine Entscheidung verlangen.

Eine Genehmigung pro Aufruf ist nicht automatisch sicher. Ein Dialog mit „Netzwerkzugriff erlauben?“ liefert kaum Entscheidungsgrundlagen. Er sollte den anfragenden Prozess sowie risikorelevante Details zeigen, etwa Zugangsdaten-Alias, HTTP-Methode und Ziel oder SSH-Benutzer und Host. Er muss auch Genehmigungsmüdigkeit vermeiden. Unterbricht ein harmloser Lesezugriff genauso wie ein Produktionsschreibzugriff, werden beide blind bestätigt.

Prozessidentität braucht mehr als Pfad oder Anzeigename, denn beide lassen sich kopieren. Unter macOS kann eine Codesignatur-Anforderung die Entscheidung an Signaturautorität und Designated Requirement binden, während eine Prozesskennung laufende Instanzen trennt. Angezeigt werden sollte die tatsächlich geprüfte Signaturinformation, nicht ein freundlicher Name, den eine fremde Binärdatei nachahmen kann.

Eine Signatur beweist trotzdem kein gutes Verhalten. Sie belegt Herkunft im Signaturmodell, nicht Absicht. Ein korrekt signierter Agent kann feindlichen Repository-Anweisungen folgen, und ein signierter Plugin-Host kann angreifergesteuerte Inhalte laden. Eine Sitzungsfreigabe sollte daher bedeuten, dass dieser identifizierte Prozess bis zu seinem Ende Aktionen anfragen darf, nicht dass alle seine Anfragen sicher sind.

Vor der Umsetzung muss feststehen, wie Nachfahren zur Sitzung gehören. Automatisches Vertrauen in jedes Kind erzeugt schwer widerrufbare Prozessbäume und lässt allgemeine Shells zu viel Befugnis erben. Eine neue menschliche Nachfrage für jedes kurzlebige Hilfsprogramm macht Automatisierung unbrauchbar. Ein klarer Entwurf hält die Autorisierung an der Broker-Verbindung des zugelassenen Agenten. Kinder erben keine Zugangsdaten und erreichen geschützte Aktionen nur über einen vermittelten Kanal, den die übergeordnete Sitzung widerrufen kann.

Das Prozessende ist ein brauchbares automatisches Ende, aber der Betreiber braucht auch sofortigen Widerruf. Der Broker muss danach wartende und künftige Aktionen ablehnen, die Sitzung ungültig machen und die Entscheidung protokollieren. Ob eine schon übertragene Anfrage noch gestoppt werden kann, hängt von Protokoll und Fernsystem ab. Widerruf macht abgeschlossene Arbeit nicht rückgängig.

Auch Neustarts gehören in den Test. Manche Clients aktualisieren sich, verbinden sich nach einem Fehler neu oder setzen ein Gespräch in einem neuen Prozess fort. Bequemer Code nennt das dieselbe logische Sitzung. Die Sicherheitsgrenze muss einen neuen Prozess als neu behandeln, sofern kein absichtliches, authentifiziertes Übergabeprotokoll Kontinuität beweist. Eine vom Agenten gelieferte Gesprächskennung beweist nichts, weil er sie kopieren kann.

Daraus folgt eine Entscheidungsleiter statt einer übergroßen Berechtigung:

1. Ist der Zugangsspeicher entsperrt und verfügbar?
2. Darf dieser neue Agentenprozess während seiner Lebensdauer handeln?
3. Verlangt diese Zugangsdatenquelle bei jeder Nutzung eine Entscheidung?
4. Begrenzt und protokolliert ein vertrauenswürdiger Ausführer die Operation?

Die ersten drei Fragen regeln Befugnis, die vierte Ausführung und Belege. Eine unscharfe Option „vertrauenswürdiger Agent“ erschwert Widerruf und Untersuchung.

Vermittelte Ausführung hält Zugangsdaten aus dem Agentenspeicher

Ein Broker ändert die Schnittstelle von „Gib mir das Token“ zu „Führe diese definierte Aktion aus“. Der Agent liefert eine Anfrage mit nicht geheimen Parametern. Der Broker prüft die Befugnis, holt die Zugangsdaten innerhalb seiner Grenze, fügt sie in das ausgehende Protokoll ein, führt die Operation aus und gibt nur das benötigte Ergebnis zurück.

Für eine HTTP-API könnte die Anfrage so aussehen:

{
  "credential": "staging-release-api",
  "method": "POST",
  "url": "https://api.example.invalid/v1/releases",
  "headers": {"content-type": "application/json"},
  "body": {"commit": "8a31c2e", "channel": "candidate"}
}

Nach der Autorisierung ergänzt der Broker den Bearer-, Basic- oder benutzerdefinierten Authentifizierungs-Header. Die sichtbare Antwort behält Status, ausgewählte Header und Inhalt, lässt aber die eingefügten Zugangsdaten weg:

{
  "status": 201,
  "headers": {"content-type": "application/json"},
  "body": {"release_id": "rel_1042", "state": "queued"}
}

Das ist eine schärfere Grenze als Schwärzung. Schwärzung lässt das Geheimnis erst in einen nicht vertrauenswürdigen Datenweg gelangen und versteckt erkennbare Formen anschließend. Vermittlung verhindert die Offenlegung. Auch Widerruf wirkt: Lehnt der Broker die nächste Anfrage ab, besitzt der Agent kein zwischengespeichertes Token zur Umgehung.

Ausgaben brauchen weiterhin Sorgfalt. Eine API kann Anfrage-Header spiegeln, ein SSH-Befehl Umgebungsdaten ausgeben und ein ausführlicher Client Authentifizierungsmaterial in Fehler schreiben. Bekannte Stellen müssen vor der Rückgabe gefiltert, Diagnosen begrenzt und Fehlerwege ebenso streng geprüft werden. Die Aussage, der Agent erhalte nie Zugangsdaten, muss Fehler und Protokolle einschließen.

Vermitteltes SSH folgt demselben Prinzip und braucht einen protokollkundigen Ausführer. Der Agent verlangt einen Befehl gegen eine benannte Hostidentität. Der Ausführer verwendet den privaten Schlüssel intern, prüft den Host, führt den Befehl aus und liefert stdout, stderr und Endstatus. Eine temporäre private Schlüsseldatei an den Agenten bleibt eine Offenlegung, auch wenn sie später gelöscht wird.

Ein Broker verhindert nicht jede schädliche erlaubte Aktion

Ein verborgenes Token beseitigt eine große Fehlerklasse, macht die angefragte Aktion aber nicht richtig. Ein autorisiertes DELETE kann Daten ohne Zugangsdatenleck löschen. Ein SSH-Befehl kann einen Host bei perfekt geschütztem Schlüssel beschädigen. Der Broker kontrolliert die Ausübung der Befugnis, kann aber aus Syntax keine Geschäftsabsicht ableiten.

Zielkontrolle ist wichtig. Darf der Agent jede URL wählen und fügt der Broker blind Zugangsdaten hinzu, kann das Token an einen Angreifer-Host gelangen. Ein solider HTTP-Ausführer bindet Zugangsdaten an passende Ziele oder stellt anders sicher, dass Authentifizierung nur dort eingesetzt wird. Weiterleitungen brauchen dieselbe Prüfung. Bei SSH gehört die Hostidentitätsprüfung zur Ausführung und darf kein optionales Agenten-Flag sein.

Auch Antwortdaten bleiben sichtbar. Sichere Zugangsdaten können eine Anfrage autorisieren, die Kundendaten, Deployment-Konfiguration oder ein anderes Geheimnis zurückgibt. Der Agent braucht nur die Mindestantwort für seine Aufgabe, doch allgemeine APIs erzwingen das schwer. Vermittlung senkt die Offenlegung von Zugangsdaten, ist aber keine automatische Verhinderung von Datenabfluss.

Prompt-Injection bleibt relevant. Repository-Text, Issue-Kommentare, Build-Ausgabe und geladene Dokumentation können einen Agenten zu einer gültigen, aber unerwünschten Aktion bringen. Menschliche Genehmigung hilft nur bei genügend Details und aufmerksamer Prüfung. Systeme mit hohem Risiko können engere entfernte Berechtigungen, API-Scopes, geschützte Branches, Staging-Umgebungen, Befehlslisten im Ausführer oder eine eigene Workflow-Engine benötigen.

Der beliebte Rat, alle Geheimnisse in Keychain abzulegen und Touch ID zu verlangen, verbindet gute Speicherung mit einer zu breiten Nutzungsentscheidung. Touch ID kann menschliche Anwesenheit bei der Freigabe belegen, verhindert danach aber weder Kopie noch Missbrauch. Biometrie gehört bei empfindlichen Fällen an die Aktionsgrenze, und das Token sollte gar nicht an den Agenten gehen.

Auditbelege müssen Aktionen beschreiben und Änderungen erkennen

Ein brauchbarer Datensatz beantwortet, wer eine Aktion anfragte, welche Prozessinstanz sie stellte, welcher Alias gewählt wurde, welches Ziel und welche Operation benutzt wurden, welche Autorisierung stattfand, wann sie lief und wie sie endete. Die Zugangsdaten selbst gehören nicht hinein. Ein Konsolentranskript erfüllt das selten, weil es Modelltext, Werkzeugmeldungen, Befehle und gekürzte Ausgabe ohne stabiles Ereignismodell mischt.

Sitzungs- und Aufrufereignisse sollten getrennt und verknüpft bleiben. Das Sitzungsjournal zeigt Auftauchen, Identifizierung, Genehmigung, Widerruf und Ende eines Prozesses. Das Aktivitätsjournal zeigt jede HTTP- oder SSH-Operation und ihr Ergebnis. So lassen sich sowohl „War dieser Lauf autorisiert?“ als auch „Was tat er?“ beantworten.

Gewöhnlich verschlüsselte Protokolle schützen Vertraulichkeit im Ruhezustand, beweisen aber keine unveränderte Reihenfolge. Eine Hash-Kette bindet jeden Eintrag an den vorherigen und lässt veränderte, fehlende oder umsortierte Chiffrate erkennen. Sie beweist weder die Erfassung jedes Ereignisses noch verhindert sie die Löschung des gesamten Speichers. Sie liefert Integritätsbelege für die verbliebenen Datensätze.

Ein Prüfkommando sollte einfach und automatisierbar antworten. Sallyport projiziert Sessions und Activity aus einem schreibblinden, verschlüsselten, hashverketteten Auditprotokoll; die Prüfung arbeitet offline über Chiffrat und ohne Entschlüsselungsschlüssel:

sp audit verify

Erfolg sollte die geprüfte Kette melden und Status null liefern, ein defektes Glied einen anderen Status. Die Prüfung gehört in Vorfallserfassung und Backup-Kontrolle, nicht nur in die Oberfläche. Ein grünes Symbol derselben veränderbaren Anwendung ist kein unabhängiger Beleg.

Protokolle brauchen außerdem einen klaren Schwärzungsvertrag. Erfasst werden Aliasse statt Werte. Es muss feststehen, ob Anfrageinhalte und Befehlsausgaben gespeichert, gekürzt, gehasht oder ausgeschlossen werden. Fehlerhafte Anfragen und Transportfehler gehören in Tests, weil Fehlerprotokolle oft mehr Rohkontext enthalten.

Angreifende Tests müssen den ganzen Weg prüfen

Architekturaussagen werden erst durch einen Test greifbar, der sie zu verletzen versucht. Erstelle Wegwerf-Zugangsdaten und einen Testendpunkt und verwende genau die Binärdateien und Prozessgrenzen des normalen Betriebs. Ein Bildschirmfoto eines Dialogs beweist nicht, welche Daten in Speicher oder Nachfahren gelangen.

Ein kompakter Plan deckt die wichtigen Grenzen ab:

1. Starte einen neuen Agentenprozess und bestätige, dass alte Genehmigung nicht übergeht. Erfasse die angezeigte Identität.
2. Fordere einen risikoarmen API-Lesezugriff und dann einen einzeln geschützten Schreibzugriff an. Die Karte muss Ziel und Operation unterscheiden.
3. Suche in sichtbarem stdout, stderr, Umgebung, Transkripten, Werkzeugnutzlasten und Absturzausgaben nach Geheimnis und kodierten Varianten.
4. Widerrufe die Sitzung und versuche es über Elternprozess und bestehendes Kind erneut. Beides muss vor Netzwerk- oder SSH-Ausführung scheitern.
5. Verändere, entferne und sortiere Kopien von Protokolleinträgen um. Die Offline-Prüfung muss jede beschädigte Kette ablehnen.

Zwei oft vergessene Missbrauchsfälle kommen hinzu. Lass den Testendpunkt zu einem anderen Ursprung weiterleiten und prüfe, dass Authentifizierung nicht folgt. Lass ihn alle Header spiegeln und ausführlich fehlschlagen; der Broker muss Zugangsdaten vor der Antwort entfernen.

Für SSH gehören unbekannter und geänderter Hostschlüssel, interaktive Passwortfrage und ein Befehl mit Umgebungsausgabe in den Test. Kläre, wer jede Entscheidung besitzt. Ein zustandsloses Hilfsprogramm darf weder einen zweiten Zugangsdaten-Cache anlegen noch mehr Umgebung erben als nötig.

Erfolgskriterien müssen beobachtbar sein. „Geheimnis geschützt“ ist nicht prüfbar. „Bytefolge und Base64-Form erscheinen nie in agentensichtbaren Dateien, Umgebung, Antworten oder Protokollen“ ist prüfbar. „Widerruf funktioniert“ ist unscharf. „Jeder Aufruf des widerrufenen Prozesses und seiner bestehenden Kinder scheitert vor dem Öffnen eines Sockets“ ist messbar.

Kontrollen richten sich nach der Befugnis des Agenten

Keychain allein kann genügen, wenn eine herkömmliche Anwendung Zugangsdaten mit geringer Wirkung abruft, ihr Codeweg eng ist, der Benutzer jede Operation direkt startet und die Offenlegung zum Bedrohungsmodell passt. Auch in einem stärkeren Entwurf bleibt es eine vernünftige Speicherschicht. Ein reifer verschlüsselter Speicher sollte nicht durch eine selbst gebaute Geheimnisdatei ersetzt werden.

Die Antwort ändert sich, wenn ein autonomes Werkzeug Operationen auswählt, nicht vertrauenswürdigen Projektcode ausführt, beliebige Kinder startet oder unbeaufsichtigt weiterarbeitet. Der Agent sollte Aktionsfähigkeiten statt geheimer Bytes erhalten. Authentifiziere jeden neuen Prozesslauf, nutze Einzelbestätigung für empfindliche Schlüssel, binde Zugangsdaten an Protokolle und Ziele und lass Widerruf künftige Nutzung sofort beenden.

Schreibe vor der Auswahl die stärkste benötigte Aussage auf. Verschlüsselung auf dem Datenträger braucht Speicherkontrolle; Operationen nur durch diesen signierten Prozess brauchen Identität und Sitzung; ein API-Aufruf ohne Tokenausgabe braucht einen Broker; erkennbare Änderungen an verbleibenden Protokollen brauchen Integritätsbelege. Jede Aussage hat einen anderen Test und Besitzer.

Notiere daneben das Restrisiko. Ein Broker macht keine entfernte Schreiboperation rückgängig, eine Sitzung entfernt keine bereits gelieferten Daten, eine Signatur beweist keine harmlosen Anweisungen und eine Hash-Kette beweist nicht die Aufbewahrung des gesamten Speichers. So erhält kein Kontrollmechanismus Anerkennung für fremde Aufgaben.

Die Migration kann schrittweise erfolgen. Beginne mit Deployment-Tokens, Infrastruktur-API-Schlüsseln und SSH-Identitäten für gemeinsam genutzte Systeme. Ersetze deren Leseschnittstelle durch kleine Aktionen, entferne alte Umgebungsvariablen und beweise mit Testdaten, dass alte Wege scheitern.

Auch die Betriebsaufgaben brauchen Besitzer: Tresor entsperren, Prozess genehmigen, Einzelprüfung setzen, Sitzung widerrufen, Fernzugangsdaten rotieren und Auditkette prüfen. Bei auffälligem Verhalten wird zuerst die Sitzung widerrufen, dann das Auditmaterial gesichert und geprüft und schließlich jeder möglicherweise offengelegte Wert rotiert.

Sallyport setzt dieses Modell unter macOS um: Agenten verbinden sich für HTTP- und SSH-Aktionen über den sp mcp-Server, während API- und SSH-Schlüssel im verschlüsselten prozessinternen Tresor bleiben. Die feste Leiter umfasst ein absolutes Tresortor, standardmäßige Autorisierung jedes neuen Agentenprozesses und optionale Genehmigung bei jeder Nutzung eines ausgewählten Schlüssels.

Das ist weder eine allgemeine Policy-Engine noch ein abfangender Netzwerkproxy. Ein enger Broker kann starke Aussagen über die Verwahrung machen, weil er definierte Ausführungswege besitzt. Aktionen außerhalb brauchen eigene Kontrollen, und entfernte Dienste müssen Scopes, Umgebungstrennung und Kontowiderruf weiter durchsetzen.

Die entscheidende Prüffrage ist konkret: Kann der autonome Prozess nach der Genehmigung die Zugangsdaten ausgeben, kopieren oder selbstständig wiederverwenden? Wenn ja, hat Keychain die Speicherung geschützt, aber die Nutzung nicht begrenzt. Nutze Keychain für seine Stärke und verschiebe die Befugnisgrenze zum Ausführer, der die Aktion erledigt und protokolliert.