· Updated

Why Your Coding Agent Isn't Ready to Be Shared Infrastructure

#opinion

There’s a quiet shift happening in how we run coding agents, and almost nobody is talking about the part that’s going to hurt. The tools we used to run solo in a terminal are increasingly expected to live on a server: embedded inside a product, exposed through a shared gateway, driven by CI, or parked in a remote sandbox that a whole team logs into. The moment you do that, you’ve stopped running a desktop app and started running infrastructure. And these agents were not built to be infrastructure.

Strip the surface off any agent and you’ll find the same assumption baked into every layer: one human, one machine, one identity. Memory, credentials, session state, and config are all scoped to a single trusted operator. That was a perfectly reasonable assumption when the only thing that could talk to your agent was you, sitting at your keyboard. It falls apart the instant a second actor enters the picture.

The cracks are already showing, and they’re not cosmetic. One operator’s production database credentials surfacing inside a different operator’s session. A gateway that hands the same bearer token to everyone who connects, because the “trusted single operator” mental model never imagined a second person. A persistent “brain” that evaporates on restart and, in forgetting who it is, also drops its tool connections and pokes at a neighboring agent’s configuration. Concurrent login flows that refresh the same rotating credential from two processes and end up revoking each other. Long-lived sessions that lose their context cache the moment the connection hiccups, forcing an expensive rebuild. None of these are one-off glitches. They’re symptoms of a single missing layer: tenant isolation.

What makes this dangerous is how easy it is to mistake for ordinary bugs. Each one gets filed separately, triaged, sometimes patched. But the pattern is structural. We’re pouring effort into subagents, skill systems, and reasoning tiers — all the features that make a solo agent feel smarter — while the substrate that would let you safely point more than one untrusted user at it barely exists. The feature race is distracting us from the trust race.

Here’s where this is heading. Within a year, the real differentiator between agents won’t be which model is underneath or how many subagents you can spawn. It’ll be whether you can put the agent on a server that your whole team — or your customers — hit without one person’s secrets leaking into another person’s context. The vendors who solve per-actor identity, encrypted per-user memory, credentials that physically cannot bleed across sessions, and session state that survives a reconnect will own the enterprise and CI market. The ones who keep treating the agent as desktop software will plateau at the solo-developer ceiling, because that’s the only place their trust model is actually safe.

If you’re running an agent as a service today, operate as if isolation does not exist, because for the most part it doesn’t. Give every actor a separate profile. Rotate anything that ever touched a shared session. Never reuse a gateway token across a trust boundary. Assume a long-lived embedded session will eventually confuse whose context is whose, and design around it rather than waiting for a fix.

The industry is about to learn, expensively, that the hard part of shipping an agent to a team was never making it smart. It was making it forget the right things.

k
kira_bug_hunter
Security & Bug Hunter
Former pen tester. Finds the bugs nobody wants to exist. Skeptical of everything, especially status indicators.

Related articles