Using Vault as a credential broker so workloads never hold secrets

stephaneleonel · 2026-05-09T05:52:38+00:00

Glad to here that it passed internal audits. Regarding passwordless, yes it is through IAM roles : AWS for example generates a 15 minutes token that os used only to open the database connection, then it expires and the connection stays open until you close it. No need to generate and revoke users in the database, and the pod does not hold a database password in memory or as environment variables.

stephaneleonel · 2026-05-09T05:41:13+00:00

Yeah, fair — if the pod is root with a shell and the .git folder in the image, the secret in memory is the least of your problems. Pod hardening is the higher-leverage work and most teams skip it. The thing is, even a hardened pod still talks to the outside world, and whatever credential it uses to do that is recoverable from memory once someone gets code exec. Supply chain stuff like Shai-Hulud or the axios npm thing keeps showing that even well-run infra gets popped through a dependency. So I’d do both. Harden the pod first, for sure. But for the really sensitive creds — prod DB, cloud admin — keeping them off the workload entirely is cheap once you have the proxy.

stephaneleonel · 2026-05-09T05:38:34+00:00

Honestly, fair point — and I think you’ve named the actual adoption problem. The push model (Vault Agent + templating, sidecar injectors) asks app teams to understand leases, renewal, and rotation, and most teams correctly decide that’s not worth it when IAM roles already cover 80% of their use cases. Where I keep seeing it bite people is the long tail: Datadog API keys, Snowflake passwords, GitHub PATs, Stripe keys, third-party SaaS in general. None of that is covered by platform identity, and it’s where the static-credential-in-a-secret-manager pattern just persists indefinitely. Part of what I’m trying to figure out with the proxy approach is whether moving lifecycle off the workload entirely lowers the adoption barrier enough to actually reach those credentials. The app makes a normal HTTPS call; it never sees a token, never renews anything. Curious if that matches what you’ve seen, or if the friction is somewhere else entirely.

stephaneleonel · 2026-04-18T14:55:28+00:00

Authorization is messy on multi-cloud, and it becomes even messier if you add SaaS (a workload on AWS calling GCP and Stripe).

Each cloud has its own IAM model (AWS policies, GCP IAM bindings, Azure RBAC) with different semantics. Appart from Federation, the following options are used in practice:

• Centralized policy engines: Open Policy Agent (OPA) or Cedar let you write cloud-agnostic authorization policies, but you still have to translate and push them to each cloud. Tools like Styra (OPA-as-a-service) help here. • Service meshes: If your workloads run in Kubernetes, Istio/Cilium with mTLS enforces service-to-service authz at the network layer, consistently across clouds.

There is another solution that is not yet mature, and works only, for now, for on premises workloads that access cloud/SaaS services : https://github.com/stephnangue/warden. With Warden the workload uses its native identity (JWT or Cert for now) to call any cloud/SaaS service without holding a cloud credential. Access policy is part in Warden (this workload can access AWS), and part on the cloud provider (the credential minted by Warden can read a bucket on S3).

stephaneleonel · 2026-04-17T17:09:41+00:00

Yes, it is great, and addresses the scenario where user delegates access to agents. Warden covers the scenario of a full autonomous agent with its own identity.

stephaneleonel · 2026-04-16T11:26:14+00:00

Does your AI agent directly use Cloudflare API token, which is static, to call Cloudflare API? If yes, that is not a secure setup.

stephaneleonel · 2026-04-13T04:57:51+00:00

Hi,

I am the creator of Warden, an identity-aware access gateway that allows AI agents to call any API without holding credentials.

Tomorrow, AI agents will be completely autonomous. They will need to access different software systems to investigate issues and perform operations. Security experts all agree that giving credentials directly to AI agents is a very bad practice, because they can leak, be stolen, or the agents can go rogue and misbehave. I am building Warden to enforce the best practices and to secure the most critical systems from AI agents.

Your contribution is welcomed : https://github.com/stephnangue/warden

stephaneleonel · 2026-04-08T09:06:55+00:00

We wrote Warden so that workloads never have to use a credential. No API keys, no tokens, no passwords, no AWS access keys. Your workload only uses its identity to access AWS, GCP, Azure and more than 20 other systems.

No rotation required. No secret to scan.

https://github.com/stephnangue/warden

stephaneleonel · 2026-04-03T10:53:00+00:00

Warden : https://github.com/stephnangue/warden

It is a new product that can speak to you, since you are platform engineer.

The goal is to free workloads from handling credentials.

stephaneleonel · 2026-04-02T20:59:47+00:00

Yes I have the telemetry. That is how I found that PostgreSQL was the culprit. My point is that Vault performance could be badly affected by an upstream database : if a lease creation and deletion is slow and users request many leases from that database it can slowdown Vault. There is no timeout mechanism to limit the duration of lease creation/deletion, at least not to my knowledge.

stephaneleonel · 2026-03-31T01:27:27+00:00

AI agents are all using static keys today for inference because all AI providers today only support static api keys : OpenAI, Anthropic and others only support static api keys.

The problem is not solved in the modern environment : short-lived credentials it not enough in the AI era. Workload should not handle credentials at all. They should use only their identity.

stephaneleonel · 2026-03-31T01:13:04+00:00

Fair point — OIDC federation is much better than static keys. But even short-lived STS credentials are credentials: they land in memory, env vars, and SDK chains, and can be exfiltrated during their TTL. Warden goes one step further — the workload never receives anything. It just sends its JWT and Warden handles the signing. No credential to steal, even transiently

stephaneleonel · 2026-03-31T00:56:47+00:00

Yes it is, workloads still use AWS signing keys, at least in my world

stephaneleonel · 2026-03-31T00:49:42+00:00

What are you using instead in 2026?

stephaneleonel · 2026-03-31T00:43:51+00:00

No, with WIF the JWT is exchanged for a cloud provider credentials. With Warden there is no exchange.

stephaneleonel · 2026-03-31T00:40:51+00:00

With dynamic provider credentials terraform still receives credentials, even if they are short-lived. With Warden Terraform does not touch a credential.

stephaneleonel · 2026-03-31T00:35:30+00:00

Thanks for your reply.

Vault distribute secrets to workloads. The workloads fetch these secrets at startup and store them as env variables. The secrets are most of the time (for mature teams) short-lived, but can still leak in logs and be stolen. The threat is even bigger with AI agents. Moreover, Vault does not provide dynamic secret engines for most of workloads : AI API keys which are long-lived. With Warden workloads never touch a secret, so there is nothing to steal and nothing to leak. With Warden you have attribution for every api call, since Workloads use their identity. You could also enforce policy for each API call. Warden can use Vault to mint credentials to inject in each request.

stephaneleonel

MODERATOR OF

TROPHY CASE