# Zugangsdatenaliase für KI-Agenten: sicherere lokale Aktionen

Agenten sollten eine Verbindung über ihren Namen anfordern und nicht die Zugangsdaten erhalten, die diese Verbindung ermöglichen. Das klingt nach einer kleinen Entscheidung beim API-Design. Tatsächlich markiert sie den Unterschied zwischen einem Agenten, der innerhalb einer Grenze handeln kann, und einem Agentenprozess, der eine Tasche voller wiederverwendbarer Geheimnisse mit sich trägt.

Ich habe Teams gesehen, die ein Geheimnis `GITHUB_TOKEN` nannten, es in die Umgebung eines Agenten legten und sich selbst gratulierten, weil die Tool-Schnittstelle ordentlich aussah. Das Token landet trotzdem im Prozessspeicher, im Shell-Verlauf, in Debugausgaben, in Kindprozessen und manchmal in den eigenen Arbeitsnotizen des Agenten. Eine andere Bezeichnung verringert die Offenlegung nicht.

**Zugangsdatenaliase für KI-Agenten** funktionieren, wenn ein vertrauenswürdiger lokaler Executor einen kurzen, verständlichen Verbindungsnamen auflöst und die authentifizierte Anfrage selbst ausführt. Der Agent fragt nach `repo-release-prod`; der Executor fügt die Zugangsdaten erst am Verwendungsort ein. Der Agent erhält einen Statuscode, einen um Geheimnisse bereinigten Antworttext oder eine Befehlsausgabe. Das Geheimnis wird nie Teil der Eingabe oder Ausgabe der Agentenschleife.

Diese Grenze muss sorgfältiger entworfen werden, als es die meisten ersten Versionen vorsehen. Ein Alias kann eine klare operative Schnittstelle, einfache Rotation und nützliche Auditaufzeichnungen bieten. Er kann aber auch zu einem dekorativen Etikett über weitreichender, dauerhafter Befugnis werden, wenn du nicht definierst, was der Name erlaubt, wer ihn aufrufen darf und wie du ihn stoppen kannst.

## Ein Alias bezeichnet eine Berechtigung, keine versteckte Zeichenkette

Ein sinnvoller Zugangsdatenalias bezeichnet eine Dienstverbindung mit einem bestimmten Zweck. Er bezeichnet keine Datenbank mit Geheimnissen, die der Agent durchsuchen kann, und er verspricht nicht, dass jede Anfrage mit diesem Alias akzeptabel ist.

Nehmen wir `payments-prod`. Für einen autonomen Agenten ist dieser Name zu vage. Darf er Rechnungen lesen, Rückerstattungen auslösen, Kontodaten bearbeiten oder Berichte herunterladen? Ein einzelnes Bearer-Token kann technisch vielleicht all das, aber der Alias sollte diese Unterschiede nicht verwischen. Bessere Namen machen den operativen Zweck sichtbar: `payments-invoice-read-prod` und `payments-refund-review-prod` zeigen dem Betreiber, was er gerade autorisieren will, und machen einen Auditdatensatz auch sechs Monate später verständlich.

Drei verschiedene Dinge werden häufig vermischt:

- Eine **Geheimnisreferenz** identifiziert gespeichertes Material, etwa einen Vault-Pfad oder eine Geheimnis-ID.
- Ein **Zugangsdatenalias** identifiziert eine nutzbare authentifizierte Verbindung.
- Ein **Fähigkeitsname** identifiziert eine erlaubte Operation, etwa die Veröffentlichung eines Releases oder das Lesen eines Buildprotokolls.

In einer kleinen Umgebung können diese Begriffe eins zu eins aufeinander abgebildet sein. Sie sollten aber nicht zufällig zu einem einzigen Konzept werden. Eine Geheimnisreferenz kann auf ein Token zeigen, das viele Endpunkte aufrufen darf. Eine Verbindung kann ein Token plus Clientzertifikat benötigen. Eine Fähigkeit kann in verschiedenen Umgebungen unterschiedliche Verbindungen brauchen. Wenn du alles zusammenlegst, werden Rotation, Prüfung und Reaktion auf Vorfälle schwieriger, weil niemand mehr erkennen kann, welcher Teil sich geändert hat.

