seekrit vs Infisical agent-vault

Comparison·Infisical agent-vault

agent-vault is Infisical's HTTP credential proxy for AI agents: MIT-licensed, self-hosted, and the most visible implementation of credential brokering there is. seekrit ships a proxy that solves the same problem the same way.

So this page is not about whether to broker credentials — you should — but about what you want sitting behind the broker. Every claim below about agent-vault comes from its own repository and documentation, and the section where it wins is not a courtesy.

What's identical

Both products give the agent a placeholder instead of a credential — __anthropic_api_key__ in agent-vault, {{seekrit:ANTHROPIC_API_KEY}} in seekrit — and swap in the real value at the network boundary, on the far side of the process you don't trust. Both terminate TLS to do it, both default to denying a destination you didn't list, and both log the request without the value.

If that's all you need, either one will do it, and you should pick on the questions below rather than on the mechanism.

What seekrit does that agent-vault doesn't

You don't run the vault. agent-vault brokers credentials; it does not relieve you of storing them. Its default is a local encrypted store unlocked by an AGENT_VAULT_MASTER_PASSWORD you set at startup, or you point it at an external store like Infisical. Either way you own backups, key custody, and an availability requirement on the thing every deploy and every agent run blocks on. seekrit's proxy fetches ciphertext from a hosted API and decrypts it in its own process; there is one component in your infrastructure, not two.

The store can't read your secrets — not "doesn't", can't. This is the row that doesn't look like much in a feature list and decides the whole thing. A seekrit secret is encrypted in your browser or CLI, under a key we never receive, before it is uploaded; the API holds ciphertext and no key. Compromise us, subpoena us, or dump our database and you get bytes. agent-vault's answer depends entirely on the store you choose — with the local store it's genuinely nobody but you, which is a strong answer, and with a managed store behind it, that vendor can decrypt.

Rules bound operations, not just destinations. api.github.com is one host and a hundred different authorities. An allowlist that stops at the hostname keeps your key from reaching an attacker's server and does nothing about an agent scoped to read issues that decides to delete a branch. A seekrit rule takes methods and paths alongside the upstream:

[[route]]
prefix = "/github"
upstream = "https://api.github.com"
allow = ["GITHUB_TOKEN"]
methods = ["GET"]
paths = ["/repos/*/*/issues/**"]

That turns the allowlist from anti-theft into anti-misuse. agent-vault documents rules over services and their endpoints; it does not publish the rule schema, so check its current shape against this rather than taking our word for the difference.

Policy survives going from one machine to fifty. A config file on a laptop is the right answer for one agent. For a fleet it becomes a distribution problem, and the usual fix — a control plane that pushes policy — hands the vendor the ability to decide where your credentials may be sent, which is the same authority as reading them. seekrit's signed policy bundles are signed in your browser and verified by each proxy against signers pinned in its own local file. We serve bytes we cannot forge, and publishing requires a user session, so an admin service token can't widen the policy of the agent holding it.

Two proxy shapes. agent-vault documents the forward-proxy model: HTTPS_PROXY plus a CA the workload trusts. seekrit does that too, and also runs as a reverse proxy — point an SDK's base URL at it and there is no certificate to install anywhere. In a container or a CI job where you can't touch the trust store, that's the difference between working and not.

Side by side

Where agent-vault is the better pick

You want to read all of the code. It's MIT and it's on GitHub. Our proxy carries an MIT licence but the vault behind it isn't public, so if your bar is "I can audit and fork the entire path my credentials take," agent-vault clears it and we don't.

You want no vendor at all. agent-vault with its local store involves nobody but you. That is a coherent position and no amount of client-side encryption is the same thing as not having a vendor. If that's your requirement, it's your requirement.

You already run Infisical. It plugs into a store you already operate, including dynamic secrets. Adding a second vendor to broker credentials you're already managing well is a bad trade and we'd tell you the same.

You want the more travelled path. Two thousand stars and a hundred and forty forks is real usage by real people. We're newer, and that should count for something in the direction it obviously counts.

The configuration we'd argue with

Not agent-vault, and not us: agent-vault pointed at a managed store that holds your plaintext.

That setup keeps the credential away from your agent and hands it to a vendor — which is a strange place to stop if the reason you're here is that systems holding credentials eventually leak them. Applied consistently, the argument for brokering is also an argument against a plaintext-holding store behind the broker. Either keep the store local and own it, or put something behind the broker that can't read what it's holding.

The bottom line

Want maximum custody, and prepared to run a secrets store to get it? agent-vault. It's good software aimed at the right problem, and "I run all of it" is a real answer to the trust question, not a consolation prize.

Want the same brokering without operating a vault, and would rather that vault be unable to read your secrets than promise not to? seekrit. You also get operation-level rules, policy you can distribute without handing us authority over it, and the rest of a secrets manager underneath — rotation, temporary database access, audit, Terraform, Kubernetes — instead of two systems to run.

Whatever you keep in seekrit, you can take back out: seekrit archive create writes your whole organization as one signed file, and seekrit archive decryptor writes a standalone HTML page that opens it with no network and no us. See export and break-glass. Export is never gated on your plan.

Our half takes one command:

npx -y @seekrit/cli proxy run --preset openai

Free for one developer, no card. If it doesn't fit, agent-vault is a git clone away, and we would much rather you brokered your credentials somewhere than not at all.