Here is the security posture of most AI-forward engineering teams right now: every engineer has production-adjacent credentials sitting on their laptop, in .env files and logged-in CLIs, and every engineer runs coding agents in permissive modes right next to them. The engineers who work on infrastructure, the ones with the broadest access, are often the heaviest agent users. The probability of disaster on any given day is low. The blast radius is the entire product.
To be fair, this risk predates agents. A stolen laptop or a walk to the bathroom with an unlocked screen exposed the same secrets. But agents change the math. A stolen laptop requires an attacker. An agent with skipped permission checks is executing thousands of autonomous actions a day inches from credentials that could take down cloud accounts. You do not need malice, only one bad supply-chain package or one badly interpreted instruction. Exposure now scales with usage, and usage is going straight up.
The wrong response is locking the agents down, because that kills the adoption you spent a year building. Teams that study this seriously, some to the point of opening formal security incidents about it, tend to conclude it cannot be solved on the laptop at all. They are right. The answer is relocating execution. When agents run in cloud sandboxes instead of on laptops, the credential problem becomes tractable. Secrets get injected at runtime, scoped per user and per project, instead of living permanently on disk. Better still, credentialed access can flow through a proxy that brokers tool calls, so the agent can invoke a Stripe tool or query logs without the raw token ever appearing in its environment. The agent uses the secret. It never possesses it.
There is a second benefit. Per-user, centrally managed access also fixes the inequality problem, where one engineer has wired up an integration and is dramatically more productive than a teammate who has not. Hook the system up once and every engineer gets the same scoped capability, which is the same argument behind event-driven and background agents running in managed environments rather than on whoever's machine happens to be open.
The endgame is simple to state: no long-lived credentials on developer laptops, and no agent that can read a secret it only needs to use. Teams that treat this as an architecture decision now will avoid treating it as an incident report later.
Key takeaways
- Agents running with skipped permission checks next to local AWS credentials and .env files create real blast radius, even at low probability.
- Locking agents down kills the adoption you fought for, so the answer is relocating execution, not restricting it.
- Sandboxed cloud execution lets credentials be injected scoped and proxied per user, so the agent uses secrets without ever reading them.
FAQ
Isn't this risk the same as a stolen laptop?
The laptop risk existed before agents, but agents change the math. A stolen laptop requires a targeted attacker. An agent with skipped permission checks executes thousands of autonomous actions a day next to those same credentials, so exposure scales with usage.
How do you give agents access to secrets without exposing them?
Run the agent in a sandboxed environment where secrets are injected at runtime, scoped per user, and ideally brokered through a proxy so the agent can invoke a credentialed tool without ever reading the raw value.
Related Essays #
Cloud Dev Environments Are the Unlock for Parallel Agent Work
Running agents locally hits a wall fast. Cloud-based dev environments let teams run parallel agent sessions, share work instantly, and actually scale.
Let the Agents Fight Each Other
If a coding agent introduces a bug and a testing agent catches it and a debugging agent fixes it, that is a win. The developer's time was preserved.
The Offense-Only Problem with AI Coding
Most developers deploy AI almost exclusively to ship features faster. The asymmetry is the problem — not the AI itself.