Ich bevorzuge Aliase, die Zieldienst, Umgebung und Aufgabe enthalten, den Zugangsdaten-Typ aber weglassen. `artifact-publish-prod` ist besser als `artifact-api-token-2`. Der erste Name überlebt eine Umstellung von einem statischen Token auf einen kurzlebigen Austausch. Der zweite verankert ein technisches Detail in jedem Agentenprompt, Toolaufruf, Test und Runbook.

Lass Agenten standardmäßig nicht alle Aliase aufzählen. Eine Liste von Verbindungsnamen verrät oft interne Dienstnamen, Umgebungen und privilegierte Abläufe. Noch wichtiger: Das Aufzählen verwandelt einen eingeschränkten Agenten in einen neugierigen. Gib einer Aufgabe nur die kleine Menge an Namen, die sie benötigt, oder stelle ein auf Operationen ausgerichtetes Tool bereit, das die Verbindung intern auswählt.

## Ein Geheimnis außerhalb des Kontexts muss auf jedem Pfad außerhalb bleiben

Das Token aus dem Hauptprompt des Modells herauszuhalten ist notwendig, reicht aber bei Weitem nicht aus. Ein Zugangsdatengeheimnis entkommt, sobald irgendeine Komponente im erreichbaren Prozessbaum es lesen oder eine andere Komponente dazu bringen kann, es auszugeben.

Betrachte einen typischen Fehlentwurf. Ein Coding-Agent ruft einen lokalen Helfer mit `connection=deploy-prod` auf. Der Helfer sucht ein API-Token nach und startet anschließend einen Kommandozeilen-Client mit diesem Token in einer Umgebungsvariablen. Der Befehl schlägt fehl. Ein Diagnose-Wrapper schreibt seine Umgebung in eine Protokolldatei. Der Agent kann auf das Arbeitsbereichsverzeichnis mit den Protokollen zugreifen und liest das Token, um den Fehler zu erklären.

Niemand wollte das Geheimnis offenlegen. Die Architektur hat es trotzdem getan, weil der Helfer eine Umgebungsvariable für einen privaten Kanal hielt. Das ist sie nicht gegenüber Kindprozessen, Absturzberichten, Diagnosewerkzeugen oder Befehlen, die ihre eigene Umgebung untersuchen können. Zugangsdaten in Befehlsargumenten sind noch problematischer, weil Prozessinspektion und Shell-Verlauf sie offenlegen können.

Der lokale Executor sollte die Zugangsdaten in seinem eigenen geschützten Speicher halten, die authentifizierte Anfrage im Speicher zusammenbauen und bewusst nur ein begrenztes Ergebnis zurückgeben. Bei HTTP fügt er den Authorization-Header selbst ein. Bei SSH wählt er den privaten Schlüssel aus oder ruft einen Helfer auf, der den Schlüssel verwenden kann, ohne dem Agenten den Dateipfad oder den Inhalt des Schlüssels zu übergeben.

Auch der Rückgabepfad verdient genauso viel Aufmerksamkeit. Manche APIs geben bei der Token-Erstellung Zugangsdaten zurück, Webhooks können Authentifizierungsdaten wiederholen, und Fehlerberichte können Anfrage-Header enthalten. Der Executor braucht eine Richtlinie für Antworten, die bekannte Header mit Geheimnissen entfernt und die eigene Anfragekonstruktion nicht zurückspiegelt. Das ist kein Grund, Geschäftsdaten stillschweigend umzuschreiben. Es ist ein Grund festzulegen, welche Teile einer Anfrage und Antwort der Agent sehen darf.

Ein sauberer Test ist hilfreicher als ein Architekturdiagramm. Bitte den Agenten, den Aliaswert abzurufen, Tool-Einstellungen auszugeben, einen Authentifizierungsfehler zu provozieren, laufende Kindprozesse zu untersuchen, falls er das kann, und alle erreichbaren Protokollorte zu lesen. Das erwartete Ergebnis ist langweilig: Er findet einen Namen und die Ergebnisse von Aktionen, aber kein Token, Passwort, keinen privaten Schlüssel und keine wiederverwendbare signierte Anfrage.

## Der Umfang der Verbindung muss zur Aktionsfläche passen

Ein Alias ist nur so eng begrenzt wie die dahinterliegende Berechtigung. Ein perfekt verborgenes Administratortoken bleibt ein Administratortoken.

