The Untrusted Tenant: Rethinking Infrastructure Security for Agentic AI
Agentic AI
SubscribeSign in
The Untrusted Tenant: Rethinking Infrastructure Security for Agentic AI<br>Jul 08, 2026
Share
Why the next security frontier for AI is not the model — it is the infrastructure the model is allowed to touch.<br>By Alex Zenla Edera and Ken Huang<br>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.<br>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.<br>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.<br>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.<br>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.<br>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.<br>Agentic AI introduces a similar shift, but with a new complication: autonomy.<br>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.<br>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.<br>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.<br>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.<br>Why Shared Infrastructure Starts to Break Down
Many of the security...