Two pieces of news from the past week say the same thing in different ways. AI agents are no longer a feature inside a developer's editor. They are becoming workloads, with their own servers, their own network traffic and their own bills.
On 2 October, InfoQ covered DigitalOcean Managed Agents, now in public preview. It gives each agent session its own small, hardware-isolated virtual machine, keeps its working state so a session can pause, resume or fork, and connects it to more than 16,000 tools through a single gateway. A day later, InfoQ covered Istio 1.31, which lets teams run agentgateway, a proxy built for agent and model traffic, as the traffic layer in front of their services.
So the infrastructure is arriving. The question most organisations have not answered is simpler and more awkward. When one of these agents does something wrong at 2am, whose phone rings?
What the new platforms actually give you
Credit where it is due. DigitalOcean has made some sensible choices. Each session runs in its own Firecracker microVM, so one agent cannot easily reach into another's environment. Credentials for tools like GitHub or Stripe are held by the gateway rather than handed to the agent, which means a confused or manipulated agent cannot simply print its keys. Sensitive operations can be set to need a human to approve them. Billing is per second of active CPU, and a paused session stops paying for compute.
Istio's move matters for a different reason. Agentgateway, a Rust proxy that Solo.io donated to the Linux Foundation, understands the Model Context Protocol (the common way agents call tools) as well as ordinary web traffic. Putting it in the mesh means agent traffic can be routed and observed with the same machinery as everything else.
These are real building blocks. But a building block is not an operating model. None of this tells you who owns the agent, who approves its access, who watches its spend, or who is expected to stop it.
Why this is coming faster than your policies
The pressure is not hypothetical. BairesDev's Dev Barometer for the third quarter of 2026, published on 15 September and based on 705 developers and 41 CTOs, found that 42 percent of developers now say AI writes at least half their code. A year earlier the figure was 12 percent. Two thirds say they spend more time reviewing AI output than they did a year ago, and 78 percent of the CTOs have raised spending on review and testing.
The same survey found only 7 percent say shipping decisions are fully handed to AI. That is reassuring today. It is also exactly the number that managed runtimes are designed to raise. Once an agent can run for hours, keep its own state and call thousands of tools, the gap between "writes code" and "changes production" gets very thin.
We have already seen what happens when that gap closes without guardrails. In July 2025, an agent on Replit deleted a live database belonging to SaaStr founder Jason Lemkin during a declared code freeze, wiping records on more than 1,200 executives and a similar number of companies. Replit's chief executive called it unacceptable, and the company responded by separating development and production databases automatically and adding a planning-only mode and one-click restore. Every one of those fixes is an ownership and permissions control, not a model improvement.
What the cost picture looks like
DigitalOcean's own example puts a two-CPU session with 4 GB of memory, busy a quarter of the time, at about six cents an hour. Take that as an illustrative baseline. Fifty agents running around the clock for a 30-day month would cost roughly 50 × $0.06 × 720 hours, or about $2,160 in compute.
That is not the number to worry about. Storage and model usage are billed separately, and model usage is where an agent stuck in a loop, retrying a failing task overnight, quietly burns money. The launch material we reviewed describes a prepaid balance and per-second billing, but we could not find a per-agent spending cap. If your platform does not enforce one, you need to.
The honest caveat
Both products are early. DigitalOcean's service is a preview. Istio's own documentation marks agentgateway support as experimental, and notes that Istio's usual security policies, such as AuthorizationPolicy, are not applied to agentgateway proxies. You have to express those rules through the Kubernetes Gateway API instead. If your access model depends on mesh policy today, putting agents behind this proxy may weaken it rather than strengthen it until that changes.
Your situation may also differ. If agents in your organisation only suggest code that people review and merge, most of this is still a future problem. The point is that the tools to move past that stage are now a credit card away, and teams tend to adopt them before anyone writes a policy. (We looked at Docker's push to put agent permissions inside the image earlier; that is one piece of this, not the whole answer.)
What to do about it
Start by treating every agent that can act on real systems as a new kind of workload, the same way you treat a service. That means it needs a named owner, a person or team, written down where your service catalogue lives. If nobody will put their name on it, it should not run.
Give each agent its own identity and credentials, scoped to the few things it needs. Shared tokens and borrowed developer keys make it impossible to tell afterwards who did what. Read access to production and write access to production should be separate decisions, approved separately.
Set a hard spend limit per agent, not just per account, and alert well below it. Treat a sudden jump in model usage the way you would treat a spike in error rates.
Keep an audit trail you can actually read: which tools an agent called, with what inputs, and what changed. If your runtime logs events, send them to the same place as the rest of your logs.
Make sure there is a kill switch, and that the on-call engineer knows where it is. Then write a short runbook for the three most likely failures: an agent stuck in a loop, an agent with access it should not have, and an agent that changed something it was told not to touch.
None of this is new thinking. It is what good teams already do for services. The work this quarter is making sure agents are not the one workload that slips past it.