Bei HTTP-Diensten beginnt der Umfang mit den Berechtigungen des Dienstkontos oder Tokens. Gib einem Release-Agenten die Erlaubnis, ein Release zu erstellen und das erforderliche Artefakt hochzuladen. Hänge nicht zusätzlich Repository-Administration, Organisationsmitgliedschaft, Abrechnungszugriff oder die Identitätsübernahme eines Benutzers an, nur weil das später vielleicht nützlich sein könnte. Ein späterer Bedarf sollte eine eigene Prüfung und normalerweise eine andere Verbindung auslösen.

Wenn das Autorisierungsmodell des Dienstes keine Einschränkung auf bestimmte Endpunkte ausdrücken kann, gehört diese Einschränkung in den Executor. Hier greifen Teams oft zu einer großen Richtliniensprache. Während einer Demo wirkt sie flexibel. Sobald ein Betreiber vorhersagen muss, ob eine unbekannte Anfrage durchgelassen wird, wird sie zum Wartungsproblem. Wenn du Endpunkte einschränken musst, halte die Regeln sichtbar und klein: erlaubte Methode, Host, Pfadfamilie und erwartete Zugangsdaten. Ungewöhnliche Anfrageinhalte und Weiterleitungen sollten bewusst entworfene Fälle sein und keine zufälligen Ausnahmen.

Für SSH gilt dieselbe Disziplin, auch wenn die Kontrollen anders aussehen. Ein Schlüssel, der eine interaktive Shell öffnet, gibt einem Agenten eine sehr große Aktionsfläche. Bevorzuge ein Konto, das die erforderliche Aufgabe in einem begrenzten Verzeichnis ausführen kann, oder einen erzwungenen Befehl, der genau die vorgesehene Operation akzeptiert. Gehe nicht davon aus, dass ein Hostalias in `~/.ssh/config` das Problem löst. Dieser Alias wählt ein Ziel für den Client aus. Er beschränkt nicht, was nach der Authentifizierung geschieht.

Das OpenSSH-Handbuch zu `authorized_keys` dokumentiert Optionen wie `command=`, `no-pty`, `no-port-forwarding` und `restrict`. Das sind praktische Werkzeuge für Maschinenverbindungen. Sie haben aber scharfe Kanten: Ein erzwungener Befehl muss seine Argumente prüfen, und eine Einschränkung, die Portweiterleitung blockiert, macht ein weitreichendes Shell-Konto nicht sicher. Prüfe zuerst die tatsächlichen Berechtigungen des Kontos. Verwende dann SSH-Optionen, um unnötige Pfade zu reduzieren.

Verwende nicht denselben Alias für Staging und Produktion, nur weil sich der Endpunkt in einem URL-Parameter unterscheidet. Auch ein Agent macht unter Druck Fehler. Getrennte Namen erlauben getrennte Zugangsdaten, Genehmigungen und Audit-Erwartungen. Sie verhindern außerdem, dass eine Staging-Aufgabe durch einen Fehler bei der Zeichenkettenersetzung Produktionsberechtigungen erhält.

## Der Executor muss den Aufrufer authentifizieren, bevor er den Alias akzeptiert

Ein Zugangsdatenalias schützt nichts, wenn jeder lokale Prozess ihn aufrufen kann. Der Executor braucht eine klare Antwort auf eine einfache Frage: Welcher Prozess hat diese Aktion angefordert?

Prozess-IDs allein sind keine Identität. Sie sind kurzlebig und können wiederverwendet werden. Ein Prozessname ist noch schwächer, weil ein anderes Programm denselben Namen verwenden kann. Unter macOS liefert die Codesignatur dem Genehmigenden bessere Informationen über die ausführbare Datei hinter einer Anfrage. Sie macht die angeforderte Aktion aber nicht automatisch sicher. Der Betreiber muss weiterhin beurteilen, ob dieser signierte Prozess diese Verbindung in dieser Sitzung erhalten sollte.

Eine sitzungsbezogene Autorisierung funktioniert gut für Agenten, die viele zusammengehörige Aufrufe ausführen. Die erste Anfrage eines neuen Agentenprozesses übermittelt die Identität des Aufrufers und den angeforderten Lauf. Die Genehmigung gilt für diesen Prozess, bis er beendet wird. So muss ein Mensch nicht eine routinemäßige Folge kleiner Aufrufe einzeln genehmigen, während die Grenze zwischen getrennten Läufen erhalten bleibt.

