The Untrusted Tenant: Rethinking Infrastructure Security for Agentic AI

Why the next security frontier for AI is not the model — it is the infrastructure the model is allowed to touch.

By Alex Zenla, CTO of Edera and Ken Huang

Anthropic’s release of Claude Fable reflects the industry’s growing recognition that autonomous AI systems cannot be trusted to behave as intended. High-risk queries get rerouted to a less capable model, and the unrestricted version stays gated to a small set of vetted partners. The lab that built the model treats raw capability as something to contain rather than something to trust. That same logic is now arriving at the infrastructure layer.

Much of the security conversation around agents to date focused on prompt injection, jailbreaks, hallucinations, and model behavior. Those are important concerns, but they are not the root problem. The deeper challenge is that organizations are increasingly giving autonomous systems access to tools, credentials, infrastructure, networks, and execution environments. Bringing trust to these systems is shifting the priorities to guardrails, restrictions and containment.

As I often tell people, an LLM’s output is untrusted data. If you are executing actions based on that output, you are executing untrusted code. Once you accept that premise, the rise of AI sandboxing becomes much easier to understand.

The practical consequence is a change in where the control point sits. For years the guiding question was “is this model safe?” The more durable question is “what can this model reach?” The first is a property of the weights and can never be fully guaranteed; the second is a property of the runtime, and it is enforceable. Designing for capability rather than intent is what moves the problem from an open research question into an engineering one.

Agentic AI Changes the Trust Model

Many people compare the current state of agents to the early days of Docker before Kubernetes emerged. There are certainly similarities. Developers are rapidly building agents, experimenting with frameworks, and creating bespoke systems long before operational standards have fully matured.

But I think a more useful comparison is the transition from monolithic applications to distributed systems and service-oriented architectures. As software became distributed across networks, machines, and services, entire categories of infrastructure emerged to address reliability, observability, identity, and security. The industry had to rethink assumptions that had worked perfectly well in a single machine world.

Agentic AI introduces a similar shift, but with a new complication: autonomy.

Agents are still applications. They are still processes running on infrastructure. What makes them different is that their behavior is increasingly shaped by probabilistic systems that generate actions at runtime. They consume inputs, invoke tools, access external systems, and make decisions that developers may never have explicitly anticipated.

This fundamentally changes the trust model. Historically, most software was assumed to operate within relatively predictable boundaries. Agentic systems do not offer that guarantee. Agents are not necessarily malicious, but they are inherently unpredictable. The cleanest illustration involved no attacker at all. Last summer, Replit’s coding agent deleted a production database during an active code freeze. No exploit, no injection. Autonomy plus access was enough.

Figure 1 — The trust model inverts. Traditional software is trusted because its behavior is fixed and predictable; an agent’s behavior is generated at runtime, so its output must be treated as untrusted data — and acting on it means executing untrusted code.

One of the ideas I keep coming back to is that agents should be treated as tenants. The cloud industry has spent decades refining how untrusted tenants share infrastructure safely. Agentic systems introduce a new kind of tenant, one capable of acting independently and interacting dynamically with the environment around it. That reality has profound implications for how we think about isolation and designing for breaches.

The tenant framing is more than an analogy — it tells you which playbook to reuse. Multi-tenant cloud already solved the hard version of this problem: run mutually distrustful workloads on shared hardware without letting one reach another. What is new is that this tenant writes its own actions as it runs. So the classic tenant controls still apply, but two of them stop being optional. Identity has to be per-session and attributable, because a nondeterministic actor is impossible to audit after the fact without it. And the boundary has to assume compromise from the first request, because there is no clean build you can point to and call trusted.

Why Shared Infrastructure Starts to Break Down

Many of the security challenges emerging around agents stem from the fact that they are being deployed into environments designed around trusted and deterministic workloads.

Containers are a good example. Containers transformed software delivery by standardizing packaging and deployment. But they were designed around developer ergonomics and continuous deployment, not around containing autonomous systems executing untrusted code. And where traditional application bugs were usually confined to a single application, an autonomous agent with access to tools, credentials and execution environments creates a much larger blast radius.

In Kubernetes, an agent may not even need to exploit a flaw to escalate privileges: service account tokens are mounted into pods by default, and cloud metadata endpoints are frequently reachable unless someone has explicitly blocked them. The agent simply inherits that blast radius. From there, it can invoke sensitive APIs, modify files, expose secrets, consume resources in unexpected ways, or interfere with neighboring workloads on highly multi-tenant infrastructure where nodes, GPUs and kernels are shared to optimize efficiency.

Figure 2 — On shared infrastructure, an agent inherits reach it never had to earn. Default-mounted tokens, reachable metadata endpoints, and a shared kernel turn a single autonomous process into a path to secrets, sensitive APIs, and neighboring workloads — no exploit required.

The issue is not any specific attack category. Prompt injection, credential misuse, tool abuse, memory poisoning, and unauthorized network access are all symptoms of the same underlying problem. Organizations are increasingly running untrusted execution environments inside infrastructure that was never designed to assume untrusted behavior.

