I've deployed and operated HashiCorp Vault in financial institutions across Europe for more than four years. Vault is an incredible piece of software. I've built my career around it. But after watching the same pattern play out at every organization, I realized Vault solves only half the problem — and the other half is about to get much worse.
Vault solves the secrets problem. It doesn't solve the access problem.
Vault is brilliant at what it does: store secrets, rotate credentials, issue short-lived tokens, manage encryption keys. It's the foundation of secrets management for good reason.
But here's what I kept seeing in every deployment, from mid-size fintechs to major European banks:
Teams would spend months setting up Vault. Secrets engines configured. Policies written. AppRole or Kubernetes auth wired up. Audit logs enabled. Everything by the book.
And then a service would authenticate to Vault, receive AWS credentials, and... that was it. The service walked away with real credentials and did whatever it wanted. No one knew which API calls it actually made. No one could distinguish between Service A and Service B if they shared an IAM role. And if something went wrong, CloudTrail would tell you the role name — not which of your twelve microservices actually called s3:DeleteObject at 3 AM.
Vault's job ends at the moment it hands over the credential. What happens after that is a blind spot.
The audit gap
Let me be specific about what's missing. Imagine you have five services that authenticate to Vault and receive AWS credentials via the AWS secrets engine. Vault's audit log tells you:
- Service A requested credentials at 10:00
- Service B requested credentials at 10:05
- Service C requested credentials at 10:12
Great. Now one of those services makes an unusual API call — say, iam:CreateUser in a production account. CloudTrail shows the IAM role made the call. But which service? You can't tell. The credentials Vault issued are identical in terms of IAM role. You're left correlating timestamps and hoping for the best.
This isn't a Vault bug. It's a gap in the model. Vault manages credential lifecycle — issuance, rotation, revocation. It doesn't manage credential usage.
Short-lived credentials are not enough
The industry has converged on "short-lived credentials" as the answer to secrets sprawl. And it's a good answer — a credential that expires in 15 minutes is better than one that lives forever.
But a credential that lives for 15 minutes can still do unlimited damage in 15 minutes. Scope is defined at issuance, not at the moment of each request. Once the credential is in the service's hands, it can make any API call the IAM policy allows, as many times as it wants, until expiration.
In a financial institution, the question isn't just "did this service have valid credentials?" It's "exactly what API calls did this service make, when, and were they all expected?" Short-lived credentials don't answer that.
Enter AI agents — and the problem gets urgent
For the last four years, this audit gap was an annoyance. Something you worked around with convention, extra tooling, and a lot of manual correlation. Humans are predictable enough that you can mostly get away with it.
AI agents change everything.
We're now giving autonomous software access to production cloud accounts. An AI coding agent that needs to push to GitHub, read from S3, and deploy to Azure. A data analysis agent that queries DynamoDB. An infrastructure agent that provisions resources via Terraform.
These agents are non-deterministic. They make decisions at runtime. They might call an API you didn't expect, in an order you didn't predict. And they're multiplying — one team might run ten agents, each with cloud access.
The question isn't whether AI agents will have cloud credentials. They already do. The question is whether anyone knows what they're doing with them.
With Vault alone, the answer is no.
What's missing: request-level visibility
The gap is between credential issuance and credential usage. Vault handles the first part well. Nothing handles the second.
What you actually need is:
- Per-request identity — know which specific workload or agent made each individual API call, not just which IAM role
- Per-request audit — log every API call with the workload identity attached, not just credential issuance events
- Per-request policy — enforce what API calls are allowed at the moment they happen, not just at credential issuance
- Zero credential exposure — the workload shouldn't hold credentials at all, eliminating the risk of credential theft or misuse
This is why I built Warden
Warden is an open-source identity-aware egress gateway. It sits in the request path between your workloads and cloud services — not at credential issuance time, but at the moment of every API call.
Here's how it works:
- Your workload makes a normal API call (say, to AWS S3)
- Warden intercepts the outbound request
- Warden verifies the workload's identity — via mTLS, JWT, Kubernetes service account, SPIFFE, or cloud machine identity
- Warden mints short-lived credentials on the fly (via STS, Vault, or the provider IAM)
- Warden injects the credentials into the request and forwards it to the cloud provider
- Every request is logged with the specific workload identity that made it
The workload never sees, holds, or handles real cloud credentials. They exist only inside the proxy, for the duration of a single request.
Warden complements Vault — it doesn't replace it
This is important: Warden isn't a Vault replacement. Vault is still the best secrets manager out there. Warden can use Vault as a credential source — in fact, that's one of the recommended configurations.
The difference is where they sit in the stack:
- Vault manages credential lifecycle: storage, issuance, rotation, revocation
- Warden manages credential usage: per-request injection, per-request audit, per-request policy
Think of it this way: Vault is the bank that holds the money. Warden is the accountant that records every transaction and makes sure each one is authorized.
What it looks like in practice
Warden currently supports AWS, Azure, GCP, HashiCorp Vault, GitHub, and GitLab as providers. The workload doesn't need any code changes — if your tool supports a custom endpoint URL, it works with Warden.
A few things that become possible with Warden in the path:
- "Which agent called s3:PutObject on the production bucket at 2:47 PM?" — you can answer this instantly, because every request is logged with the workload identity
- "Block all destructive operations from AI agents" — per-request policy enforcement means you can allow reads but block deletes, regardless of what the IAM role permits
-
"This agent should only access GitHub repos in the
src/directory" — Warden can enforce path-level restrictions that GitHub's own token scoping can't express - "Prove to the auditor that no unauthorized API calls were made last quarter" — the audit log is complete, per-request, and tied to identities
The hard part: proxying cloud APIs
Building Warden has been an exercise in pain, mostly around AWS SigV4 signature verification from the proxy side. Signing a request is well-documented. Verifying one from a man-in-the-middle position — so you can strip the original auth, inject new credentials, and re-sign — is a minefield of undocumented SDK behaviors, URI encoding edge cases, and service-specific quirks.
S3 alone has path-style vs virtual-hosted buckets, unsigned payloads, chunked signing, and presigned URLs with auth in query parameters. Directory buckets and table buckets use a separate SigV4-S3Express auth flow that's next on the roadmap.
But the proxy architecture is what makes everything else possible. If you're not in the request path, you can't do per-request anything.
What's next
Warden supports six providers today. The roadmap is 100+ — every major cloud, SaaS, and AI service. The goal is to become the standard identity-aware gateway for how workloads and AI agents access external services.
The project is open-source, written in Go, and available on GitHub: github.com/stephnangue/warden
If you've been running Vault and felt the same gap I described — or if you're deploying AI agents and wondering how to govern their cloud access — I'd love to hear from you. Open an issue, start a discussion, or reach out directly.
Stephane has been deploying and operating HashiCorp Vault in financial institutions across Europe for over four years. He is the creator of Warden, an open-source identity-aware egress gateway for cloud and SaaS services.
Top comments (0)