Für manche Aliase sollte bei jeder Verwendung eine Entscheidung getroffen werden. Produktionsbereitstellungen, zerstörerische API-Operationen und der Zugriff auf Kundendaten sind dafür geeignete Kandidaten. Der Genehmigungsdialog sollte Alias, Ziel, Operation und Identität des Aufrufers in verständlicher Sprache anzeigen. Wer Menschen auffordert, ein undurchsichtiges Ereignis zu genehmigen, bringt ihnen bei, einfach durchzuklicken.

RFC 6749 macht eine hilfreiche Trennung, die Entwickler von Agententools beibehalten sollten: Der Autorisierungsserver stellt Zugriffstokens aus, und der Ressourcenserver akzeptiert sie. Der Agent muss keines von beidem sein. In einem lokalen Executor-Entwurf kann der Executor die Komponente sein, die die Zugangsdaten verwahrt oder beschafft und die authentifizierte Anfrage sendet. Der Agent bleibt dann der Anforderer einer eng beschriebenen Aktion. Das ist eine sauberere Trennung, als den Agenten nur deshalb als allgemeinen OAuth-Client zu behandeln, weil er HTTP-Aufrufe ausführen kann.

Das bedeutet nicht, dass jeder Agent interaktive Genehmigungen braucht. Ein kontrollierter Build-Worker kann eine eng begrenzte, vorab genehmigte Verbindung besitzen. Entscheidend ist, ob du den Aufrufer identifizieren kannst und ob seine Berechtigung zu seiner Aufgabe passt. Wenn keine dieser Antworten belastbar ist, hat der Alias lediglich eine lokale Rechteausweitung hinter einer freundlicheren Oberfläche verborgen.

## Bei der Rotation soll sich das Material ändern, nicht der Name

Der praktische Nutzen von Aliasen zeigt sich bei der Rotation. Du ersetzt das Token oder den SSH-Schlüssel hinter `artifact-publish-prod`; der Agent fordert weiterhin denselben Verbindungsnamen an. Kein Prompt, keine Quelldatei und keine Agentenkonfiguration muss das neue Geheimnis erhalten.

Das bedeutet nicht, dass ein Alias ewig bestehen sollte. Halte den Namen nur so lange stabil, wie seine Bedeutung stabil bleibt. Wenn ein Token von Lesezugriff auf Schreibzugriff wechselt, ist der alte Name irreführend. Wenn die Zuständigkeit von einem Team auf ein anderes übergeht, passt die bisherige Genehmigungserwartung möglicherweise nicht mehr. Wenn Zugangsdaten von einem Testmandanten in einen Produktionsmandanten verschoben werden, erstelle einen neuen Alias, auch wenn die API identisch ist.

Der Rotationsablauf sollte beide Seiten der Änderung nachweisen:

1. Lege die Ersatz-Zugangsdaten hinter dem bestehenden Alias ab und führe über den Executor einen eng begrenzten Health-Check aus.
2. Widerrufe oder deaktiviere das alte Material beim Dienstanbieter und wiederhole anschließend die erwartete Agentenaktion.
3. Prüfe den Auditdatensatz auf fehlgeschlagene Wiederholungen oder unerwartete Aufrufer, weil sich veraltete Prozesse nach einer Rotation oft bemerkbar machen.
4. Entferne kopierte Zugangsdaten-Dateien, alte Umgebungseinstellungen und Notfallscripte, die den Executor umgangen haben.

Der letzte Punkt ist der Grund, warum Rotationen in der Praxis scheitern. Jemand erstellt ein temporäres Token, damit ein Release weiterläuft, legt es in einer CI-Variable oder einem lokalen Script ab und vergisst es. Der sauber ausgearbeitete Alias-Weg rotiert problemlos, während der verlassene Umgehungspfad weiterhin funktioniert. Die Rotation ist erst abgeschlossen, wenn du den alternativen Pfad gefunden und geschlossen hast.

Das OWASP Secrets Management Cheat Sheet empfiehlt, Geheimnisse zu rotieren und das Prinzip der geringsten Berechtigung anzuwenden. Beides ist richtig, wird aber meist als Frage der Speicherhygiene dargestellt. Bei Agenten schützt die Rotation auch die Instruktionsschicht. Ein stabiler Alias sorgt dafür, dass der Modellkontext kein wechselndes Geheimnis enthält und keine Aufgabe zum Aktualisieren eines Geheimnisses nötig ist, die in Transkripten, Commitnachrichten oder Toolausgaben auftauchen könnte.

## Auditaufzeichnungen müssen Entscheidungen beschreiben, ohne Geheimnisse zu speichern

