How to give your AI agent a secure computer

An agent that only calls a model can reason about work, but it cannot compile code, inspect a repository, manipulate files, run a browser, or keep a development process alive. Adding those capabilities creates a new security boundary because model-directed activity becomes real computation with access to infrastructure and data.

To give your agent a computer, connect its orchestrator to a separately managed, isolated execution environment with a defined image, resources, filesystem, network policy, credentials, lifecycle, and audit trail. This guide explains that architecture, when to use it, how to build it on Northflank, and which enterprise controls must stay outside the model.

Give your agent a computer by provisioning an isolated sandbox through an API, exposing bounded computer operations, and destroying or pausing the environment when the task ends.

• Keep model orchestration and policy enforcement outside the execution environment.
• Give the agent typed operations for creating a computer, running commands, moving files, checking status, and ending the session.
• Select a task-specific image and enforce limits for CPU, memory, storage, processes, duration, network use, and concurrency.
• Start with an ephemeral filesystem. Add explicitly owned persistent storage only when the task must resume or retain artifacts.
• Use scoped credentials, restricted networking, correlated telemetry, and an independent containment path for every run.

An agent computer is an execution environment that the agent controls through a constrained interface, not an unrestricted shell inside the agent service.

The model may decide that a task requires cloning a repository, running tests, or creating a file. The orchestrator turns that proposal into a structured request. A policy layer checks whether the caller and agent may perform the operation. Only then does a sandbox control API create or operate the isolated environment.

This practical component model keeps responsibilities clear:

The computer must not inherit the developer's permissions.

An agent needs a computer when its work requires general-purpose execution that cannot be represented safely as a small set of narrow API calls.

Examples include coding agents that inspect repositories and run tests, data agents, browser agents, and evaluation workers. Custom packages, long-running processes, build tools, or GPUs can also require a complete runtime.

Do not provide a computer by default. For one approved business operation, a typed API gives the agent less authority and a smaller failure surface. Use a sandbox when flexible execution is part of the job, especially for generated code, user files, unfamiliar repositories, or untrusted dependencies.

A safe agent computer architecture separates planning, authorization, execution, state, and operational control. This six-part design is a practical reference.

Run the model loop and policy checks in a service that the sandbox cannot modify. If generated code compromises the execution environment, it should not be able to rewrite the orchestrator, grant itself more tools, or suppress the event that terminates the run.

Pass only the task context the runtime needs. Return stdout, stderr, exit status, selected artifacts, and health information through the control interface instead of letting the model treat the whole environment as trusted memory.

Give the orchestrator explicit operations such as create, exec, upload, download, status, pause, resume, and delete. Validate file paths, resource class, image, ports, timeout, and output size before execution. A typed exec operation that accepts arbitrary shell commands still grants general-purpose execution; its real boundary comes from runtime isolation, identity, network policy, credentials, and destination-side authorization.

Creation and deletion should be retry-safe. Before provisioning, persist a durable computer ID, owner, task ID, and expiry so a reconciliation worker can find ambiguous requests, retry deletion, and remove abandoned environments.

Start each computer from a controlled image containing the runtime and tools its workload needs. Pin important dependencies or image digests where practical, scan the supply chain, and rebuild images as fixes become available.

Define resource classes instead of letting the model request arbitrary capacity. Each class should bound CPU, memory, ephemeral storage, processes, execution time, network use, and optional GPU access. Tenant-level quotas should also constrain simultaneous computers and creation rate.

Use an ephemeral root filesystem unless the workload requires continuity. Export test reports, patches, logs, and other approved artifacts before deleting the computer. Keep business records in databases or object stores with their own authorization rather than turning a sandbox disk into a system of record.

Persistent workspaces are appropriate for coding sessions that pause and resume, but persistence changes the threat model. Retained repositories, caches, downloads, credentials, and generated files need a named owner, tenant boundary, retention period, malware or policy checks, and a deletion path. The guide to persistent versus ephemeral AI sandboxes covers that decision in more detail.

Treat access as a separate grant for each run. The policy layer should evaluate the initiating user, agent version, operation, target, arguments, environment, and required approval before issuing a task-scoped credential. Secret injection limits distribution; it does not stop receiving code from reading or misusing the secret. Use task-scoped credentials that the destination also authorizes and that operators can revoke independently.

Begin with no inbound exposure and no unnecessary outbound access. Allow only required registries, model endpoints, source hosts, and internal services. Keep metadata endpoints, cluster APIs, credential services, and unrelated tenant networks unreachable.

