OneCLI

Open-Source-Credential-Gateway für KI-Agenten: einmal speichern, überall einsetzen, Schlüssel bleiben für den Agenten stets unsichtbar

Agenten-Identifikation 凭证网关

https://onecli.sh/

Website besuchen

Ausführlicher Bericht

OneCLI ist ein Open-Source-Anmeldeinformations-Gateway für KI-Agenten, das im Y Combinator Summer 2026-Batch entwickelt wurde und über 2.800 Sterne auf GitHub hat. Es löst eines der schwierigsten Sicherheitsprobleme im Agentenzeitalter: Der Agent muss externe APIs aufrufen, aber die direkte Übergabe des Schlüssels an den Agenten ist gleichbedeutend damit, das sichere Passwort an die Tür zu kleben. Die Lösung von OneCLI besteht darin, ein transparentes Proxy-Gateway zwischen dem Agenten und dem Zieldienst einzufügen. Die echten Zugangsdaten werden verschlüsselt und im Gateway gespeichert. Der Agent hält nur das Platzhalter-Token und das Gateway schließt die Ersetzung von „gefälschter Schlüssel → echter Schlüssel“ in dem Moment ab, in dem die Anfrage gesendet wird. Zum Zeitpunkt des Schreibens wurde das Projekt mehr als 320.000 Mal heruntergeladen und von NanoClaw als Standard-Anmeldeinformationsstufe ausgewählt.
OneCLI wurde von Guy Ben Aharon und Jonathan Fishner mitbegründet. Der Hintergrund der beiden Gründer liegt im Bereich Sicherheitstechnik: Guy war der erste Ingenieur bei Argon (später von Aqua Security übernommen) und Jonathan arbeitete am Zero-Trust-Netzwerkzugang bei Axis Security (später von HPE übernommen), beide kamen vom israelischen Militärgeheimdienst. Zuvor arbeiteten die beiden gemeinsam am Open-Source-Datenbanktool ChartDB (über 20.000 Sterne auf GitHub). Die Motivation für die Erstellung ergab sich aus persönlicher Erfahrung: Als sie die Agent-Orchestrierungsschicht für ChartDB aufbauten, konnten sie keine sichere Möglichkeit finden, Anmeldeinformationen an autonome Agenten zu verteilen. Teamuntersuchungen ergaben, dass fast alle Teams, die Agenten verwenden, den API-Schlüssel entweder fest in der .env-Datei codiert oder die Agentenlösung improvisiert haben. Im Juli 2026 wurde das Projekt offiziell als Open Source veröffentlicht und erschien auf Hacker News „Show HN“, was schnell die Aufmerksamkeit der Community auf sich zog. Y Combinator bewarb OneCLI am 23. Juli 2026 öffentlich über sein offizielles X-Konto und definierte es als eine Infrastrukturschicht, die „KI-Agenten ermöglicht, echte Arbeit zu erledigen, ohne Passwörter zu speichern“. OneCLI verwendet die Apache-2.0-Lizenz und befindet sich noch in der frühen Phase der schnellen Iteration (v1.42.0+), aber Unternehmen wie Docker, MindsDB, Zoho, Coralogix usw. haben damit begonnen, es zu verwenden.
Der Kernworkflow von OneCLI ist in drei Schritte unterteilt. Im ersten Schritt speichert der Betreiber die echten API-Anmeldeinformationen im verschlüsselten Tresor von OneCLI; Im zweiten Schritt wird jedem Agenten ein Platzhalterschlüssel (z. B. FAKE_KEY) ausgegeben, und der Agent verwendet diese gefälschten Schlüssel, wenn er HTTP-Anfragen stellt. Im dritten Schritt fängt das OneCLI-Gateway die Anfrage ab, schließt die Entschlüsselung und den Ersatz der Anmeldeinformationen ab, bevor die Anfrage das Gateway gemäß den Host- und Pfad-Matching-Regeln verlässt, und leitet schließlich die Anfrage mit den tatsächlichen Anmeldeinformationen an den Zieldienst weiter. Während des gesamten Prozesses kommt der Agent zu keinem Zeitpunkt mit dem echten Schlüssel in Kontakt. Auf dem Technologie-Stack besteht OneCLI aus drei Schichten. Das in Rust geschriebene Hochleistungs-HTTP-Gateway ist für das Abfangen ausgehender Anfragen und das Einschleusen von Anmeldeinformationen verantwortlich. Der Agent überträgt das Zugriffstoken über den Proxy-Authorization-Header, um die Identitätsauthentifizierung abzuschließen. Das von Next.js erstellte Web-Dashboard wird zur Verwaltung von Agenten, Schlüsseln und Berechtigungen verwendet. Das Gateway analysiert dynamisch, welche Anmeldeinformationen für jede Anfrage über die vom Dashboard bereitgestellte API eingefügt werden sollen. Die Anmeldeinformationsspeicherebene verwendet die AES-256-GCM-Verschlüsselung. Der Schlüssel wird erst entschlüsselt, wenn eine Anfrage erfolgt. Nach der Entschlüsselung wird es streng anhand der Host- und Pfadmuster abgeglichen und dann in Form von Anforderungsheadern oder URL-Parametern eingefügt. Die Bereitstellung ist äußerst einfach und kann mit nur einem Befehl gestartet werden: docker run -d --name onecli -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli Besuchen Sie nach dem Start http://localhost:10254, um einen Agenten zu erstellen, fügen Sie einen Schlüssel hinzu und verweisen Sie dann den HTTP-Proxy des Agenten auf localhost:10255. Das Agent-Framework erfordert keine Codeänderung – es kann darauf zugegriffen werden, solange es das Setzen der Umgebungsvariablen HTTPS_PROXY unterstützt. Dazu gehören Claude Code, Codex, Cursor, Cline und Mainstream-Frameworks wie OpenClaw, NanoClaw, LangChain und CrewAI. OneCLI bietet außerdem das Befehlszeilentool onecli CLI, mit dem Agenten ihre eigenen Identitäten und Schlüssel über Shell-Befehle autonom verwalten können. Der Agent Orchestrator kann neue Agenten erstellen, Anmeldeinformationen zuweisen und Regeln in einem Skript konfigurieren, ohne das Dashboard manuell bedienen zu müssen.Der lokale Modus unterstützt den anmeldungsfreien Einzelbenutzerbetrieb ohne Konfiguration von NEXTAUTH_SECRET. Team Collaboration kann die Google OAuth-Authentifizierung aktivieren. Alle Umgebungsvariablen verfügen über sinnvolle Standardwerte, die automatisch generiert werden, wenn SECRET_ENCRYPTION_KEY nicht festgelegt ist.
OneCLI ist derzeit völlig kostenlos und Open Source (Apache-2.0). Das kostenlose Kontingent unterstützt bis zu 2 Agenten und es ist keine Kreditkarte erforderlich. Das Projektteam ist derzeit ein von Y Combinator gegründetes Startup-Unternehmen und hat noch keinen konkreten Preisplan für die offizielle kommerzielle Version bekannt gegeben. Zu den vorhersehbaren Geschäftspfaden gehören Multi-Agent-Unterstützung für Unternehmenseditionen, erweiterte Richtlinien-Engines, unternehmensweite Integration von Identitätsanbietern und verwaltete Cloud-Dienste.
Die allgemeine Reaktion der Community auf OneCLI war positiv, insbesondere innerhalb der Agent-Sicherheits-Community. Einige Entwickler im Hacker News-Diskussionsthread wiesen darauf hin, dass Lösungen wie Credential Agent-Lösungen nicht neu sind (wie der Tokenizer von Fly.io, der BuzzFeed SSO-Agent usw.), aber auf AI Agent-Szenarien zugeschnittene Implementierungen haben tatsächlich die Schwelle für die Implementierung gesenkt. Einige Entwickler teilten auch Pläne mit, HashiCorp Vault mit Skripten zu verwenden, um ähnliche Effekte zu erzielen, gaben jedoch zu, dass die „out-of-the-box“-Erfahrung von OneCLI besser ist. Das vom offiziellen Konto von Y Combinator beworbene Demovideo zeigt den gesamten Prozess, bei dem Claude Code die GitHub-API über das OneCLI-Gateway aufruft – der Agent hält während des gesamten Prozesses nur FAKE_KEY und der echte PAT wird vom Gateway in dem Moment eingefügt, in dem die Anfrage gestellt wird. Die Bewertungen aus der chinesischen Community sind überwiegend konstruktiv. Einige Entwickler im Blogpark haben tatsächliche Tests mit OneCLI durchgeführt und glauben, dass die „Transformationskosten nahe Null“ liegen. Bei Teams, die bereits Agenten in der Produktionsumgebung ausführen, muss jedoch besonderes Augenmerk auf die HTTPS-Zertifikatsverwaltung und die Netzwerkisolation des Gateways gelegt werden. Andere bemerkten, dass eine zentralisierte Verwaltung von Anmeldeinformationen auch ein zentralisiertes Risiko mit sich bringt – wenn der OneCLI-Server kompromittiert wird, hat der Angreifer ein äußerst wertvolles Ziel.
OneCLI hat von mehreren maßgeblichen Quellen positive Presse erhalten. Die öffentliche Werbung von Y Combinator wird als Signal an die Branche gewertet, dass der Accelerator davon überzeugt ist, dass die Agentensicherheitsinfrastruktur ein unabhängiger Bereich ist, der Aufmerksamkeit verdient. Die Agent Times, World AI 360 und andere Medien haben darüber berichtet, und es wird allgemein angenommen, dass das Designmuster von OneCLI – die Isolierung von Anmeldeinformationen außerhalb des Agentenspeichers – voraussichtlich eine Standardsicherheitsschicht für die Agentenarchitektur werden wird. Aus der Perspektive der wettbewerbsorientierten Produktlandschaft besteht die Hauptkonkurrenz für OneCLI aus zwei Arten von Lösungen. Ein Typ sind herkömmliche Schlüsselverwaltungstools (HashiCorp Vault, AWS Secrets Manager, 1Password). Diese Tools lösen das Speicherproblem, aber nicht das Injektionsproblem – es besteht immer noch die Gefahr eines Lecks, nachdem der Agent den Schlüssel erhalten hat. Der andere Typ ist das neu entstehende Agent-Framework (z. B. das MCP-Protokoll), aber die MCP-Tool-Definition verbraucht das Kontextfenster des Agenten und jeder MCP-Server handhabt die Authentifizierung unabhängig, sodass eine einheitliche Verwaltung der Anmeldeinformationen fehlt. Die differenzierte Positionierung von OneCLI besteht darin, eine Leerstelle zwischen diesen beiden Lösungstypen zu finden: Lösung von Speicherung und Injektion, ohne das Kontextfenster des Agenten zu belegen.
OneCLI ist nicht ohne Risiken. Das Kernproblem liegt im MITM-CA-Modell: Das Gateway muss über den CA-Schlüssel verfügen, um Zertifikate für beliebige Ziele auszustellen. Dies bedeutet, dass auf einem gemeinsam genutzten oder mandantenfähigen Computer eine Schwachstelle bei der Rechteausweitung den CA-Schlüssel offenlegen kann. Die Bereitstellung erfordert besondere Sorgfalt bei der Isolierung von Docker-Containern und Netzwerk-Namespaces. Obwohl das Projekt schnell iteriert und die Community schnell wächst, befindet es sich noch im v1.x-Stadium und die API und das Konfigurationsformat können sich bei Versions-Upgrades ändern. Für Unternehmen, die langfristige Stabilitätsgarantien benötigen, wird empfohlen, OneCLI als auswertbare Lösung für die Prototypenverifizierung zu verwenden und gleichzeitig die traditionelle Verwaltung von Anmeldeinformationen als Fallback-Lösung beizubehalten. Ein weiteres Problem, das nicht ignoriert werden darf, ist das zentralisierte Vertrauen. Die Zentralisierung von Anmeldeinformationen in einer Gateway-Verwaltung verbessert die Betriebs- und Wartungseffizienz, bedeutet aber auch, dass das Gateway selbst zu einem einzigen Angriffspunkt wird. Betreiber müssen eine zusätzliche Härtung des Gateways durchführen, einschließlich, aber nicht beschränkt auf: Beschränkung der Dashboard-Zugriffs-IPs, Aktivierung der externen Speicherung von Prüfprotokollen und regelmäßig wechselnde Verschlüsselungsschlüssel.
OneCLI eignet sich am besten für beide Arten von Teams. Die erste Kategorie sind Entwicklungs- und Betriebsteams, die Codierungsagenten (Claude Code, Codex, Cursor) ausführen. Diese Agenten müssen häufig externe APIs wie GitHub, Slack, Jira usw. aufrufen, und jede Ausgabezeile kann Schlüssel enthalten. Die zweite Kategorie ist ein Team, das ein Multi-Agent-Kollaborationssystem aufbaut, das den API-Zugriff aller Agents einheitlich verwalten und prüfen muss. Zu den nicht geeigneten Szenarien gehören: Agenten, die nur in vollständig isolierten Netzwerken ausgeführt werden, Teams, die bereits über ausgereifte HashiCorp Vault-Bereitstellungen verfügen und nicht bereit sind, zusätzliche Infrastruktur hinzuzufügen, und Benchmark-Unternehmen, die strenge Compliance-Audits erfordern (z. B. SOC 2 Typ II). Für Letzteres wird empfohlen, zu warten, bis OneCLI eine Sicherheitsüberprüfung durch einen Drittanbieter abgeschlossen hat, bevor eine Bereitstellung auf Produktionsebene in Betracht gezogen wird.
OneCLI trifft genau einen echten Schwachpunkt bei der Popularisierung von KI-Agenten – die Sicherheit von Anmeldeinformationen – und bietet eine technisch elegante und praktische Lösung. Sein Kernurteil lautet: „Der Agent sollte nicht einmal die Taste berühren“ und setzt dieses Prinzip auf architektonischer Ebene um. Während der kritischen Übergangsphase von Agenten vom Spielzeug zur Produktivität wird erwartet, dass OneCLI zum Sicherheitsstandard für die Agenten-Infrastruktur wird. Der wahre Wert kann jedoch erst vollständig verifiziert werden, wenn eine Prüfung durch Dritte abgeschlossen ist und die stabile Version 2.0 veröffentlicht wird.