Protokolle sollten dir beantworten, wer eine Aktion angefordert hat, welche Verbindung angefordert wurde, was der Executor getan hat und ob die Aktion genehmigt wurde. Sie dürfen niemals zu einer bequemen Kopie des Geheimnistresors werden.

Ein praktischer Ereignisdatensatz enthält Zeitstempel, Sitzungskennung, Identität des Aufrufers, Alias, Kanal, Ziel, Methode oder Befehlsklasse, Autorisierungsentscheidung und Ergebnisklasse. Bei einem HTTP-Aufruf reicht `POST /releases` normalerweise aus, um die Aktion zu erklären. Den vollständigen `Authorization`-Header zu speichern ist nie nützlich und erzeugt ein erhebliches Bereinigungsproblem. Bei SSH solltest du Hostalias, Remote-Konto oder Befehlsklasse und Exit-Status aufzeichnen, nicht den Fingerabdruck eines privaten Schlüssels, wenn dieser sensible Inventarinformationen preisgibt.

Halte den Sitzungsdatensatz und den Datensatz einzelner Aktionen getrennt. Eine Sitzung zeigt, wann ein Agentenlauf begann, welcher lokale Prozess ihn besaß und ob du ihn widerrufen hast. Einzelne Datensätze zeigen, was innerhalb dieses Laufs geschah. Wenn du beides zu einem vagen Aktivitätsfeed zusammenführst, dauert es länger als nötig, einen verdächtigen Lauf zu widerrufen und seine Aktionen zu finden.

Manipulationsnachweise verbessern die Qualität eines Auditprotokolls. Eine nur anhängbare Datei lässt sich von jedem bearbeiten, der die Datei ändern kann. Eine Hashkette macht spätere Änderungen erkennbar, weil jeder Eintrag den Digest des vorherigen Eintrags einbezieht. Sie verhindert keine Löschung und beweist nicht, dass ein bösartiger Executor wahrheitsgemäße Inhalte aufgezeichnet hat. Sie erschwert es aber erheblich, eine heimliche Umschreibung als echte Historie auszugeben.

Ein nützlicher Prüf-Befehl hat absichtlich einen einfachen Vertrag:

```
$ sp audit verify
verified 184 records
chain: valid
first record: 2025-04-03T09:14:22Z
last record:  2025-04-03T16:48:01Z
```

Die genaue Anzahl und die Zeitstempel werden abweichen. Entscheidend ist, dass die Prüfung den gespeicherten verschlüsselten Ereignisstrom liest, die Kette überprüft und eine ungültige Position meldet, wenn jemand einen Datensatz verändert. Eine Offline-Prüfung über Ciphertext ist besonders nützlich, weil ein Ermittler die Kontinuität prüfen kann, ohne den Tresor zu öffnen oder gespeicherte Aktionsdetails offenzulegen.

Verwechsle Manipulationsnachweise nicht mit Überwachung. Du musst verdächtige Aktivitäten weiterhin prüfen, bei Beginn eines Vorfalls Kopien sichern und festlegen, wer Sitzungen widerrufen darf. Kryptografie kann dir sagen, dass sich eine Datensatzfolge geändert hat. Sie kann dir nicht sagen, ob `delete-production-data` eine sinnvolle Anfrage war.

## Genehmigungsmüdigkeit ist ein Zeichen für schlechtes Aliasdesign

Wenn jemand jede harmlose Aktion genehmigen muss, wird er genehmigen, ohne zu lesen. Das ist kein Problem der Menschen. Es ist ein System, das routinemäßige und folgenschwere Berechtigungen nicht unterscheidet.

Verwende eine Sitzungsgenehmigung für einen begrenzten Agentenlauf, dessen erlaubte Verbindungen ein gewöhnliches betriebliches Risiko darstellen. Die Genehmigung sollte die Codesignatur des Prozesses anzeigen, denn ein Label wie `agent` sagt nur wenig aus. Wenn der Prozess endet, sollte der nächste Prozess eine neue Genehmigung benötigen. Das begrenzt einen kopierten Toolaufruf besser als eine einmalige Genehmigung, die unbegrenzt gültig bleibt.

Verwende eine Genehmigung pro Aufruf für Aliase, deren jede Verwendung geprüft werden sollte. Der Executor muss das Ereignis so verständlich darstellen, dass ein Mensch es schnell ablehnen kann. `Use payments-refund-review-prod to submit refund request for order 4821` ist handlungsorientiert. `Tool call requires approval` ist nachlässiges Design.

