seekrit vs HashiCorp Vault

Comparison·HashiCorp Vault

HashiCorp Vault is the reference implementation of "a secrets engine": static storage, the broadest dynamic -secrets catalog there is, encryption-as-a-service, and a certificate authority, self-hosted or as HCP Vault Dedicated. We'll take it as given that it works — a huge amount of infrastructure runs on it.

If Vault is breached, what does the attacker get?

Vault's own architecture docs describe a server that, once unsealed, decrypts via its internal "barrier" and serves plaintext through the HTTP API to any caller its ACL policy permits. Getting unsealed means reconstructing a root key — by default split via Shamir's Secret Sharing across a threshold of key-holders, or handed to a cloud KMS or HSM via auto-unseal. The untrusted storage backend holds only ciphertext, but Vault itself holds the keys once running. To HashiCorp's credit, a Vault deployment is normally single-tenant — your own cluster if self-hosted, or a dedicated cluster if you're on HCP Vault Dedicated — so a breach doesn't reach other customers the way a shared multi-tenant service's would. But within that one instance, there's no narrower unit: compromise the running server's memory, or the storage backend plus whatever unseals it, and you have everything behind that barrier, because that's what "unsealed" means. That's the design, not an oversight — Vault's entire value as a secrets engine depends on something being able to decrypt on request.

If seekrit is breached: there's no barrier to get past, because there's no key on our side that opens more than one principal's own grant. Our security model states it at its real strength and no stronger — secrets are encrypted client-side, and the server stores only ciphertext, wrapped keys, and metadata. A full compromise of our database, infrastructure, or staff yields ciphertext and the names of your secrets, not their values. Three honest boundaries: metadata is visible — names, versions, and timestamps aren't encrypted. Third-party sync is the one opt-in exception, scoped per environment, for platforms whose runtime we can't get in front of. And the guarantee covers us being breached, not every way a credential leaks — a leaked passphrase or service token still exposes whatever that principal held, the same as a leaked Vault token would.

This isn't hypothetical. A service holding the ability to decrypt customer-stored values on request has been exactly the failure mode behind recent disclosures elsewhere — Railway's incident described possible access to decrypted customer environment variables, and Northflank told every customer to assume theirs were decrypted. Neither is Vault, and we're not implying it was; both show what happens when the thing protecting a credential is a service that can read it, rather than a design where no service can.

What seekrit's design makes possible — and where Vault's own docs agree with the concern

Because no service holds a broadly-decrypting key, an agent never needs to hold the credential either: the egress proxy substitutes {{seekrit:NAME}} at the network boundary, and the hosted MCP server holds no tool that can return a secret value at all. Worth noting: HashiCorp's own official (beta) Vault MCP Server documentation warns that, depending on the query, the server may expose Vault data — including secrets — to the MCP clients and LLMs talking to it, and says plainly not to use it with untrusted clients or LLMs, on top of discouraging beta features in production generally — an honest acknowledgment of what happens when a secrets engine is reachable by an agent. Agent access policy is signed in the publisher's browser, so the server can serve it without being able to widen it.

Where Vault is the better pick

Dynamic secrets, by a wide margin. Vault's database secrets engine alone covers Cassandra, Couchbase, Elasticsearch, HanaDB, InfluxDB, MongoDB, MongoDB Atlas, MSSQL, MySQL/MariaDB, Oracle, PostgreSQL, Redis, Redis ElastiCache, Redshift, and Snowflake, plus AWS, Azure, GCP, SSH, Kubernetes, RabbitMQ, Nomad, and Consul as their own engines. seekrit's temporary-access covers seven targets.

Transit and PKI are mature, standalone products in their own right. The Transit engine is "encryption as a service" — Vault encrypts and decrypts on request and never stores your data, only the key. The PKI engine issues short-lived certificates on demand. seekrit's managed keys cover encrypt/sign client-side; we have no certificate authority at all.