On Northflank BYOC, network policies must be explicitly configured: without ingress rules, same-project inbound traffic is allowed, and without egress rules, outbound traffic is allowed. Verify the available enforcement mechanism for the selected deployment. If your agent processes company data, the wider agent isolation architecture explains why runtime separation must complement source-system authorization.

Assign one correlation ID across the request, policy decision, sandbox, commands, approvals, artifacts, resource use, and termination. Capture content only where policy permits, and keep platform audit events distinct from application-level agent traces.

Containment must not depend on the agent cooperating. Operators need to terminate a computer, revoke credentials, block its network path, disable a tool or policy, quarantine retained files, and prevent a new run. Test those actions during prompt-injection, malicious dependency, resource exhaustion, approval-bypass, data-exfiltration, and sandbox-escape exercises. The AI-agent sandbox security checklist provides a fuller evaluation framework.

Enterprise governance should set maximum authority before runtime and show that the boundary worked for each task.

Increase autonomy only after representative tests show that prompt injection, malicious tool responses, malformed arguments, permission escalation, memory poisoning, approval bypass, data exfiltration, and sandbox escape attempts remain inside the intended boundary. A successful task is evidence of usefulness, not evidence that the computer is safe.

One use case for Northflank Sandboxes is giving an AI agent a secure computer: generated or untrusted code runs inside an isolated environment created from a container image. The Northflank sandbox guide explains its complete setup and lifecycle.

The workflow has four steps:

1. Choose where it runs. Create a project on Northflank Cloud or a compatible BYOC cluster.
2. Authorize your application. Use an API token whose RBAC role permits the required sandbox operations.
3. Create and start the sandbox. Select the container image, startup command, temporary storage, runtime variables, and CPU and memory plan. Because creation is asynchronous, wait for the deployment status to reach COMPLETED before executing commands; treat FAILED as an error and enforce a readiness timeout.
4. Run the task and end the session. Use the exec API to run commands and collect the command's standard output, error output, and exit code. Then pause or delete the sandbox.

For files that must survive restarts or pauses, attach a persistent volume. Pausing scales the sandbox to zero while keeping its service configuration and volume intact; resume it by scaling back to one instance. Permanent cleanup requires deleting the service and retained volume separately.

Northflank combines isolated execution with the infrastructure around the agent. Teams can control sandboxes through the REST API, CLI, or JavaScript client, while running orchestrators, services, databases, jobs, storage, and GPU workloads on the same platform.

On supported infrastructure, Northflank uses Kata Containers with KVM-backed microVMs through Cloud Hypervisor. Where nested virtualization is unavailable, Northflank may use gVisor, a user-space-kernel isolation model rather than a microVM. GPU workloads on Northflank Cloud use gVisor by default. Choose the provider, region, and node-pool configuration that meets your threat model.

Deployment can use managed Northflank Cloud, a new Northflank-managed Kubernetes cluster provisioned in your own cloud account and VPC through self-serve BYOC, or an eligible existing Kubernetes cluster your team operates and connects through BYOK. Runtime availability depends on provider, region, hardware, and cluster configuration. BYOK also requires a reachable Kubernetes API, so on-premises placement does not mean air-gapped.

Enterprise controls include scoped API roles, secret injection, private networking, and token-specific audit feeds on Enterprise plans. These complement application-level policy and agent traces. Compatible agents can use Northflank Skills through their assigned permissions.

Not necessarily. An agent computer is a functional boundary: isolated compute, processes, files, networking, and lifecycle operations exposed to an agent. Its implementation may use a microVM, a user-space-kernel sandbox, or another isolation model appropriate to the threat.

No. Agents that only call narrow, well-authorized APIs may not need general-purpose execution. Use a separate sandbox when the task requires flexible code, shell, file, repository, browser, dependency, or process access. Decide whether to allocate one environment per task, session, user, or tenant from the data boundary and threat model.

It depends on the workload. Ephemeral environments simplify cleanup for independent tasks. Persistent volumes help coding and research sessions resume, but retained state needs explicit ownership, access, retention, scanning, and deletion controls.

Not as unrestricted access by default. Allow the destinations and protocols required for the task, inspect or broker sensitive paths where appropriate, and keep metadata services, control planes, credential endpoints, and unrelated internal networks unreachable.

• AI-agent sandbox security checklist: What enterprises should evaluate
• Persistent vs ephemeral AI sandboxes
• How to isolate AI agents that have access to company data
• How to scale AI-agent sandboxes for high-concurrency workloads
• How to deploy an AI agent from sandbox to production