Secrets Management for Serverless and Edge Worker Applications
Inject secrets at the Worker runtime layer, not fetched from a vault during execution.
Edge compute makes one promise above all others: serve the request in under 10 milliseconds, from a location close enough to the user that "network latency" stops meaning anything. That promise breaks the moment a Worker has to stop and ask a central vault for a password. A single secrets lookup against a regional origin adds 100 to 150 milliseconds to a request that was supposed to finish in single digits, and the entire advantage of running at the edge gets wiped out by the one dependency nobody designed for the edge in the first place. There's a resilience cost too: routing every invocation back through one region to fetch a credential turns a globally distributed system into a globally distributed system with one point of failure. A faster vault only shaves milliseconds off a broken pattern. Injection changes the outcome, because the secret is present the moment the Worker executes rather than fetched over a network during execution. That distinction, injection versus fetching, is the spine of everything below, and it's the reason vault-at-runtime no longer holds up as an edge pattern.
How badly the industry currently handles secrets (and why it keeps getting worse)
Start with the number that should worry anyone running production infrastructure: 28.65 million hardcoded secrets landed in public GitHub repositories in 2025, according to GitGuardian's State of Secrets Sprawl 2026 report. That's a 34% jump from the year before, arriving at a moment when tooling to catch this stuff has never been more available. So availability isn't the bottleneck. Behavior is.
The instinct to treat private repos as the safe zone runs straight into the data: internal repositories are six times more likely to contain hardcoded secrets than public ones, presumably because nobody expects an outside party to ever see them, so review discipline slips exactly where it shouldn't.
AI coding assistants made this worse, which runs counter to what most engineering teams assumed would happen. Credential leaks tied to AI services jumped 81% year over year, a sharp rise that reflects how quickly AI tooling has become embedded in everyday development workflows. These are small, fast, hard-to-catch habits, repeated thousands of times a day across a codebase. No linter flags "the autocomplete just leaked a Stripe key" as a risk category, because nobody wrote that rule yet.
The problem doesn't stay confined to code, either. Entro Labs' H1 2025 analysis of more than 27 million non-human identities found that 43% of all exposed secrets live outside code entirely: in CI/CD workflow logs, collaboration tools, and messaging apps. Scanning repositories catches less than half the problem. Most secrets-scanning budgets are pointed at the wrong half.
The lifecycle management underneath all this is close to nonexistent. Across the industry, 71% of non-human identities never get rotated within any recommended time frame, 97% carry more privilege than they need, and 44% of tokens turn up exposed inside messaging and collaboration platforms. Sprawl is accelerating, rotation is the exception rather than the rule, and the attack surface has moved well past where most security teams are actually watching.
The non-human identity explosion and what it means for secrets at the edge
Non-human identities, meaning service accounts, API keys, tokens, and machine credentials, now outnumber human accounts by a wide margin. Rubrik Zero Labs puts the average enterprise ratio at 45 machine identities for every human one. In cloud-native and DevOps environments specifically, Entro Labs' H1 2025 research puts that ratio at 144 to 1, and the total non-human identity population grew 44% industry-wide between 2024 and 2025. Put those two numbers together and the story is simple: the ratio is already lopsided, and it's getting more lopsided fast.
Every Worker deployed at the edge adds to that count. A service token here, a signing secret there, a database credential for a function that queries a read replica three regions away. Most of these get created without a named owner and without an expiry date, so they persist until someone notices, or until an attacker does first.
Agentic AI turns the dial up further. Autonomous agents spin up ephemeral tokens on their own, call internal APIs without a human approving each call, and trigger deployments as part of a workflow nobody watches in real time. Each of those actions mints a machine identity, and most go untracked. Ninety-two percent of organizations already expose non-human identities to third parties in some form, and 68% have no identity security controls built for AI workloads specifically. That gap between exposure and control is the whole problem, in two numbers.
Structurally, this changes the core question of access control. "Who has access to what" gets a lot harder to answer when "who" is an agent acting on behalf of a service, not a person with a name and a manager. Secrets bound to Workers need explicit ownership, a defined scope, and an audit trail; encryption at rest solves a different problem entirely. Any runtime injection pattern built for the edge has to assume agents call Workers as clients, right alongside humans, and design access accordingly.
The right injection pattern: binding secrets at the Worker runtime layer
Name the anti-pattern first, because it's still everywhere: secrets sitting in environment variable files, fetched from a vault at cold start, or baked directly into a build artifact. All three treat the secret as something the application goes and gets, rather than something the runtime already has. All three carry the same latency and exposure cost.
The alternative: define the secret once at the account level, bind it to the specific Workers that need it, and decrypt it only at the moment of execution, inside the runtime itself. That single design choice removes the network round-trip entirely, so there's no latency penalty eating into the edge's core advantage. It also enables a write-only model, where a secret's value never gets exposed again after creation, not even to the person who typed it in. Nobody can leak what they can no longer see.
This works best as dedicated infrastructure with clear boundaries, not a configuration file with extra permissions bolted on. A secret like PROD_POSTGRES_PASSWORD gets defined exactly once and bound to as many Workers as need it, with zero duplication and zero risk of one copy drifting out of sync with another. Rotation happens at that layer too, so a credential changes without redeploying a single Worker script or kicking off a CI/CD pipeline. At a scale of thousands of Worker instances running globally, that's not a nice-to-have. A rotation that takes seconds beats one that takes a coordinated deployment window, every time.
Role-based access control governs who can bind a secret to a Worker, who can rotate it, and who can delete it, and a unified audit log records every one of those actions. That log directly answers the lifecycle failure modes described above. The 71% rotation gap and the 97% over-privileging problem don't fix themselves, but a system that logs every binding and every rotation at least makes the gap visible instead of invisible.
Where this pattern needs adapting: multi-cloud, Kubernetes, and CI/CD pipelines
Almost nobody runs edge Workers in isolation. Most teams run them alongside Kubernetes clusters, traditional serverless functions, and services spread across more than one cloud provider, and secrets management has to span all of it without recreating the exact sprawl problem it's meant to fix.
Kubernetes brings its own trap, and it's worth stating bluntly: secrets stored natively in Kubernetes are base64-encoded, which looks like security and isn't. Base64 is an encoding scheme, not encryption; anyone with read access to the cluster decodes it in one line, no key required. The workable pattern here is the External Secrets Operator model. It connects the cluster to an external secrets backend, syncs values on a configurable refresh interval, and keeps raw credentials out of the manifests entirely. That refresh interval needs careful tuning: too short, and the sync calls start adding real load to the backend API; too long, and a rotated credential sits stale in the cluster for hours after it should have been retired.
CI/CD pipelines are arguably the riskiest injection point of all, since secrets passed as environment variables during a build step have a habit of showing up in build logs, exactly one of the venues where Entro Labs found 43% of all exposed secrets living. The fix is to inject at deploy time rather than build time, and to authenticate machine to machine with scoped, short-lived tokens instead of one long-lived credential shared across every pipeline run.
Platforms built around an API-first model, Doppler among them, handle this by treating secrets as a service with scoped tokens and native CI/CD integrations, rather than as a file sitting somewhere in the repo. That model maps cleanly onto the edge injection pattern described above, and it points at the principle holding across every one of these environments: one source of truth, an explicit scope for every credential, and an audit trail that doesn't depend on where the runtime happens to live.
Secrets governance for agentic workloads running at the edge
Agentic AI is moving from experiment to line item fast. The market grew from $7.6 billion in 2025 to a projected $10.8 billion in 2026, and Gartner projects 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from under 5% just a year earlier. That's a curve, not a trend line.
Production reality lags the enthusiasm by a wide margin, and the gap is where the risk lives. Seventy-nine percent of enterprises say they've adopted AI agents in some form, but only 11% actually run them in production, and secrets management is among the unsolved challenges that keep production deployments limited. Ephemeral credentials get created and consumed by agents faster than any rotation policy built around human review cycles can track. Multi-agent workflows, where a planner hands off to an executor which hands off to a reviewer, create credential handoff chains that are genuinely hard to audit after the fact. The real risk concentrates at plugin and skill boundaries, not inside the model itself; every boundary where an agent calls out to a tool is a place a credential can leak.
Governance for this has to add several things on top of runtime injection. Each agent invocation needs its own short-lived, scoped token rather than a shared credential reused across runs. Plugin supply chains need review and skill manifests need signing, so a malicious or careless plugin can't quietly exfiltrate a credential it was never supposed to see. Each skill should execute in a sandboxed context limited to that one task's scope, with every binding showing up in an audit log recording which agent touched which secret, when, and for how long.
The underlying model here is Zero Trust, applied literally: every agent invocation gets treated as an identity that has to prove its scope before it goes anywhere near a secret, regardless of how trusted the surrounding process looks. Non-human identities already outnumber humans 144 to 1 in cloud-native environments, so agent secrets aren't an edge case to plan for later. They're the dominant management problem right now, and treating them as a future concern is how the next round of breach disclosures gets written.
Rotation, least privilege, and the operational habits that make injection patterns durable
Rotation without redeployment is what actually separates a durable pattern from a fragile one at edge scale. Tying secret rotation to a deployment pipeline was fine when there was one monolith to redeploy. It stops being workable the moment there are hundreds of live Worker instances spread across regions, each of which would need to be touched individually. The better model keeps rotation entirely inside the secrets layer, where Workers pick up the new value on their next invocation with no code change and no pipeline trigger required.
Least privilege has to function as a hard constraint enforced at creation, something engineers build into the system rather than a principle teams nod at during a security review and then forget. The fact that 97% of non-human identities carry excessive privilege isn't a rounding error; it's a direct reflection of how rarely scoping gets enforced when the credential first gets created. Every Worker binding should specify exactly which secrets it touches, whether it gets read or write access, and for how long that access stays valid. Bindings need review when a Worker gets deprecated, too, because an orphaned binding is just the.env file problem wearing different clothes.
Audit logs only help if someone actually reads them. Rotation events, binding changes, and access patterns need to reach the people on call, not sit archived in a system nobody opens until after an incident. A Worker suddenly touching a secret it hasn't used in weeks is a real signal, and alerting on that kind of anomaly catches problems a static permissions review never will.
Every secret should get a named owner and a defined expiry the moment it's created, well before a breach forces someone to finally ask who owns it. Runtime injection solves the latency problem and the exposure problem. Durability comes from treating rotation, scoping, and audit as things that happen continuously, revisited on an ongoing basis rather than checked off once during setup.
What a well-governed edge secrets architecture looks like end to end
Walk the full path a secret takes, start to finish. Definition happens once, at the account level, named by environment andunction, something like PROD_STRIPE_KEY, with a named owner and an expiry date attached from day one. Binding happens per Worker, with an explicit scope reviewed both at deployment and again at deprecation. Injection happens inside the runtime, decrypted at the moment of execution, never touching a build artifact or a log file along the way. Rotation happens at the secrets layer, fully decoupled from deployment, with Workers picking up the new value automatically. Audit records every binding, every rotation, every deletion, and surfaces all of it to on-call teams instead of burying it. Agent access runs on short-lived, scoped tokens issued per invocation, inside sandboxed execution contexts, with plugin supply chains reviewed before they ever touch a credential.
Worth naming plainly what this prevents. Hardcoded credentials sitting in a repo, because there's no build-time injection to leak one. Secrets showing up in CI/CD logs, because injection happens at deploy time instead of build time. The 100 to 150 millisecond latency tax, because there's no network round-trip at invocation. Stale credentials outliving their rotation, because rotation lives at the secrets layer instead of the deployment pipeline. Orphaned non-human identity bindings, because ownership gets enforced at creation rather than discovered during an incident.
Open questions remain, and pretending otherwise would be dishonest. Cross-account secret sharing at real scale isn't fully solved by any pattern in production today. Agent-to-agent credential handoff across long-running, multi-step workflows is still an active area of development, with frameworks like LangGraph working through exactly this problem in real time.
Return to where this started. The 100 to 150 millisecond penalty of fetching a secret from a central vault was never just a performance annoyance; it's a signal that the architecture underneath it got built for a compute model the edge has already left behind. Injection instead of fetching, rotation decoupled from deployment, scope enforced at creation rather than discovered after a breach: this is what the edge model actually requires to work as advertised.
