Think about a hotel keycard. It opens exactly one room, it stops working the day you check out, and if you lose it, the hotel just deactivates that one card and cuts you a new one. Nobody has to change the locks on every door in the building.
Now think about a master key. It opens everything, it works forever unless someone remembers to take it back, and if it goes missing, you have a genuinely bad afternoon ahead of you.
A huge number of background services, queues, cron jobs, and automated agents are still running on the equivalent of a master key: one static API token, generated once, dropped into an environment variable, and left there for years. It works fine, right up until it doesn't, and by then it's usually already a problem.
Why background workers get treated differently, and why that's backwards
Most teams put real thought into how a logged-in user authenticates. Sessions expire, passwords get hashed, multi-factor authentication gets bolted on. Then that same team spins up a background worker to process a queue of image uploads, and the whole conversation about security shrinks down to "generate an API key, put it in the .env file, done."
The logic seems reasonable on the surface. There's no human sitting at a keyboard for a background job, so a lot of the usual concerns, phishing, weak passwords, someone leaving their laptop unlocked, don't really apply. But that reasoning skips over the actual risk, which isn't about how the worker logs in. It's about what happens if that one static credential ever leaks.
And static credentials leak more often than people like to admit. They end up committed to a git repository by accident. They sit in plaintext in a logging system that wasn't supposed to capture environment variables but did anyway. They get copied into a Slack message during an incident and never rotated afterward. They live in a Docker image that gets pushed to a registry with looser access controls than anyone realized.
When that master key API token leaks, whoever has it can do everything your background service could do, for as long as nobody notices and rotates it. That could be months. Some breaches aren't discovered until well over a year later, and the credential that caused it was often sitting there quietly the whole time, valid and unnoticed.
What zero-trust actually means here
Zero-trust sounds like a big architectural philosophy, but for background workers it boils down to a genuinely simple idea: don't hand out a credential that works forever and does everything, when you could hand out one that works briefly and does one thing.
In practice, that means a few concrete changes.
Short-lived tokens instead of permanent ones. Rather than a static key that lives forever, a worker requests a fresh token that's only valid for a short window, often just minutes. If it leaks, the damage is capped by the clock. An attacker who steals a token valid for fifteen minutes has a much smaller window to do anything than an attacker who steals a key that's been quietly valid since 2022.
Scoped permissions instead of blanket access. A worker that processes image uploads should not hold a credential that also happens to be able to delete customer accounts or export financial reports, even if it never intends to use those abilities. Scope the token down to exactly what that specific job needs to do, nothing more. If it's compromised, the blast radius is whatever that narrow scope allows, not the whole system.
Identity tied to the workload, not to a shared secret everyone copies around. Instead of a token that gets pasted into five different services' configuration because it's convenient, each service or job proves its own identity independently, often using something like a signed certificate or a cloud provider's built-in workload identity system, and gets issued its own short-lived, narrowly scoped token in response. Nobody is sharing a secret that, if it leaks from any one of five places, compromises all five.
A concrete example
Say you run a queue that processes video uploads: a user uploads a video, a background worker picks up the job, transcodes it, and writes the result to storage.
The static key approach looks like this. A key gets generated once, given broad read and write access to the storage bucket because it was easier than figuring out the exact permissions needed, and stored as an environment variable across every worker instance. If one worker instance gets compromised, whether through a dependency vulnerability, a misconfigured container, or a leaked deployment log, the attacker now holds a credential with broad access that will keep working until someone happens to notice and rotate it.
The zero-trust approach looks different. Each worker instance authenticates using its own workload identity, something tied to the actual running instance rather than a copy-pasted secret. It requests a token scoped specifically to "write to this one storage path" and valid for the next ten minutes, does its job, and the token expires shortly after, whether or not anything went wrong. If that same worker instance gets compromised an hour later, whatever credential an attacker finds sitting in memory or in logs is already useless, or close to it, and even if it weren't expired yet, it could never have done anything beyond writing to that one narrow storage path anyway.
Same job gets done in both cases. The video still gets transcoded, the user still gets their result. The difference only shows up on the day something goes wrong, which is exactly when you want the difference to already be baked in, not something you wish you'd set up sooner.
The trade-off, honestly
This is more work to set up than a static key in an environment variable, and it's fair to be upfront about that. You need a way to issue short-lived tokens, usually some kind of identity provider or secrets manager, and your workers need logic to request a fresh token before the old one expires rather than assuming it'll just keep working. That's real engineering effort, not a config flag.
But compare that upfront cost to the cost on the other side: a leaked static key that worked for a year before anyone noticed, with full access to everything that worker could touch. Most teams that have been through an incident like that will tell you the setup cost would have been worth it many times over.
For genuinely low-stakes internal tools, a static key might really be fine. The zero-trust approach earns its cost on anything touching customer data, payment systems, or infrastructure that could cause real damage if the credential got out.
The takeaway
A background worker doesn't need a master key just because there's no human typing a password. It needs exactly the access it requires, for exactly as long as it needs it, and nothing more. Hotel keycards expire on checkout day for a reason. Your API tokens should too. The same instinct, scope access down and enforce it structurally instead of trusting discipline, is also the argument in our piece on multi-tenant isolation.
Written by Akram
Technical Specialist