Sallyport verwendet aus diesem Grund eine feste Entscheidungskette: Ein gesperrter Tresor verweigert jede Aktion, ein neuer Agentenprozess benötigt standardmäßig eine Sitzungsgenehmigung, und einzelne Zugangsdaten können für jede Verwendung eine Genehmigung verlangen. Das System verzichtet auf eine Richtliniensprache, damit lokale Betreiber nicht erst einen Autorisierungsinterpreter debuggen müssen, bevor sie einen Agenten stoppen können.

Mache aus jeder Bestätigung keine Diskussion mit dem Agenten. Eine Genehmigung ist ein Kontrollpunkt, kein Gesprächsprompt. Lehne die Aktion ab, widerrufe die Sitzung, wenn der Lauf vom Kurs abweicht, und prüfe die vorherigen Datensätze. Wenn eine Aufgabe häufige Ausnahmegenehmigungen braucht, überarbeite die Aufgabengrenze oder erstelle eine engere Verbindung mit Berechtigungen, die zur wiederkehrenden Arbeit passen.

## Aliase beheben weder Prompt-Injection noch schlechtes Aufgabendesign

Die Isolierung von Zugangsdaten begrenzt den Schaden durch den Diebstahl von Geheimnissen. Sie entscheidet nicht, ob ein Agent eine API aufrufen, eine Datei hochladen oder einen Remote-Befehl ausführen sollte.

Eine Prompt-Injection in einem Repository-Issue kann einen Agenten auffordern, ein Release zu veröffentlichen, einen Bericht über einen erlaubten Endpunkt abzuziehen oder eine SSH-Verbindung für einen Befehl zu verwenden, der in die weitreichenden Berechtigungen eines Kontos fällt. Der Alias hat seine Aufgabe erfüllt, wenn der Angreifer das Token nie erhalten hat. Der Agent kann trotzdem eine schädliche erlaubte Aktion ausführen.

Darum ist ein weiter Alias selbst dann gefährlich, wenn das Geheimnis nie offengelegt wird. `cloud-admin-prod` gibt einer eingeschleusten Anweisung zu viel Spielraum. `artifact-publish-prod` mit einem eingeschränkten Dienstkonto und einem erwarteten Ziel bietet weniger. Du musst weiterhin begrenzen, welche Dateien der Agent lesen kann, nicht vertrauenswürdige Inhalte von Aktionsanweisungen trennen und bei Aktionen mit größeren Folgen eine Genehmigung verlangen.

Ein weiterer schwacher Entwurf stellt ein allgemeines `http_request`-Tool plus Aliasparameter bereit. Der Agent kann dann eine mächtige Zugangsdatenverbindung auf beliebige Pfade, Hosts nach Weiterleitungen oder Endpunkte richten, die der Betreiber nie berücksichtigt hat. Ein zweckgebundenes Tool wie `create_release` ist weniger flexibel, was oft ein Sicherheitsvorteil ist. Allgemeinheit ist nicht neutral, wenn ein Agent nicht vertrauenswürdigen Text befolgt.

Betrachte jeden Alias als Antwort auf einen Satz, den du aufschreiben kannst: „Dieser identifizierte Prozess darf diese Klasse von Aktionen gegen dieses Ziel mit dieser Genehmigungsbehandlung ausführen.“ Wenn du den Satz nicht ohne Wörter wie „alles“ oder „bei Bedarf“ formulieren kannst, braucht die Verbindung mehr Design, bevor ein Agent sie erhält.

## Ein lokaler Executor sollte langweilig und prüfbar bleiben

Der Executor besitzt mehr Berechtigungen als der Agent und sollte deshalb weniger tun als der Agent. Er braucht verschlüsselte Zugangsdaten-Speicherung, eine kleine Zahl von Aktionskanälen, die Identifizierung des Aufrufers, Entscheidungslogik und Auditaufzeichnungen. Er muss kein Remote-Access-Gateway, kein universeller Proxy und keine eigene Regelsprache mit Hunderten von Ausnahmen werden.

In einer lokalen Entwicklungsumgebung kann eine Menüleisten-App den Zustand des Tresors und offene Genehmigungen sichtbar machen, ohne einen zusätzlichen Hintergrunddienst einzuführen, dessen Existenz Betreiber vergessen. Das ersetzt keine sorgfältige Entwicklung. Es bündelt aber den sensiblen Vorgang an einer Stelle, die sperren, Anfragen ablehnen und eigene Aufzeichnungen führen kann.

