Nº 012/Engineering/5 min read/
Why the Proxy Is Not the Product
The first thing most people say when they encounter AgentSecrets is some version of "oh, it's a proxy."
That framing is understandable. The proxy is the most visible part of the architecture, the component that runs on your machine, intercepts the HTTP request, and injects the credential. When you explain how AgentSecrets works, the proxy is usually the first thing you describe.
But describing a component is not the same as describing the product. A database has a connection pool. Nobody calls PostgreSQL a connection pool tool.
What the proxy actually is
The proxy is the transport mechanism. It is the component responsible for one specific operation: taking a credential name, resolving the value from the OS keychain, injecting it into an outbound HTTP request, and returning the API response. It does that job well and it is architecturally important because of where it sits, between the agent and the network, at the exact point where the zero-knowledge guarantee is enforced.
But it is one component. Credential storage, team access, encryption, the domain allowlist, the audit log schema, the SDK constraints — none of those are proxy decisions. All of them are infrastructure decisions, and the proxy executes within the constraints they set.
Calling AgentSecrets a proxy is like calling a bank a vault. The vault is real and it matters. It is not the product.
What the infrastructure actually is
AgentSecrets is an infrastructure that makes secrets management more secure than it has ever been, for both humans and AI agents.
That sentence covers more than the proxy. It covers the OS keychain storage layer, which means credentials never exist as plaintext files on disk. It covers the zero-knowledge cloud sync, which means the server holds ciphertext it cannot decrypt and a compromised server does not mean compromised credentials. It covers team workspaces, which means developers share access to encrypted secret stores without sharing values. It covers the domain allowlist, which means an agent cannot be redirected to an attacker-controlled destination even under prompt injection. It covers the audit log, which is structured so that a value column does not exist in the schema. It covers the SDK, which has no retrieval method because the infrastructure makes retrieval unnecessary.
Each of those is a decision made at the infrastructure level. Each one addresses a failure mode that exists in current secrets management practice. Together they form something that is genuinely different from what existed before, not a better version of the same approach but a different architecture for the same problem.
Why the distinction matters for developers building on it
When the proxy is the product in someone's mental model, the SDK looks like a convenience wrapper, a nicer way to call the proxy that you might use if you are in Python but could skip if you preferred another approach.
When the infrastructure is the product, the SDK looks like what it actually is: the interface through which developers build tools and agents that inherit the entire security model. The no-get() constraint is not an API design quirk, it is the infrastructure making it structurally impossible to retrieve a credential value into application code. The MockAgentSecrets testing client is not a convenience, it is the infrastructure's guarantee holding even in a test environment where no proxy is running.
A developer who understands AgentSecrets as infrastructure builds differently on top of it than one who understands it as a proxy. They think about the MCP server they are building as something that inherits a security model rather than something that calls a local HTTP server. They think about the audit log as a record of what their agent did under what policy state, not as a log file the proxy writes. They think about the domain allowlist as a security primitive that closes an attack path, not as a configuration option.
That difference in how developers think about what they are building on is the difference between ecosystem adoption and tool adoption, and those two things compound very differently over time.
What this means for the proxy narrative
The proxy narrative is understandable but incomplete. The proxy exists, it works, and the zero-knowledge injection it provides is the mechanism that makes the core guarantee possible.
What the narrative misses is that the guarantee is enforced across the entire architecture. The OS keychain storage, the zero-knowledge cloud sync, the SDK's structural constraints, the audit log schema that has no value field — all of these are part of the same guarantee, not separate features sitting alongside the proxy.
When someone says AgentSecrets is a proxy, they are identifying one layer of a system that was designed to make secrets management secure at every layer. The proxy is the layer they can see most easily. The infrastructure is what they are actually using.
The longer arc
The proxy is the foundation of what exists today. The cloud resolver, when it ships, will extend the same guarantee to serverless environments and CI/CD pipelines where a local proxy cannot run. AgentSecrets Connect will extend it further, to platforms provisioning credential infrastructure for their users without those users ever knowing the infrastructure exists.
At that point the proxy narrative does not just miss the point, it becomes actively misleading. A platform integrating Connect is not integrating a proxy. They are integrating credential infrastructure that handles the entire lifecycle of a user's credentials from provisioning through revocation, zero-knowledge, at scale.
The proxy is where the infrastructure starts. What it is building toward is bigger than any single component.
AgentSecrets is open source and MIT licensed. The full architecture is at agentsecrets.theseventeen.co. The repository is at github.com/The-17/agentsecrets.