Nutzerbewertungen

2hyqkek

—

Habe OneCLI ausprobiert, und das Schlüsselverwaltungsproblem von Claude Code ist damit komplett gelöst. Früher musste ich ständig diverse API-Keys in die .env stopfen; jetzt läuft alles mit einem Docker-Befehl, und der Agent kennt die echten Schlüssel gar nicht. Das Sicherheitsgefühl steigt enorm.

珊瑚37

—

Manche vergleichen es mit HashiCorp Vault, aber ich finde, die Positionierung ist eine andere. Vault ist zu schwergewichtig; für ein kleines Team in der Agent-Entwicklung ist OneCLIs Ein-Klick-Deployment wirklich entspannt.

RGonzales_Plus

—

Ein in Rust geschriebenes HTTP-Gateway, die Performance ist wirklich stabil. Ich habe die Latenz gemessen: Mit dem OneCLI-Proxy ist praktisch kein zusätzlicher Overhead spürbar – viel schneller, als bei jedem Aufruf den Schlüssel aus Vault zu holen.

王月珍

—

Habe gesehen, dass der offizielle YC-Account OneCLI empfiehlt, und mich eingelesen. Der Ansatz ist wirklich gut: Es geht nicht darum, dem Agent API-Aufrufe zu verbieten, sondern darum, dass der Agent die Schlüssel gar nicht erst anfassen sollte. Diese Designphilosophie unterschreibe ich.

