Discuss your project
Agentic architecture

Long-duration agents in sandbox: architecture, security, and task recovery in 2026

An agent who works for hours needs checkpoints, budgets, persistent states, and access limits. The model is only part of the system: the harness and the sandbox determine what it can actually do.

Long-duration agents in sandbox: architecture, security, and task recovery in 2026

Agents are no longer limited to a sequence of three calls. They can inspect files, execute commands, use a browser, modify a project, and work on a task for a significant amount of time. In April 2026, OpenAI notably presented an evolution of its Agents SDK including controlled sandbox environments and a clearer separation between the harness and the compute.

This autonomy increases the value, but also the impact of an error. An agent can repeat a wrong action, follow a malicious instruction contained in a file, or pursue a costly strategy for hours. Reliability must therefore be designed at the platform level.

SDKs, models, and sandbox primitives are evolving rapidly. Check the versions and conditions at the time of implementation.

The model does not constitute the agent

An agentic system includes:

  • a model;
  • a harness that manages the loop;
  • instructions;
  • tools;
  • a policy;
  • a runtime environment;
  • a state;
  • a memory;
  • approvals;
  • of observability;
  • a stop mechanism.

The quality of the model matters, but the harness determines how it plans, interprets a result, retries, compresses the context, and finishes.

A more capable model in an overly permissive environment sometimes increases risk faster than productivity.

Define a unit of work

A long task must be bounded by a contract:

  • objective;
  • entrance;
  • expected artifacts;
  • acceptance criteria;
  • prohibitions;
  • budget;
  • duration;
  • owner;
  • final state;
  • escalation procedure.

Avoid open-ended goals like 'improve the project.' Prefer 'fix these three scenarios, add the tests, and produce a pull request without changing the data schema.'

The agent must be able to declare that it is stuck or that the criteria are contradictory.

Separate the harness from the compute

The harness orchestrates the conversation, the tools, the policy, and the state. The compute executes the commands in a sandbox: container, VM, isolated browser, or specialized environment.

This separation allows:

  • to replace the compute;
  • to limit resources and network;
  • to destroy the environment;
  • to preserve the useful state elsewhere;
  • to parallelize;
  • to resume after a breakdown;
  • to audit the actions.

The sandbox is ephemeral by default. Explicitly selected artifacts are copied into durable storage after inspection.

Architecture separating the agency harness, the model, the policy, the compute in sandbox, the tools, secrets, checkpoints, and supervision.

Apply the least privilege to tools

Each task receives a list of capabilities, not the user's full rights. The tools are classified:

  1. local reading;
  2. external reading;
  3. proposal;
  4. reversible writing;
  5. irreversible or high-impact action.

Reading a repository does not authorize publishing. Preparing an email does not authorize sending it. Generating a migration does not authorize executing it in production.

Permissions are temporary, limited to a resource, and revocable. An undeclared tool is inaccessible.

Control the network

Full internet access is rarely necessary. Plan for:

  • no network;
  • domain allowlist;
  • logged proxy;
  • limited downloads;
  • upload forbidden;
  • inspection of types and sizes;
  • controlled DNS resolution.

The downloaded content is unreliable. It is analyzed in a separate space and cannot modify system instructions.

The most dangerous scenario combines a malicious external source, a secret, a writing tool, and an outgoing network. The policy must prevent this composition.

Provide the secrets on demand

A secret is never written in the prompt or in the sandbox image. A broker issues a short token, limited to the action, with an audience and a duration.

The log indicates that an access occurred without recording the value. Secrets are revocable and renewable. Whenever possible, the tool performs the operation on behalf of the agent without giving them the raw secret.

An agent does not obtain production credentials to prepare a report.

Budgeting autonomy

A long task has several budgets:

  • time;
  • steps;
  • tokens ;
  • model calls;
  • cost;
  • CPU ;
  • memory;
  • storage;
  • network;
  • errors and retries.

As a limit approaches, the agent summarizes its state, saves the artifacts, and requests a decision. It does not automatically proceed with a higher expenditure.

Retries use backoff and idempotence. A permanent error is not repeated a hundred times.

Save useful checkpoints

The model context is not durable storage. A checkpoint contains:

  • objective and constraints;
  • common plan;
  • steps completed;
  • decisions;
  • modified files;
  • test results;
  • errors;
  • next action;
  • remaining budget;
  • version of the tools and the model.

The checkpoint is atomic and versioned. The recovery checks that the environment has not changed. If an action may have succeeded before the failure, an idempotency key or a state read prevents duplication.

Compacting memory without erasing constraints

On a long task, the context must be summarized. Poor compaction can lose a prohibition or a decision.

Separate:

  • immutable instructions;
  • verified facts;
  • decisions;
  • compressible history;
  • external artifacts;
  • tool results.

The summary is structured and controlled. Safety constraints are never present solely in a text produced by the model.

Detect loops and drift

The signals are:

  • same orders;
  • same mistakes;
  • files modified then canceled;
  • lack of progress;
  • expanding plan;
  • multiplication of tools;
  • cost without artifact;
  • acceptance criteria ignored.

The harness calculates progress indicators and stops after a number of cycles. The agent produces a diagnostic and asks for help.

Introduce approvals in the right places

Asking for confirmation on every read makes the system unusable. Never asking before a critical action is dangerous.

Typical doors:

  • access to new sensitive data;
  • adding a network domain;
  • use of a secret;
  • external writing;
  • sending;
  • publication;
  • expense;
  • deletion;
  • change of permissions;
  • passage into production.

The approval screen explains the action, the target, the data, the risk, the alternative, and the possibility of canceling.

Produce verifiable artifacts

The result should not be just a "task completed" sentence. It includes:

  • files;
  • diff ;
  • report;
  • sources;
  • tests ;
  • synthetic logs;
  • decisions;
  • limits;
  • unfinished elements.

Artifacts go through malware, secret, format, and size checks before leaving the sandbox.

Observe without recording everything

Logs are used to understand errors, but may contain data. Separate:

  • metrics;
  • tool events;
  • decisions;
  • masked prompts;
  • sensitive content;
  • artefacts.

Retention depends on the risk. The teams have a table showing active tasks, budgets, blockages, errors, approvals, and kill switch.

Testing adverse behaviors

The mandatory scenarios include:

  • malicious instruction in a document;
  • link to an unauthorized domain;
  • exfiltration attempt;
  • destructive command;
  • secret displayed by mistake;
  • loop;
  • false success;
  • break in the middle of writing;
  • resumption with a different version;
  • tool unavailable;
  • budget overrun.

The test checks the entire system, not just the model's response.

Design the kill switch and the revocation

The operator must be able to:

  • suspend a task;
  • cut the network;
  • revoke the tokens;
  • freeze the artifacts;
  • stop a class of tasks;
  • revert to a version;
  • to prevent new executions.

The procedure is tested. A button not connected to the computer does not constitute a stop.

Choose the appropriate tasks

The best first cases are bounded, verifiable, and reversible: document analysis, test preparation, sourced reporting, file transformation, or proposal for modification.

First avoid financial actions, decisions about people, overall administration, or autonomous publication.

Partitech can build the harness, the sandboxes, the tool gateway, the policies, the checkpoints, and the observability. The goal is not an agent that "can do everything," but a platform capable of proving what it has done, limiting what it can do, and properly recovering when it fails.

Let's talk about your project

Design and secure a long-term agent platform with Partitech. Contact Partitech.

Share this article