The Containment Problem: Why AI Agents Require a Different Kind of Execution

Most organizations evaluating AI agents are focused on what they can do. That is an important question. But it is not the decisive one. The question that will define whether agents can be trusted in real systems is: under what conditions are they permitted to act? These are not the same question. And the gap between them is where most of the serious risk lives.

The problem is not intelligence. It is execution.

AI agents are already reading files, executing shell commands, fetching data from the web, modifying codebases, and chaining these actions together in pursuit of a goal. They are not just generating text. They are acting.

There is a fundamental difference between code that does what it was explicitly written to do and an agent that interprets a goal and selects its own path toward it. Conventional software follows instructions. An agent pursues outcomes. And when something pursues outcomes, the risk is not just bugs, it is logical but unintended actions. Actions that were technically permitted, but should never have been taken.

This is the containment problem. And the execution models most organizations currently build on were not designed to answer it.

Process isolation is the wrong primary control boundary

Containers gave us a portable, reproducible way to package and isolate applications. For that purpose, they work well.

But containers draw their boundary at the process level, defining where an application runs, not what it may do once running. When the application is deterministic code written by a human, that is a reasonable tradeoff.

When the application is a goal-driven agent capable of chaining arbitrary actions, process-level isolation is the wrong primary control boundary. It is not that process isolation is worthless, it is that it does not answer the questions that matter for agent execution:

• Which specific files may this agent read?
• Which commands may it execute, and which require explicit human approval?
• What network access is permitted, and where?
• What is the default when the agent attempts something outside its defined scope, permit or deny?
• Can every action be traced, attributed, and if necessary revoked?

You can approximate answers to these questions by layering additional controls on top of process isolation. But constraint is not the primary organizing principle of that model. You are adding it against the grain.

The default that changes everything

The principle at stake here is called capability-based security. The core idea is simple: nothing is permitted by default. Access to resources, files, commands, network, services.... must be explicitly granted. Permissions are narrow in scope. Actions outside the granted permissions are denied, not permitted-until-blocked.

In practice, access tends to start broad and narrow over time, because that is operationally easier. For conventional software, teams have often been able to close that gap with tooling and operational discipline. For agents, closing it that way is no longer sufficient, because the source of the risk is not misconfiguration. It is the architecture of how permissions are held in the first place.

An agent that reasons freely but acts under explicit, revocable, per-action permissions is a fundamentally different risk surface than an agent operating inside a broad process boundary.

The agent can reason freely. It cannot be permitted to act freely.

What this reveals about Heim

At NorNor, we have spent four years building an execution layer around a core architectural conviction, Heim: that execution environments should enforce what code is allowed to do, not just where it runs.

That conviction was not born from AI. It came from a different set of problems, operational complexity, determinism, the operational weight of the container-and-orchestration stack. Our architecture was built capability-first, with access to host resources explicit, narrow, and deny-by-default.

What the AI agent problem does is make visible why that architecture matters in ways that were previously harder to articulate. The emergence of goal-driven, action-taking software is not a new challenge that Heim is now adapting to. It is a precise illustration of why execution environments need to enforce what code is allowed to do, and why that constraint has to be structural, not layered on top.

We are testing agent execution on our own runtime internally. The enforcement primitives that make it possible to run arbitrary code under fine-grained policy are the same primitives that make it possible to constrain an agent's actions to a defined scope.

The question that will define AI in production

AI agents will move from demos into real systems. They already are. And as they do, the conversation will shift, from what they can do to what they should be permitted to do, and how that permission is enforced.

That question does not have a prompt engineering answer. It does not have a model quality answer. It has an execution architecture answer.

The infrastructure decisions being made now, about what agents run on, and how their permissions are structured, will matter more than most people currently expect. The organizations that get this right will not just have safer AI deployments. They will have deployments where the trust boundary is defined by the execution layer itself, not patched in afterward.

Nimer Björnberg, CEO NorNor AB