FrankHicksIII

—

Auf Hacker News fragte jemand, ob das nicht einfach ein Auth-Proxy sei — ähnliche Lösungen gab es tatsächlich schon früher. Aber es ist speziell für Agent-Szenarien optimiert und sofort einsatzbereit, und das reicht.

AnnGray

—

Das Deployment ist simpel: Eine Zeile docker run und es läuft. Aber es gibt eine Falle: Man muss sich selbst um das Problem mit dem selbstsignierten Zertifikat kümmern – vertraut der Agent-Container dem CA-Zertifikat nicht, kommt der HTTPS-Verkehr nicht durch.

流年472

—

Der Ansatz von OneCLI erinnert mich an einen realen Fall, den ich gelesen habe: Der Sicherheitschef eines Großkonzerns autorisierte einen Agent, der daraufhin wie wild E-Mails löschte. Hätte es damals eine Gateway-Policy-Schicht gegeben, wären vielleicht nur ein paar statt aller E-Mails gelöscht worden.

8j0wz

—

Habe OneCLI zusammen mit NanoClaw ausprobiert — ein butterweiches Erlebnis. Der Agent weiß gar nicht, dass die Schlüssel existieren, ein Leak ist schlicht unmöglich. Für sicherheitsbewusste Teams ist diese Kombination einen Versuch wert.

