Skip to content

Secrets Bridge

Unified secrets control plane

SecretsBridge

The control plane for secrets governance.

Keep secrets in Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, or Kubernetes. Secrets Bridge governs who can request, approve, reveal, patch, and audit access, without storing plaintext secrets in the control plane.

Try it locally Read the architecture Star on GitHub

What is Secrets Bridge?

Secrets Bridge is a unified secrets control plane for governing secrets across external providers without storing secret values in the control plane.

It does not replace HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, or Kubernetes External Secrets. It governs access, workflows, approvals, audit, and agent execution around them. The values stay in your provider.

See what's live, QA-certified, and on the roadmap

Why Secrets Bridge

  •  Workflow-gated reads & writes

    Developers request access through configurable workflows. Approvers vote. Agents fetch (or write) values. Every value is single-shot, audited, and KMS-wrapped at rest.

  •  SOC2-ready audit

    The audit_events table is append-only at the schema layer: BEFORE UPDATE / BEFORE DELETE triggers reject mutations. Every action emits a correlation ID you can drill into.

  •  No KMS lock-in

    Three backends ship today behind one SB_KMS_BACKEND knob: local (dev), vault-transit (OSS production), aws-kms (AWS production). Bring your own. No cloud lock-in.

  •  Plaintext never on the wire

    TLS + per-direction wire-envelope encryption (X25519 for CP→Agent, KMS-DEK + AES-GCM for Agent→CP). Even a TLS-terminating proxy in your mesh sees only ciphertext.

Who this is for

  • Regulated teams (fintech, healthtech, defence-adjacent) where "everyone has full Vault read access" is no longer an answer your auditor will accept.
  • Platform teams standing up multi-cluster / multi-account secrets governance from scratch.
  • Compliance engineers who need a real audit trail (correlation IDs, immutable rows, value-free metadata) without reaching for an SIEM bolt-on.

How it's different

Secrets Bridge Direct Vault AWS Secrets Manager + IAM Most "secrets SaaS"
Multi-provider ✅ Vault + AWS today; Azure + GCP on roadmap Vault only AWS only Varies
Workflow approval per read ✅ Built-in Plugin / RFC ❌ Some
Single-shot reveal-once UX ✅ Built-in ❌ ❌ Some
Append-only audit at schema ✅ Postgres triggers ❌ application-layer CloudTrail (not append-only) Varies
Self-hostable ✅ OSS, no SaaS dependency ✅ n/a ❌
KMS choice ✅ Vault Transit / AWS KMS / local n/a AWS KMS only Provider-controlled
Agent uses only outbound traffic ✅ Loopback probes; no inbound n/a n/a Varies

On the roadmap (not live yet)

Listed here because they are not shipped. See the product status page for the exact Live / QA-certified / In-progress / Roadmap split.

  • Azure Key Vault and GCP Secret Manager providers. The agent's resolvers ship Vault + AWS Secrets Manager today; the others are next.
  • HashiCorp Vault advanced flows and deeper Kubernetes External Secrets integration.
  • Flux integration (read-only ArgoCD observation ships today).
  • Per-tenant KMS scoping: one CMK per deployment for now.
  • Agent connection-scoped job claim and a richer agent fleet dashboard.
  • Native Slack / PagerDuty notification sinks: webhook is in; native sinks are next.

🚧 Pre-v1.0

The architectural foundation is solid (BRD-aligned, polyrepo, infra-free core, type-safe Go), but several P0 items from the SECURITY_REVIEW are still open: real OIDC, agent workload identity, rate limiting, key-rotation runbook. We're tracking them on the org project board.

If you'd like to be a design partner, particularly if you're in financial services, healthcare, or government-adjacent, please open an issue at secrets-bridge/.github.