Closed-Loop Execution and Security Isolation for AI Agents

1. From Talking to Acting

In recent years, the main output of large language models has been text. Developers read the answer and then decided whether to act on it. Now more and more agents can call tools directly: operating robotic arms, reading and writing files, sending network requests, and calling APIs. As capabilities grow, the nature of the risk changes. If a model says something wrong, a person can ignore it. If a model does something wrong, the result may already have happened, and undoing it can be costly.

This article uses a real long-running physical task as a case study to discuss three engineering questions: how to let an agent complete complex tasks unattended, how to estimate its running cost, and how to set safety boundaries for it.

2. Case Study: An Unattended Painting Task

One developer had an agent control a robotic arm overnight to paint an autumn tree. When the work reached the canopy, the system found that the paint set lacked transition colors. It did not stop. Instead, it split the task into subtasks: it switched to another palette and mixed the intermediate colors one cell at a time. After mixing each cell, it took a photo with a camera and compared the result with the target color sample. Only after a comparison passed did it return to the canvas to continue.

The whole process involved more than 300 movements and took about four and a half hours. The case highlights three points.

First, tasks must be decomposable. “Paint a tree” is a vague goal, while “mix a specific intermediate color and verify it” is a subtask with a clear end condition.

Second, every step has external observation. The camera image provides a feedback signal that is independent of the model’s reasoning, so the system does not rely only on its own judgment.

Third, gaps can be found and filled during execution. A plan does not need to be perfect from the start. What matters is that the verification mechanism exposes deviations in time.

The following pseudocode shows the basic structure of this kind of execution loop:

while not task_done(goal):
    state = observe()                  # Read sensor or camera data
    gap = diff(state, goal)            # Find the difference between the current state and the goal
    if gap is None:
        break
    subtask = plan(gap)                # Split the gap into executable subtasks
    result = execute(subtask)          # Call the robotic arm or another actuator
    verified = verify(observe(), subtask.expected)
    log(subtask, result, verified)     # Record each step for later review
    if not verified:
        retry_or_escalate(subtask)

3. Key Design Points for Closed-Loop Verification

The core of a closed loop is that verification must happen independently after execution. Common practices include the following.

1. Perception checks: Use sensors or image comparison to confirm the physical state. For color tasks, a simple color-space distance can screen results first, and more precise metrics can then review them.
2. Result assertions: Define the expected outcome of each subtask in advance, for example, “the mixed color falls within a certain color difference range.” Define assertions before execution so that the process is not explained after the fact based on the result.
3. Independent review: Send key checkpoints to another model or a rule engine. This reduces systematic bias from a single source of judgment.

Verification thresholds depend on the scenario. A painting task can tolerate some color difference, while an assembly task may require millimeter-level precision. If the threshold is too loose, errors pass silently. If it is too strict, the system can get stuck in endless retries. Set an upper limit on retries, and hand the task to a human once that limit is exceeded.

Logging matters just as much. Each action should record its inputs, outputs, verification result, and timestamp. When something goes wrong, this log is the only reliable basis for tracing what happened.

4. Running Cost Accounting

The cost of an unattended task usually has three parts: inference call fees, the occupancy cost of execution equipment, and the compute cost of verification. You can estimate it with this formula:

Total cost ≈ number of inference calls × cost per call + device runtime × device hourly cost + number of verifications × cost per verification

The value of this formula is that it turns “it ran all night” into a number you can compare. For example, if verification steps run too often, inference costs rise noticeably. Developers can reduce cost by cutting unnecessary repeated observations, caching confirmed states, and merging adjacent small steps.

Cost estimates must also include failed retries. The higher the failure rate, the closer the actual cost comes to the upper bound. Recording retry counts together with failure causes shows where optimization should start.

5. Security Boundaries: Sandboxes and Network Egress

The more capable an agent is, the more it needs clear permission boundaries. Agent risk comes mainly from three sources: what the agent can access, what it can change, and whether it can send information outside.

5.1 Network Access Denied by Default

For research, code analysis, or internal testing, the execution environment should have no external network access by default. Processes in the sandbox can reach only explicitly listed resources. Isolation layers usually include the following:

• Process and filesystem isolation, mounting only the necessary directories, read-only by default
• Network namespace isolation, with no egress route by default
• Resource quotas that limit CPU, memory, and runtime duration

5.2 Egress Control, Including DNS

Many people focus only on HTTP egress and overlook DNS resolution. DNS queries alone can carry information. Data can be encoded in query names, and a resolver can forward it to an external server. If an egress policy checks connections but not queries, it leaves a covert channel open.

In practice, you should:

• Allow access only to internal resolvers, and block direct access to external resolution services.
• Match resolution requests against an allowlist, and reject non-allowlisted domains outright.
• Monitor unusual queries, such as overlong labels, high-frequency random subdomains, and large numbers of distinct query names.
• Retain DNS logs and network logs together for auditing.

Below is a sample policy:

policy:
  network:
    default: deny
    dns:
      resolvers: [internal-resolver]
      allow_domains: [docs.internal.example, pkg.internal.example]
      max_label_length: 40
      rate_limit_per_minute: 30
    http:
      allow_destinations: []

5.3 Temporary Authorization and Automatic Revocation

Authorization should be specific to the task, its scope, and its time limit. For example, “allow access to one group of internal documents for 15 minutes” is easier to control than “allow internet access.” When the time limit expires, permissions should be revoked automatically, and the execution environment should be destroyed or reset.

Circuit breakers are also necessary. On consecutive failures, unusual network behavior, or exceeding the time limit, the system should pause immediately and raise an alert rather than wait for a person to notice.

5.4 Confirmation for Irreversible Actions

Actions such as deleting data, sending external messages, changing permissions, and controlling physical devices should require human confirmation before execution. The agent can generate the plan and a preview, but a person approves the final step. This matters most in unattended settings, where no one may be present to correct mistakes afterward.

6. Implementation Checklist

• Can the task be split into subtasks with clear end conditions?
• Does each subtask have an observation or verification that is independent of the model?
• Is there an upper limit on retries, and is the task handed to a human when the limit is exceeded?
• Does every action have a complete log?
• Is running cost estimated by category: inference, equipment, and verification?
• Is the network denied by default, and is DNS resolution included in egress control?
• Do permissions have a defined scope and time limit, and are they revoked automatically on expiry?
• Do irreversible actions require human confirmation?