HaroldStephensIII

—

Habe OneCLI bereits in meinen Cursor-Workflow integriert und die APIs von GitHub, OpenAI und Slack konfiguriert. Der Einrichtungsprozess ist intuitiv: Das Web-Panel verwaltet Agents und Schlüssel, die Berechtigungsgranularität ist fein genug.

AshleyOrtiz

—

Mein einziges Bedenken ist das Zentralisierungsrisiko. Alle Schlüssel laufen über das OneCLI-Gateway — wird es kompromittiert, ist alles verloren. Der verschlüsselte Speicher ist gut umgesetzt, aber beim Single Point of Failure in der Produktion bleibe ich etwas skeptisch.

康明_1

—

Habe mehrere Credential-Management-Tools verglichen: OneCLI ist für Einzelentwickler am freundlichsten. Authsome kommt ohne Infrastruktur aus, hat aber kein Auditing; Vault ist zu schwergewichtig. OneCLI trifft genau die goldene Mitte.

Isabella.Morgan

—

Die Anbindung an Bitwarden ist ein echtes Plus: Die Schlüssel müssen nicht in der lokalen Datenbank von OneCLI liegen, sondern werden direkt aus Bitwarden gezogen. Für Teams, die bereits einen Passwortmanager nutzen, sind die Migrationskosten sehr gering.

