AgentSecrets did not start as a Go project. It started as a question about what secretscli could become.

secretscli was a Python tool we built for managing secrets in developer workflows. Simple, intentional, no proxy, no agent integration — just the cleanest secrets management interface we could build for a developer who wanted something that stayed out of the way. It still exists on PyPI, though we are not actively maintaining it anymore because what we learned while thinking about its future led somewhere else entirely.

The question that changed the direction

At some point we started thinking about how to extend secretscli. Whether it could become a Claude Code skill, whether there was a more interesting problem underneath it. That thinking led to research, and the research led to a specific realisation: there was no secrets infrastructure for AI agents that actually addressed the agent threat model, and the gap was not in quality but in existence.

Around the same time we came across reporting on the OpenClaw attack. The details of that incident made the problem concrete in a way that pure research does not. Prompt injection as a vector for credential exfiltration was not theoretical. It was happening, and the reason it worked was architectural — agents were holding credential values they should never have held.

That is when AgentSecrets became a different product entirely, not an extension of secretscli but a ground-up answer to a problem secretscli was never designed to solve.

Why the proxy changed everything about the distribution question

secretscli is a Python library. Installing it is pip install secretscli. That model works fine for a developer tool that lives in a Python environment.

AgentSecrets has a local proxy. The proxy needs to run as a persistent background process, respond to requests from any language or framework, inject credentials at the transport layer, and manage a local OS keychain. That is a different kind of software than a Python library, and it has different distribution requirements.

A Python proxy is possible, but it comes with friction. The developer needs Python installed at the right version, with the right dependencies, and they need to manage the process themselves or write a wrapper around it. For a security tool that needs to be trusted, "it works if your Python environment is set up correctly" is not a strong foundation.

A compiled binary changes the picture — one file, no runtime dependency, distributable via Homebrew or a direct download. The developer installs it and it works. That reliability matters more for infrastructure than it does for application code.

Go or Rust

Once we decided to write a compiled binary, the real decision was Go or Rust.

Rust produces faster binaries and gives more control over memory. For a proxy that handles sensitive data transiently, that level of control is appealing. But Rust has a significantly steeper learning curve and a longer build cycle, and we were a small team moving fast on a product that needed to ship and iterate.

Go compiled binaries are nearly as performant as Rust for the kind of work the AgentSecrets proxy does — network I/O, keychain reads, HTTP request manipulation. The concurrency model is well suited to a proxy handling multiple simultaneous requests. The toolchain is fast and the language is simple enough that the codebase stays readable as it grows.

The decision was not Go over Rust because Rust is worse. It was Go over Rust because the performance difference did not justify the development overhead at this stage, and because Go's distribution story — single static binaries with no external dependencies — was exactly what we needed.

What Go gave us that mattered

Cross-platform keychain access was one of the first things we had to think about carefully. macOS Keychain, Linux Secret Service, Windows Credential Manager are three completely different systems with different APIs. Go's ecosystem has solid libraries for all three, and the abstraction layer we ended up with is clean enough that the proxy code does not need to know which operating system it is running on.

Process lifecycle was the other one. The proxy needs to start, stay running, respond to signals, and clean up gracefully when it stops. Go handles this well out of the box, and the tooling around building long-lived processes in Go is mature.

The CLI benefits from the same distribution story as the proxy. Both brew install and go install work, the binary is self-contained, and a developer who has never heard of Go can install AgentSecrets without knowing or caring what it is written in.

Why the SDK stayed Python

The CLI and proxy are Go. The SDK is Python, and that was a deliberate decision.

Python is where most AI agent development is happening right now. LangChain, CrewAI, AutoGen, most of the MCP ecosystem that is not running in Claude Desktop directly — Python. If the SDK is not Python, we are asking a large portion of the target audience to cross a language boundary before they can use it.

The Go and JavaScript SDKs are on the roadmap. The Python SDK came first because it reaches the widest audience of developers building agents today, and reaching that audience quickly was more important than covering every language at launch.

secretscli and AgentSecrets are not the same product

It is worth being clear about this because the naming history can make it seem like one led to the other in a linear way.

secretscli is a simple secrets management tool for developers, with no proxy and no agent integration. It is good at what it does and it still works.

AgentSecrets is infrastructure for AI agent credential management. It has a proxy, a zero-knowledge cloud sync layer, team workspaces, an SDK with no retrieval method, MCP integration, an exec provider, and a domain allowlist. It also works for manual developer workflows, and it is better than secretscli for those too because it does more.

The thread between them is the question that started the research: what would secrets management look like if it was built for the way AI agents actually work. secretscli was not the wrong answer to that question. It was the answer to a different question, and asking the right question required understanding the agent threat model first.

AgentSecrets is open source and MIT licensed. The full architecture is at agentsecrets.theseventeen.co. The repository is at github.com/The-17/agentsecrets. secretscli is still available at github.com/The-17/secretscli.