Sallyport verwahrt API-Schlüssel und SSH-Schlüssel in einem verschlüsselten lokalen Tresor und führt HTTP- und SSH-Aktionen im Auftrag von MCP-fähigen Agenten aus, statt Zugangsdaten in den Agentenkontext zu übergeben. Der `sp mcp`-Shim stellt dem Agenten eine normale stdio-Verbindung bereit, während die App der Executor bleibt.

Prüfbarkeit bedeutet, dass ein Betreiber grundlegende Fragen beantworten kann, ohne während eines Vorfalls den Quellcode lesen zu müssen: Ist der Tresor gesperrt? Welche Sitzung ist aktiv? Welche Verbindung wurde angefordert? Kann ich diese Sitzung widerrufen? Wurde die aufgezeichnete Abfolge verändert? Wenn die Antwort verlangt, Protokolle aus fünf verschiedenen Komponenten zusammenzuführen, mag das System clever sein. Um zwei Uhr morgens ist es aber nicht beherrschbar.

Halte das Toolprotokoll eng. Gib strukturierte Erfolgs- und Fehlerergebnisse zurück. Vermeide Fehlermeldungen, die interne Anfrageobjekte oder Speicherpfade von Geheimnissen enthalten. Mache die Abbruchfunktion ausdrücklich, damit ein Benutzer eine lang laufende Aktion stoppen kann, ohne unabhängige Arbeit zu beenden. Diese Entscheidungen wirken gewöhnlich. Sie machen den Unterschied zwischen einer betreibbaren Grenze und einer Grenze aus, deren Existenz du lediglich hoffst.

## Teste die Grenze wie ein Angreifer, der Prompts schreiben kann

Eine Demo des erfolgreichen Ablaufs beweist nur, dass der Alias aufgelöst wird. Bevor du dem Entwurf vertraust, teste die Wege, über die ein Agent oder ein kompromittiertes Plugin versuchen würde, aus einem Verbindungsnamen weitergehenden Zugriff zu machen.

Beginne mit einem Alias, der auf ein nicht produktives Dienstkonto zeigt. Führe eine Agentenaufgabe mit dem vorgesehenen Aufruf aus und gib dem Agenten anschließend gegnerische Anweisungen: Er soll Toolschemata untersuchen, Konfigurationsauszüge anfordern, fehlerhafte Anfragen auslösen, Weiterleitungen folgen, Kindbefehle starten und erreichbare Protokolle lesen. Prüfe sowohl sein sichtbares Transkript als auch die Aufzeichnungen des Executors. Du suchst nach Geheimnissen, unerwarteten Zielen und Aufrufen, die die vorgesehene Aktionsgrenze umgehen.

Teste anschließend Fehler bewusst. Sperre den Tresor während einer Anfrage. Widerrufe die Sitzung vor dem zweiten Aufruf. Rotiere die zugrunde liegenden Zugangsdaten. Verändere einen gespeicherten Auditdatensatz in einer Kopie und führe die Prüfung aus. Jeder erwartete Fehler sollte für den Betreiber klar und für einen Angreifer unbrauchbar sein. „Zugriff verweigert, weil der Tresor gesperrt ist“ ist in Ordnung. Ein Stacktrace mit einem Tresordatensatz oder Headerwert nicht.

Teste schließlich den unangenehmen betrieblichen Fall: Ein Agentenlauf erledigt gerade legitime Arbeit, als sein Verhalten verdächtig wird. Kann der Betreiber den Lauf identifizieren, ihn sofort widerrufen, feststellen, welche Aufrufe bereits erfolgreich waren, und prüfen, dass die Datensatzfolge nicht bearbeitet wurde? Wenn dafür eine Schnitzeljagd durch Terminals und Cloud-Dashboards nötig ist, behebe das zuerst, bevor du weitere Aliase hinzufügst.

Eine benannte Verbindung ist eine kleine Schnittstelle mit großen Folgen. Mache ihren Namen ehrlich, ihre Berechtigungen eng, ihren Aufrufer identifizierbar und ihre Aufzeichnungen nützlich. Dann kann der Agent Aktionen anfordern, ohne jemals ein Geheimnis zu erhalten, das sich zu stehlen lohnt.