KeithStewartJr

—

Habe mir den Code angesehen: Die Rust-Gateway-Schicht ist solide geschrieben. AES-256-GCM-Verschlüsselung im Ruhezustand, entschlüsselt wird erst zur Anfragezeit — kein offensichtlicher Schwachpunkt im Design. Ich hoffe auf baldige Freigabe-Workflows und Monitoring-Regeln.

Jacqueline.Adams

—

OneCLI kann zwar das Leaken von Schlüsseln verhindern, aber nicht, dass ein autorisierter Agent Unfug treibt. Hat der Agent die Berechtigung für die Stripe-API, kann er beliebig abbuchen. Dieses Problem braucht noch Freigabe-Workflows — ein Gateway allein reicht nicht.

Laura_MooreIII

—

Verfolge es seit Show HN, inzwischen über 2800 Stars — das Wachstum ist wirklich schnell. Das zeigt, dass dieser Schmerzpunkt viele Leute trifft. Apache-2.0-Lizenz plus YC-Rückendeckung: einen Blick wert.

7wnel5q

—

Nach dem Deployment von OneCLI gab es einen unerwarteten Bonus: Die Audit-Logs sind großartig. Früher war völlig unsichtbar, welche APIs der Agent wann aufgerufen hat; jetzt ist alles auf einen Blick erkennbar, die Fehlersuche ist viel effizienter.

EHughesIII

—

Die Architektur aus Gateway + Dashboard + verschlüsseltem Speicher ist sehr klar. Die Performance des Rust-Gateways ist kein Problem, und das Next.js-Panel bedient sich angenehm. Nur die Dokumentation ist stellenweise zu knapp — Neulinge müssen wohl etwas herumprobieren.

smallpeacock198

—

