Deine Secrets liegen im Schlüsselbund des Systems,
nicht in einem Prompt und nicht in deinem Repo
AgentsRoom speichert API-Keys, Tokens und Datenbank-Passwörter in einem maschinenlokalen Tresor, verschlüsselt über den Schlüsselbund deines Betriebssystems. Du referenzierst sie über ihren Namen, und die App löst sie auf, sobald ein Befehl oder ein Agent startet.
Schluss damit, ein Token in einen Prompt zu kleben, weil es der schnellste Weg war, einen Agenten wieder in Gang zu bringen. Benenne das Secret einmal, nutze überall sonst {{secret:NAME}}, und lass den Wert dort, wo er hingehört.
Wie AgentsRoom ein Secret für deine Befehle nutzbar hält und für den Agenten, der danach fragt, unlesbar.
In jedem Projekt landet am Ende eine Handvoll Werte, die nicht geteilt werden dürfen: ein Zahlungs-Key, ein Datenbank-Passwort, ein Deploy-Token, ein API-Key für die Staging-Umgebung. Sobald KI-Coding-Agenten ins Spiel kommen, beginnen diese Werte, sich auf die denkbar schlechteste Art zu bewegen. Sie werden in einen Prompt geklebt, um einen Agenten wieder in Gang zu bringen, in ein Skript hartkodiert, das der Agent geschrieben hat, oder in einer Datei abgelegt, die drei Commits später mitcommittet wird.
Der Secret Manager von AgentsRoom gibt ihnen einen einzigen Ort. Ein Secret ist ein Name und ein Wert: du legst es einmal an, und AgentsRoom verschlüsselt es über den Schlüsselbund deines Betriebssystems, bevor es überhaupt die Platte berührt. Der ganze Tresor ist eine einzige Datei in deinem Home-Verzeichnis, geschrieben mit Rechten nur für den Eigentümer, und er verlässt nie die Maschine, auf der er entstanden ist.
Von da an fasst du den Wert nie wieder an. Du schreibst {{secret:NAME}} in einen Dev-Befehl oder in die Umgebung eines Agenten, und AgentsRoom setzt den echten Wert ein, sobald dieser Befehl oder dieser Agent startet. Deine Agenten können die Namen auflisten und darum bitten, dass einer eingespeist wird, was für ihre Arbeit reicht, und den Wert selbst bekommen sie nie.
Ein Tresor für eine Maschine voller KI-Agenten
Vom Betriebssystem verschlüsselt, über den Namen referenziert, im letztmöglichen Moment aufgelöst.
Verschlüsselt durch deinen System-Schlüsselbund
Jeder Wert wird über Electron safeStorage verschlüsselt. Das heißt: Der Schlüssel liegt im Schlüsselbund deines Betriebssystems und nicht bei AgentsRoom. Die App speichert Chiffrat und bittet das System um die Entschlüsselung, genau wie die anderen Anwendungen, denen du deine Zugangsdaten schon anvertraust.
Eine Tresordatei, nur für den Eigentümer
Alle deine Secrets liegen in einem einzigen Tresor unter ~/.agentsroom/secrets.json, geschrieben mit Rechten nur für den Eigentümer (0600) und bei jeder Änderung atomar ersetzt. Keine halb geschriebene Datei nach einem Absturz, und kein anderes Benutzerkonto auf der Maschine kann sie öffnen.
Über den Namen referenzieren, nie über den Wert
Ein gespeichertes Secret wird als {{secret:NAME}} verwendet: in der Befehlszeile eines Dev-Terminals, in der Umgebung, die einem Agenten mitgegeben wird, überall dort, wo du sonst die Zugangsdaten getippt hättest. Was du auf dem Bildschirm liest und was du einem Teamkollegen zeigen könntest, ist der Name.
Beim Start aufgelöst, im Hauptprozess
Die Ersetzung passiert, wenn der Prozess startet, innerhalb des Electron-Hauptprozesses. Der aufgelöste Wert geht in die Umgebung des gestarteten Befehls und sonst nirgendwohin: nicht in ein Log, nicht in die Oberfläche, nicht in eine Datei auf der Platte.
Agenten sehen Namen, keine Werte
Ein KI-Agent kann die Namen deiner Secrets auflisten und darum bitten, dass eines in etwas eingespeist wird, das er gleich ausführt. Es gibt keinen Codepfad, der einen Wert an einen Agenten, an die Oberflächenschicht oder über MCP zurückgibt. Der Agent arbeitet mit der Referenz, die App arbeitet mit dem Secret.
Kein Schlüsselbund, keine Speicherung
Kann die Maschine keinen funktionierenden System-Schlüsselbund anbieten, weigert sich AgentsRoom, das Secret zu speichern, statt auf Klartext auszuweichen. Ein Tresor, der still zu einer normalen Datei verkommt, ist schlimmer als gar kein Tresor, deshalb existiert dieser Rückfallpfad schlicht nicht.
Maschinenlokal by Design, nicht per Standardeinstellung
Deine Secrets werden nie an AgentsRoom-Server gesendet. Es gibt keinen Sync-Schalter zu prüfen, keinen Cloud-Tresor, den du abwählen müsstest, und kein Backup deiner Keys irgendwo außer auf deiner eigenen Platte. Der Tresor entsteht auf der Maschine, wird mit einem Schlüssel verschlüsselt, den der Schlüsselbund des Betriebssystems für diese Maschine hält, und bleibt dort. Eine Kopie der Datei allein ist nichts, was eine andere Maschine öffnen könnte.
Die Trennung zwischen ein Secret benutzen und ein Secret lesen ist im Code durchgesetzt, nicht durch eine Anweisung in einem Prompt. Die Oberflächenschicht, die MCP-Werkzeuge und jeder Agent sprechen über Secrets nur mit Namen. Nur der Electron-Hauptprozess macht aus einer Referenz einen Wert: während er die Umgebung eines Prozesses aufbaut, den du starten wolltest, oder, wenn du Live-Daten für HTML-Ansichten in einem Projekt aktiviert hast, wenn er einer Anfrage an einen Endpunkt, den du erlaubt hast, einen Header hinzufügt, den die Seite nie sieht. Einem Agenten zu sagen, er solle vorsichtig mit Zugangsdaten sein, ist eine Hoffnung. Keine Funktion zu haben, die die Zugangsdaten zurückgibt, ist eine Garantie.
Genau das macht es vertretbar, einen Agenten gegen eine kostenpflichtige API oder eine echte Datenbank arbeiten zu lassen. Der Agent weiß, dass ein Secret namens STRIPE_SECRET_KEY existiert, und kann darum bitten, dass es in den Befehl eingespeist wird, den er ausführen will. Er kann es nicht ausgeben, nicht in eine Datei kopieren, die er gerade schreibt, und nicht in eine Konversation lecken, die anderswo gespeichert wird.
Vom eingefügten Token zum benannten Secret
Drei Schritte, und der Wert taucht nie wieder auf.
Das Secret einmal anlegen
Gib ihm einen Namen und füge den Wert ein letztes Mal ein. AgentsRoom verschlüsselt ihn über den System-Schlüsselbund und schreibt ihn in den Tresor unter ~/.agentsroom/secrets.json, nur für den Eigentümer und atomar. Hat die Maschine keinen nutzbaren Schlüsselbund, sagt die App das und weigert sich, statt Klartext zu schreiben.
Es als {{secret:NAME}} referenzieren
Nutze die Referenz überall dort, wo früher der Wert stand: im Befehl, der deinen Dev-Server startet, oder in der Umgebung eines Agenten, der ein API-Token braucht. In deinen Einstellungen liegt die Referenz, und die darf man ruhig ansehen.
AgentsRoom löst es beim Start auf
Wenn der Befehl oder der Agent startet, tauscht der Hauptprozess die Referenz in der Umgebung dieses Prozesses gegen den echten Wert. Dein Tooling bekommt, was es braucht, und der Agent, der es steuert, kannte immer noch nur den Namen.
Wann ein Secret Manager keine Option mehr ist
Die Situationen, in denen aus eingefügten Zugangsdaten ein echter Vorfall wird.
Dev-Server, die echte Keys brauchen
Dein Dev-Server startet nicht ohne Zahlungs-Key und Datenbank-Passwort. Setz {{secret:NAME}} in den Startbefehl statt der Zugangsdaten, und der Befehl wird zu etwas, das du während eines Calls ohne Schrecksekunde auf dem Bildschirm stehen lassen kannst.
Agenten, die eine kostenpflichtige API aufrufen
Ein Agent braucht während der Arbeit ein Token für eine Drittanbieter-API. Füge das Secret über seinen Namen zu seiner Umgebung hinzu: Der Agent bekommt eine funktionierende Umgebung, und das Token steht nicht im Prompt, nicht in der Konversation und nicht in dem, was der Agent als Nächstes schreibt.
Keys, die nicht mehr im Repo landen
Der übliche Unfall sind Zugangsdaten in einer Konfigurationsdatei, die ein späterer Commit einsammelt. Secrets über ihren Namen zu referenzieren heißt: Die im Repository versionierte Datei enthält nur einen Namen, es gibt also nichts zu leaken, wenn der Branch gepusht wird.
Eine Maschine, viele Projekte
Ein einziger Tresor, geschützt durch deinen System-Schlüsselbund und nur von deinem Benutzerkonto lesbar, bedient jedes Projekt, das du öffnest. Jedes Projekt referenziert die Namen, die es braucht, und keines hält seine eigene verstreute Kopie von Zugangsdaten.
Wie kann ein Agent ein Secret nutzen, das er nicht lesen kann?
Weil Zugangsdaten benutzen und Zugangsdaten lesen zwei verschiedene Operationen sind, und AgentsRoom für Agenten nur die erste umsetzt. Der Tresor wird über MCP von genau einem Werkzeug bereitgestellt, secrets_list, und es gibt Namen zurück. Von da an schreibt der Agent {{secret:NAME}} in den Befehl oder die Umgebung, die er braucht, und die Ersetzung übernimmt die App, nicht der Agent.
Was bewusst fehlt, ist die andere Richtung. Kein MCP-Werkzeug gibt einen Secret-Wert zurück, die Oberflächenschicht bekommt nie einen, und nichts rendert ihn in eine Konversation zurück. Aus einer Referenz einen echten Wert zu machen, passiert im Electron-Hauptprozess, in dem Moment, in dem ein Prozess gestartet wird, und das Ergebnis geht in die Umgebung dieses Prozesses und sonst nirgendwohin. Die einzige Ausnahme ist optional und gilt pro Projekt: ein Request-Header für einen Endpunkt, den du für deine HTML-Ansichten erlaubt hast, vom Hauptprozess hinzugefügt und der Seite nie angezeigt.
In der Praxis heißt das: Ein Agent kann deine Testsuite gegen eine echte Datenbank laufen lassen, eine kostenpflichtige API aufrufen oder auf Staging deployen, ohne dass ein einziger Zugangsdatensatz in seinen Kontext gelangt. Hinterher muss nichts geschwärzt werden, weil nie etwas offengelegt wurde.
AgentsRoom MCP entdeckenWo werden meine Secrets gespeichert?
Kann mein KI-Agent meine Secrets lesen?
Werden meine Secrets auf AgentsRoom-Server synchronisiert?
Wie nutze ich ein Secret in einem Befehl?
Was passiert, wenn meine Maschine keinen System-Schlüsselbund hat?
Ersetzt das die Umgebungsdateien in meinem Projekt?
Wenn jemand die Tresordatei kopiert, kann er sie lesen?
Welches MCP-Werkzeug nutzen meine Agenten für Secrets?
Das könnte dir auch gefallen
Datenbankverbindungen
Speichere deine MySQL-, PostgreSQL-, SQL Server-, MongoDB-, SQLite- und Google BigQuery-Verbindungen, erreiche eine Datenbank in einem privaten Subnetz über einen SSH-Tunnel oder eine AWS SSM Session und lass deine KI-Agenten sie über MCP abfragen. Standardmäßig schreibgeschützt, ein Statement pro Aufruf, begrenzte Ergebnismengen, und das Passwort erreicht den Agenten nie. Export, Import und Kopie von Datenbank zu Datenbank für MySQL, PostgreSQL und MongoDB.
SSH-Verbindungen
Speichere deine SSH-Verbindungen, öffne ein integriertes Terminal über SSH und starte Claude Code, Codex oder Antigravity CLI direkt auf deinem Remote-Server oder VPS. Authentifizierung per SSH-Schlüssel oder Passwort, Verbindungsprofile pro Projekt, kein separater SSH-Client nötig.
Dev-Terminals
Terminal-Manager und Prozess-Launcher pro Projekt. Starte Backend, Frontend und Worker mit einem Klick, mit deinen Secrets, die beim Start eingespeist statt eingetippt werden.
AgentsRoom MCP
Der MCP-Server, mit dem deine Agenten AgentsRoom selbst steuern: Projekte, Terminals, Backlog und Verbindungen, samt der Leitplanken, die dazugehören.
Gib deinen Agenten Zugriff, nicht deine Keys
Lade AgentsRoom herunter, verschiebe deine API-Keys und Passwörter in einen Tresor, der durch deinen System-Schlüsselbund verschlüsselt ist, und referenziere sie überall sonst über ihren Namen.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutze Claude, Codex, Antigravity CLI oder einen anderen KI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Agenten, die du wie eine Unterhaltung liest
Jeder Agent hat eine Rolle, ein Gesicht und einen Verlauf, den du wie in einer Messaging-App liest.
