Agents with Shells: The New Production Frontier

How has the AI agent execution model changed?

The agent execution model is pivoting from stateless, API-driven tool use to stateful agents with direct, persistent access to local execution environments. This shift, catalysed by recent platform updates like OpenAI's Agents API with "Computer use" capabilities, fundamentally alters the architecture of production agentic AI systems.

Previously, an AI agent's ability to act upon the world was constrained to a predefined set of sandboxed API calls. An agent could query a database or send an email via a specific function, but it had no concept of a persistent workspace, file system, or running processes. This model was secure and simple to manage but inherently limited. The agent was a transient caller of external tools, not a persistent worker within an environment.

The new paradigm grants agents a shell. It allows them to read and write files, execute scripts, install packages, and maintain state across multiple steps within a containerised environment. This unlocks vastly more complex and powerful workflows—from automated code repository management to dynamic data analysis involving multiple local tools. However, it also introduces state management, security, and reliability challenges that were previously abstracted away by the API gateway model.

How do we engineer for secure agent execution?

Secure execution for shell-enabled agents demands a defence-in-depth strategy, combining ephemeral, containerised sandboxes with granular, process-level permissioning and continuous behavioural monitoring. Relying on prompt-level guardrails alone is no longer sufficient when an agent can directly execute arbitrary code.

The foundation is isolation. Each agent task or session must run in a lightweight, single-use container (using technologies like Docker or Firecracker) with a minimal base image and no network access by default. This ensures that even a compromised agent cannot escape its immediate environment or affect other processes. All necessary files and tools should be mounted into the container at runtime, not pre-installed.

The second layer is fine-grained control. Instead of granting the container a broad set of permissions, we must define an explicit "allow list" of commands and system calls the agent is authorised to execute. This can be enforced using security tools like AppArmor or SELinux, effectively creating a specific Instruction Set Architecture for the agent's task. Finally, real-time observability is critical. Tools leveraging eBPF can monitor system calls, file access, and network packets generated by the agent's process, flagging anomalous behaviour that might indicate a jailbreak attempt or a hallucinated, destructive command sequence.

What are the dominant failure modes for stateful agents?

The dominant failure modes in this new stateful paradigm are state corruption, hallucinated execution paths, and unrecoverable error loops. Unlike stateless API calls that either succeed or fail atomically, stateful agents can enter broken intermediate states that are difficult to debug and resolve automatically.

State corruption occurs when an agent incorrectly modifies a file or environment variable, rendering subsequent steps in the workflow invalid. This necessitates robust checkpointing and rollback mechanisms. Before executing a potentially destructive command like `rm` or a script execution, the system should snapshot the agent's workspace, allowing for a clean reset if the step fails. Hallucinated execution paths, where an agent attempts to run a command that is syntactically correct but contextually nonsensical (e.g., `git push` in a `/tmp` directory), require proactive validation. The orchestration layer must parse the agent's intended command and verify its preconditions before execution.

What are the implications for Australian organisations?

For Australian organisations, the adoption of execution-capable agents creates a direct tension between their immense power and the strict data sovereignty and privacy obligations under the Privacy Act 1988. Giving an AI agent the ability to write to a local filesystem necessitates a rigorous approach to AI governance and data residency that many current architectures are unprepared for.

When an agent can download, process, and create derivative data artefacts on a file system, clear controls must be in place to ensure Personally Identifiable Information (PII) is handled correctly and that data never leaves Australian shores unless explicitly permitted. This presents a direct challenge for organisations across NSW, from fintechs in Sydney to advanced manufacturing operations in the Hunter region. Frameworks like the NSW AI Assessment Framework (AIAF) provide principles, but the technical implementation of accountability and transparency for these powerful new agents is a complex engineering problem.

Proving compliance requires detailed, immutable logging of every action the agent takes—every file read, every process spawned. This level of granular traceability and control is not a feature that can be added later; it must be designed into the core of the agentic platform. As specialists in production-grade agentic systems, our work at Precision Data Partners focuses on building these secure, compliant, and observable AI execution environments that meet the stringent demands of Australian enterprises. You can learn more about our approach to Responsible AI here.