Bin dem Praxisbericht auf Cnblogs Schritt für Schritt gefolgt, das lokale Deployment dauerte keine zehn Minuten. Mit Claude Code die GitHub-API aufgerufen — durchgehend nur FAKE_KEY zu sehen. Diese transparente Ersetzung fühlt sich wirklich nach Hightech an.

Brian.Martinez168

—

Für jemanden wie mich, der AI Agents entwickelt, löst OneCLI das nervigste Problem: Vor jeder Demo musste ich prüfen, ob die .env-Datei versehentlich committet wurde. Darum muss ich mir jetzt keine Sorgen mehr machen.

Web_3Wave

—

Es befindet sich noch in der 1.x-Phase, die API kann sich also häufig ändern. Für den Produktiveinsatz empfehle ich, die Version festzupinnen, sonst wird es mühsam, wenn sich das Konfigurationsformat nach einem Upgrade ändert.

purplepanda996

—

Habe OneCLI in das Multi-Agent-System unseres Teams eingebunden, drei Projekte isolieren jeweils ihre Schlüssel und Richtlinien. Dieses projektbezogene Isolationsdesign ist sehr praktisch — die Daten verschiedener Kunden vermischen sich nicht.

许桂强

—

Ich will nur wissen, wann die 1Password-Integration kommt. Nur Bitwarden zu haben ist etwas einschränkend. In meinem Team nutzen viele 1Password, hoffentlich wird das ergänzt.

DianeMitchell_Plus60

—

Mit einem einzigen Docker-Befehl stand alles, wirklich praktisch. Allerdings habe ich einen Node.js-Agent getestet: Die Umgebungsvariable HTTP_PROXY wird von älteren Node-Versionen schlecht unterstützt, man braucht 22+.

LoganRodriguez_20234

—

Daumen hoch. Ich hatte zuvor ein Experiment gemacht: Ein gewöhnlicher Prompt-Injection-Angriff konnte den OpenAI-Key aus den Umgebungsvariablen herauslocken. Nach der Einführung von OneCLI habe ich denselben Angriff erneut versucht — der Agent hat den Key schlicht nicht in der Hand, da kann nichts leaken.

OMpow

—

Das Design der Policy-Engine ist gelungen: Für jeden Agent lassen sich eigene Allow/Block-Regeln und Ratenlimits konfigurieren. Das geht deutlich tiefer als simples Schlüsselmanagement — im Grunde Berechtigungskontrolle auf der Netzwerkebene.

云烟737

—

Die PostgreSQL-Abhängigkeit ist eine Hürde. Als Einzelentwickler extra eine Datenbank zu installieren, nur um es laufen zu lassen, ist etwas übertrieben. Zum Glück soll es eine eingebettete PGlite-Version geben, dann braucht man keine separate Datenbank. Ich freue mich auf die offizielle Unterstützung.

AfraRomkes

—

Habe mit dem DevOps unseres Teams gesprochen. Er meint, der MITM-Proxy-Ansatz von OneCLI berge Compliance-Risiken für regulierte IT-Umgebungen in China. Selbstsignierte Zertifikate werden bei Schutzstufen-Audits nicht unbedingt anerkannt — diesen Punkt sollte man im Auge behalten.

WLopezX736

—

Der Analyseartikel von The Agent Times ist gut geschrieben und trifft den Kern: OneCLI löst das Problem geleakter Schlüssel, aber nicht den Missbrauch von Berechtigungen durch Agents. Trotzdem überwiegen die Stärken — immerhin wurde zuerst das kritischste Problem gelöst.

goldendog167

—

Habe ein Issue zur Frage der Freigabe-Workflows eröffnet, der Entwickler hat sehr schnell geantwortet und gesagt, es stehe bereits auf der Roadmap. Ein von Y Combinator unterstütztes Projekt — das Iterationstempo dürfte nicht langsam sein.

星辰_14

—

Nachdem ich den von karpathy retweeteten Standpunkt zu CLI und Agents gelesen habe, passt das Design von OneCLI wirklich dazu. Die CLI ist die native Schnittstelle für Agents, und Credential-Management auf der CLI-Ebene ist grundlegender und universeller als auf der Anwendungsebene.