HA and governance depth for large, regulated deployments. Vault Enterprise and HCP Vault Dedicated add Performance and Disaster Recovery replication, HSM-backed auto-unseal, namespaces, and Sentinel policy. HashiCorp's compliance page lists ISO 27001/27017 and FIPS 140-2/140-3 validation for Vault, and PCI DSS v4.0.1 for HCP Vault Dedicated. seekrit holds none of that yet — see our own trust page.

What running Vault yourself costs

Self-hosting Vault answers "the vendor can read my secrets" by making you the holder of the unseal material and the operator of the barrier — it moves the key to you, it doesn't remove it, and HashiCorp's own docs are specific about what operating it well involves:

• A storage cluster sized for it. The Raft reference architecture recommends five nodes across three availability zones (tolerating two node losses or one AZ loss), sub-8ms inter-AZ latency, and — for a large cluster — 200+ GB of SSD storage per node at 10,000+ IOPS, with audit logs written to a separate disk "for best performance."
• Unseal material you generate and protect, by default Shamir-split across key-holders who must be available to unseal after every restart, or a cloud KMS/HSM dependency via auto-unseal instead.
• Backups and upgrades with real procedure, not just a button. HashiCorp's own guidance says to take a snapshot before any upgrade, because downgrading Vault's storage isn't always possible, and to restore-test in an isolated environment first — a single node is stopped and unsealed on the new binary, an HA cluster is upgraded standby-first, and HashiCorp is explicit that Vault does not support true zero-downtime upgrades.
• Monitoring and load testing you set up, per the reference architecture, and (outside Enterprise) no built-in dead-server cleanup for Raft unless you enable Autopilot yourself.

None of that is HashiCorp overselling the product — their docs are genuinely thorough about what a correct deployment needs, which is exactly why the list is long. Someone on your team owns that cluster, that unseal material, and those upgrade drills, because Vault being able to decrypt on request for your organization is the thing that makes it useful.

seekrit's side of this is nothing to deploy. npx -y @seekrit/cli init --org-name "Acme Storefront" --yes signs up and writes a config file — no cluster to size, no unseal procedure, because the security model means there's no barrier key on our side to protect in the first place. The API runs on Cloudflare's global edge, with no cluster for you to size and no secret material to replicate, and a single org can drive tens of thousands of resolves a day without you provisioning anything for it.

To be fair about the other half: seekrit's own customer-side pieces — the egress proxy, seekrit run, the ESO sidecar, and the provisioner — do run in your environment, same as Vault's agent or CSI provider would. They're small single binaries or containers with no storage cluster behind them, not nothing to operate, just far less.

And since 2023, Vault's core repository ships under the Business Source License, not an OSI-approved open-source one.

Where self-hosting Vault is still the right call: an air-gapped network, a data-residency mandate, a requirement that no third party hold even your ciphertext, or a platform team that already runs this class of infrastructure well. Any one of those settles it in Vault's favor regardless of the rest of this page.

Side by side

When Vault is the right call

• You need dynamic secrets for something on Vault's list and not ours — Cassandra, Snowflake, Consul, Nomad, and more.
• You want encryption-as-a-service or a certificate authority in the same platform.
• You're running at a scale or under a compliance regime where namespaces, Sentinel policy, HSM auto-unseal, or FIPS validation matter.
• You'd rather have a mature, enormously battle-tested product, and are prepared to either run it well or pay HashiCorp to.

When seekrit is the right call

• An AI agent is the one holding the credential, and you want that to be structurally impossible rather than a beta warning label on an MCP server.
• You don't want to run a secrets engine. Vault done well is real infrastructure. seekrit is one thing to point your tools at.
• You want no key anywhere that decrypts more than one principal's own access, not a barrier that opens for anyone holding a valid token.

The bottom line

Vault is the deepest, most capable secrets engine there is, and if your needs are dynamic-secrets breadth, encryption-as-a-service, or governance at scale, it's the right tool. What it isn't is zero-knowledge — by design, it's a service that decrypts on request, for whoever holds a valid token. seekrit is built for the narrower, newer problem of an agent that shouldn't hold the credential at all.

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

Free for one developer, no card, and no barrier key anywhere for an agent — or anyone else — to ask it to open.