A Quiet but Consequential Release
AWS has open-sourced the Workload Credentials Provider, a lightweight client-side tool that automates the delivery and refresh of certificates from AWS Certificate Manager and secrets from AWS Secrets Manager across both AWS and non-AWS workloads. Formerly known as the AWS Secrets Manager Agent, the renamed and expanded provider is available under the Apache-2.0 license on GitHub. It is the kind of release that generates no keynote applause but solves a problem that quietly consumes operations teams everywhere: keeping credentials and certificates fresh on every host that needs them, without writing and maintaining a pile of bespoke glue code to do it.
The framing from practitioners captures why this matters. As Ashish Kasaudhan, a senior cloud architect at PwC Acceleration Centers, observed, "The hidden cost of secrets management isn't the API call. It's the operational complexity." Corey Quinn of The Duckbill Group put the relief more bluntly: "Your ops team finally gets to sleep through cert expiry weekends." Both comments point at the same truth. The marginal cost of fetching a secret is trivial; the accumulated cost of building, monitoring, and debugging the automation that keeps thousands of secrets and certificates current is anything but, and it lands disproportionately on the people holding the pager.
The Problem: Certificate Lifetimes Are Collapsing
The release lands against a specific industry pressure. The Certification Authority Browser Forum, the body that governs how public certificates are issued and trusted, has been steadily mandating shorter certificate lifetimes. Each reduction multiplies the number of renewal and redeployment events an organization must handle, and manual or semi-automated processes that were tolerable at annual renewals become untenable when certificates rotate every few months or weeks. Previously, customers exporting public or private certificates from ACM had to stitch together custom automation using Amazon EventBridge to detect renewals and push the updated certificates to their fleets.
That custom automation is exactly the sort of undifferentiated heavy lifting that becomes a liability at scale. It has to be written once, then maintained forever, kept in sync across operating systems and web server configurations, and debugged when a renewal silently fails and a service starts serving an expired certificate. The Workload Credentials Provider collapses that whole category of work into a single managed component. It checks for updated certificates every 24 hours, downloads them only when the content has actually changed, and can run a user-configured command after each successful refresh, such as reloading Apache or NGINX, so the new certificate takes effect without manual intervention.
Built in Rust, With Security as a Default
The engineering choices signal that AWS treats this as security-critical infrastructure rather than a convenience script. The provider is written roughly 94 percent in Rust, with PowerShell and shell scripts only for installation, a deliberate choice for a tool that handles secrets and runs as a long-lived local service. It operates as a localhost HTTP server that applications query instead of calling AWS APIs directly, and it ships with SSRF protection: callers must present a token header so that a server-side request forgery vulnerability elsewhere on the host cannot trick the provider into leaking secrets. Notably, it defaults to post-quantum ML-KEM key exchange, putting forward-looking cryptography in the default path rather than behind a flag.
On the secrets side, the provider retains full backwards compatibility with the AWS Secrets Manager Agent it replaces, so existing deployments migrate without rework. It caches secrets in memory with a configurable time-to-live that defaults to 300 seconds, supports a refreshNow parameter to bypass the cache when a fresh value is required, and can pre-fetch secrets at startup using tag-based discovery. Role chaining enables cross-account access, and the same localhost interface serves all of it. For certificates, it supports up to 50 entries, each managed by an independent background task, so one slow or failing certificate refresh does not block the others.
Runs Almost Anywhere, Including Off AWS
Deployment flexibility is a core part of the pitch. The provider runs as a system service on Linux via systemd and on Windows with PowerShell 5.1 or later, and it installs through RPM packages for AL2023 and RHEL, Debian packages for Ubuntu, a Windows installer for EC2, a container sidecar via Docker, and an AWS Lambda extension. For secrets, supported targets include AWS Lambda, Amazon ECS, Amazon EKS, and Amazon EC2; for certificate management, Amazon EC2 and on-premises hosts are covered. That on-premises and non-AWS reach is the strategically interesting part, because it lets organizations standardize credential delivery across hybrid estates rather than running one mechanism inside AWS and a different one everywhere else.
The sidecar deployment pattern is particularly relevant for containerized and Kubernetes-based platforms. Running the provider as a sidecar gives each pod a local, cached, SSRF-protected endpoint for secrets and certificates without embedding AWS SDK calls or long-lived credentials into the application container. That is a cleaner separation of concerns than baking secret retrieval logic into every service, and it aligns with how platform teams increasingly think about credential delivery as a property of the runtime environment rather than the application code. The application asks localhost; the platform handles the rest.
An AWS-Native Answer to Vault Agent
Strategically, observers have framed the Workload Credentials Provider as an AWS-native alternative to HashiCorp Vault Agent for client-side credential delivery. That comparison is apt and worth examining for what it reveals about AWS's intent. Many organizations adopted Vault Agent specifically to get automated, local, cached delivery of secrets and certificates with policy-driven refresh, a capability AWS's own tooling previously left to customers to assemble. By shipping a first-party, open-source provider that covers the same ground for ACM and Secrets Manager, AWS reduces a meaningful reason to bring in third-party secrets infrastructure for AWS-centric workloads.
The honest caveat is the economic one. The provider itself is free and open source, but it is a delivery mechanism, not a free lunch: users still pay for the underlying AWS Secrets Manager and ACM usage it orchestrates. For teams already standardized on those services, that is simply the existing bill plus a better client, and the trade is clearly favorable. For teams running a multi-cloud secrets strategy on Vault or another platform, the calculus is more nuanced, since adopting an AWS-specific provider trades portability for tighter integration. Either way, the release is a clear signal that AWS intends to own the client side of credential delivery, and it has open-sourced a credible, security-forward tool to do it.