This is why chasing individual attack categories is a losing strategy. Each new symptom invites its own point defense — a prompt filter, a jailbreak classifier, a tool-call allowlist — and the list never ends, because you are patching manifestations instead of the condition. The condition is ambient authority: the agent holds standing access it did not need and cannot be trusted to use narrowly. Remove the standing access and whole classes of symptoms collapse at once. A stolen credential is worthless if it was scoped to one task and expired at the end of the session; a reachable metadata endpoint is inert behind default-deny egress. Least privilege stops being a compliance checkbox and becomes the primary control.

What AI Sandboxing Actually Means

When people hear the term AI agent sandboxing, they often think about a single product category or implementation. I think of it more as a security architecture.

An effective AI agent sandbox must first prevent an agent from impacting the host, which in practice means a hardware-enforced boundary and a separate kernel per workload rather than shared-kernel namespaces. It must control network access with default-deny egress and explicit allowlists, because agents almost never need the full open internet. It must establish identity boundaries built on scoped, short-lived credentials per agent session instead of ambient secrets. It must create meaningful isolation between workloads, agents, and tenants, ideally in ephemeral environments that start clean every session. And it must do all of this at near-native performance. The old objection that strong isolation costs too much died when microVMs started booting in hundreds of milliseconds.

Figure 3 — AI sandboxing is a layered architecture, not a single product. Runtime, network, identity, and environment controls each close a different escape path, and none of them carries the weight alone — all at near-native performance.

That balance between trust, security, and performance is critical. Organizations are not looking for environments that eliminate autonomy. They are looking for environments where autonomy can operate safely.

Network microsegmentation is part of the answer, but only part. Segmentation governs east-west traffic. It does nothing about a kernel compromise on a shared host. Meaningful isolation has to exist at multiple layers of the stack: the data an agent can read, the tools it can call, and the runtime it executes in. No single control carries the weight.

At its core, AI sandboxing is built around a simple principle: assume everything can go wrong.

Once agents are given access to tools and execution environments, failure is no longer a theoretical possibility. It becomes an architectural certainty that systems must be designed to withstand.

It is worth being precise about why this cannot be solved by keeping a human in the loop. Approval gates work when actions are rare and legible. Agents generate actions continuously, at machine speed, in volumes no reviewer can meaningfully inspect — and the whole point of deploying them is to remove the human from the routine path. Oversight does not disappear, but it moves. Instead of approving each action, you constrain the environment so that even an unreviewed, wrong, or hijacked action stays inside a boundary you already trust. The sandbox is what lets you say yes to autonomy without betting the blast radius on every individual decision being correct.

The Goal Is Not To Make Everything Agentic

I do not believe everything will become agentic. In fact, I think that assumption is unrealistic.

There will continue to be enormous amounts of deterministic software because predictability remains valuable. But wherever organizations choose to deploy autonomous systems, they will need infrastructure designed for a fundamentally different trust model.

The long term challenge is not building more agents. The challenge is building environments where autonomous systems can safely coexist with everything around them.

That is why AI sandboxing is emerging as such an important category. It is not about restricting what agents can bring to productivity. It is about creating the isolation boundaries that allow organizations to trust them enough to deploy them in the first place.

What This Means for Security and Platform Teams

If you are responsible for the infrastructure agents run on, the shift is concrete and actionable. A few principles translate the trust model above into decisions you can make this quarter:

• Treat every agent as an untrusted tenant. Give it its own isolation boundary by default, the way a serious multi-tenant platform never lets one customer’s workload share a kernel with another’s.

• Default-deny the network. Egress allowlists per agent, not open internet. Most agents need a handful of endpoints; grant exactly those.

• Kill ambient authority. No standing tokens mounted by default. Issue scoped, short-lived credentials per session so a leak expires on its own and every action is attributable.

• Make environments ephemeral. Start clean every session so poisoned memory, stray files, and residual state cannot accumulate across runs.

• Measure blast radius, not just accuracy. Before deploying an agent, ask what it could touch if it went fully wrong today — and shrink that surface until the answer is acceptable.

• Assume breach, and design for it. The Replit incident had no attacker. Autonomy plus access was enough. Your controls should hold even when the agent is simply wrong.

Key Takeaways

• An LLM’s output is untrusted data — and acting on it is executing untrusted code. That single premise reframes the entire security problem.

• The real risk is not the model; it is the reach. Prompt injection, jailbreaks, and hallucinations are symptoms; standing access to tools, credentials, and infrastructure is the cause.

• Autonomy plus access is enough to cause damage — no exploit required. Unpredictable is not the same as malicious, and it is just as dangerous to a production database.

• Agents are a new kind of tenant. Reuse the multi-tenant cloud playbook, but make per-session identity and assume-breach isolation non-negotiable.

• Sandboxing is an architecture, not a product. Hardware-enforced runtime isolation, default-deny networking, scoped ephemeral credentials, and clean-per-session environments — layered, because no single control carries the weight.

• Strong isolation is no longer a performance tax. microVMs boot in hundreds of milliseconds; the cost objection is dead.

• Isolation is an enabler, not a restriction. It is what lets an organization trust an agent enough to deploy it at all.