The New Multi-Tenant Challenge: Securing AI Agents in Cloud-Native Infrastructure

Every company is becoming an AI company, or so the saying goes. What that increasingly means in practice is that every company is becoming a company that runs untrusted code on behalf of its users.

Last year, our product team pitched a feature: An AI agent that could clone a customer’s repository, analyse a production bug, write a fix, and open a pull request. My first thought was that this sounded like a veritable security nightmare.

To do its job, the agent needs to execute shell commands, read and write files, and make network calls to GitHub and various LLM APIs. The inputs are untrusted code from customers, prompts that could have been injected with untrusted content, and an LLM whose behaviour we can influence but never fully control. If any of those things go wrong in the right combination, you can end up with one customer’s agent exfiltrating another customer’s source code, or credentials leaking through prompt manipulation, or your infrastructure becoming someone else’s free compute cluster.

Protecting a system like this isn’t trivial. In fact it’s quite a daunting task, one which has historically only been the domain of large organisations who are providing infrastructure as a service.

But we love a challenge, and so we dug deep, did a load of research and built out a system that we had confidence in, which would allow us to sleep well at night! We ended up with a solution that wasn’t derived from any single clever trick; it’s more about re-applying the same defence-in-depth and least-privilege principles that have worked for decades, just carefully tweaked for a new kind of workload.

Familiar Patterns in Unfamiliar Territory

Fundamentally, you can see this as a multi-tenancy problem disguised as an AI problem. Whether you’re building coding assistants, data analysis tools, customer support automation, or any of the other agent-shaped products emerging right now, you eventually hit the same wall: the AI needs to do things, and doing things means executing code in some form.

As an industry, we solved multi-tenancy decades ago for web applications, then again for containers, then again in the context of serverless functions. Each time, the principles were the same: isolate workloads from each other, minimise the privileges each workload has, assume that any individual component can be compromised, and design so that compromise stays contained.

The difference with AI agents is that the threat model now includes the workload itself. A traditional container runs code you wrote, but an agent can run code that an LLM has cooked up seconds earlier, influenced by prompts that might be adversarial, operating on data you have never seen before. Trying to predict the outcomes here is futile.

Layering Isolation, in Practice

So how do you get the isolation that’s required? You layer several controls, none of which are novel individually. For example, we run agent workloads in containers on dedicated nodes, separate from our main application cluster. Each execution of an agent gets its own container on its own isolated Docker network, disconnected from other agents on the same host. Filesystem access is scoped to a single worktree that contains only the repository the agent is supposed to work on.

For network egress, all traffic is routed through an allowlist proxy, and anything other than connections to this proxy are rejected. That means that the agent can reach the VCS provider and the LLM endpoints it needs, but arbitrary outbound connections fail. In turn, this closes many of the obvious exfiltration and probing paths.

In terms of running the containers themselves, they’re hardened aggressively: User namespace remapping ensures that “container root” is not “host root”, all capabilities dropped, privilege escalation disabled, resource limits added to prevent fork bombs and runaway processes. These are documented practices that have existed for years, but have often been seen as optional or nice-to-haves. When running AI-directed workloads, you start to want all of them applied consistently.

Assume the Worst

A key takeaway here is that you have to assume everything will eventually go wrong, and design so that no single failure is catastrophic. Each layer of isolation reduces the blast radius. Combined, they make successful attacks impractical rather than merely unlikely.

Defence in depth means that if network filtering somehow fails, filesystem isolation still protects customer data. If container escape happens, the host has no credentials to anything valuable. Each layer reduces the blast radius; when combined, they make successful attacks impractical rather than merely unlikely.

Again, these aren’t new ideas, but when your workload includes an unpredictable reasoning system with access to a shell, you can’t afford to skip any of them. The response is not just to think up new security primitives, but also to apply the existing ones without exception.

Where We’re Going

The adoption curve we’re on here is steep. Industry forecasts suggest that by the end of 2026, 40% of enterprise applications will have embedded task-specific agents, up from less than 5% in early 2025. That is a lot of companies about to discover they need to run untrusted, AI-directed workloads safely.

Good news: The tooling is catching up. Open-source projects like the Agent Sandbox SIG and Kata Containers are building momentum, and service meshes/egress gateways are becoming more commonplace, allowing control over agent network access.

The hard problem that remains is cultural. Security research consistently finds that AI agents are dramatically over-permissioned. It’s common to find deployed agents that hold far more privileges than they need or use, as platforms default to broad access, as that’s the way things have always been done. Least privilege is a principle everyone agrees with, but few apply rigorously.

The cloud native ecosystem has provided solutions for similar types of problems before. We learned to treat containers as untrusted. We learned to assume breach and design for containment. The question now is around who will apply those lessons to agentic workloads, before the inevitable high-profile breach forces the issue.

We’re all still figuring this out, but the path forward looks a lot like the path behind: the agents are new, but the fundamentals are not.