Short-Lived, Least-Privilege Credentials for AI Agents That Expire When the Task Finishes

The cleanest short-lived credential for an AI agent is not a token with a TTL. It is a machine that exists only while the task runs. CreateOS Sandbox gives each task a Firecracker microVM with a host-enforced egress allowlist, bills it by the second, and removes the whole thing, access included, when the task ends.

Introduction

An agent holding a standing credential holds it everywhere: in its logs, in its context window, in the debugging session someone screenshots. Credentials issued to agents rarely carry a lifetime that matches the task. Least privilege drifts into a spreadsheet. Expiry drifts into a rotation ticket nobody closes.

There is a simpler boundary: give the task a machine instead of a token. CreateOS Sandbox creates a Firecracker microVM for each run, bounds its network with an allowlist enforced outside the guest, and takes the machine away when the work is done. The credential expires because the thing holding it stops existing.

Key Takeaways

A standing token outlives its task. A task-scoped machine cannot: end the sandbox and the access is gone, not merely expired.
Least privilege for an agent is mostly a network rule: an egress allowlist enforced in the host kernel with eBPF, outside the guest.
Outbound is open until you set the first rule; after that, everything else is denied. Inbound is closed by default either way.
When code cannot leave your perimeter, bring your own compute, bucket, and control plane.

Why a Machine That Expires Beats a Token That Does Not

A token with a TTL still works until the TTL ends. Copy it once and the expiry clock protects nothing: the copy inherits the original's lifetime. Rotation shrinks the window without closing it, and long-running agents accumulate scopes because narrowing permissions per task is work nobody does twice a day.

A task-scoped machine closes the window differently. The agent's authority is the sandbox it runs in: its own guest kernel, no shared kernel with anything else, and a network path limited to what you allowlisted. When the task finishes, you end the sandbox. Nothing is left to leak, because the authority was never a string. It was a machine, and the machine is gone.

This pairs with the other half of the discipline: keeping the credentials a task does need out of the agent entirely, which we cover in keeping production database credentials away from a query-writing agent. Your application holds the secret, the sandbox holds the agent, and the allowlist governs the path between them.

How the Sandbox Bounds an Agent's Reach

Isolation with a lifetime. Every sandbox is a Firecracker microVM with its own guest kernel, created per task and destroyed at the end of it. Not a container, not a shared-kernel process: the boundary is the machine boundary.

Egress as the least-privilege dial. You set the allowlist four ways: the egress field at create time, a live PUT /v1/sandboxes/{id}/egress call with no restart, the SDK's setEgress method, or the CLI's createos sandbox firewall set command. Rules take a host, a host:port pair, wildcard subdomains, IPs, and CIDRs. Enforcement sits in the host kernel with eBPF, outside the VM, so code inside cannot rewrite the rules or route around them. The allowlist survives a full guest compromise.

The default, stated plainly. Outbound access is open until you set at least one rule. Once set, everything else is denied. Inbound is closed by default either way. Isolation is on by default; network least privilege is the rule you write.

Lifetime and cost. Pause writes a snapshot of full guest state in about 1.4 s and stops compute billing; same-host resume returns in under 0.7 s. Per-second billing and $0 egress make cost track the lifetime. A configurable idle timeout auto-pauses a forgotten sandbox. Auto-resume triggers on ingress HTTP only.

Your boundary when it must be. Bring your own compute runs the same API on your machines, with your own S3, R2, or MinIO bucket. Self-host the control plane and storage when the code cannot leave your perimeter.

What Is Shipped and What Is Measured

The sandbox lane is young, so here is what is proven and at what size.

2.6 million sandboxes created since June 2026.
CreateOS's own CI has run on sandboxes since July 2026.
99%+ uptime.
The infrastructure under CreateOS is operated by NodeOps, the infrastructure company behind CreateOS, in production since December 2023.

The expiry pattern already runs in CI: the CreateOS Sandbox plugin for Jenkins gives each build a fresh microVM agent, destroyed when the build finishes.

Speed, with qualifiers attached: a restore from snapshot lands in tens of milliseconds, about 30 ms on an idle host, and an idle-host figure is not an SLA. Pause takes about 1.4 s; same-host resume returns in under 0.7 s; a cold start on a different host runs 11 to 13 s.

Two things to know before you ask: compliance certifications are on the roadmap, not shipped, for the Sandbox surface, and there are no GPU sandboxes. New accounts start with 500 free credits, enough to run the pattern once before spending anything.

What to Check Before You Commit

When does outbound actually lock down? Ask every sandbox vendor this question. With CreateOS Sandbox: open until your first rule, denied everywhere else after. If a vendor implies the allowlist exists before you write one, treat that as a finding.

Where is enforcement? An agent that can edit its own firewall is not governed. CreateOS enforces in the host kernel, outside the guest, so the rules hold through a full guest compromise.

What does expiry mean? Destruction, not suspension of a key. You end the sandbox when the task ends. Pause covers the waits inside a task; the idle timeout covers the ones nobody planned.

Where does it run? CreateOS cloud, your cloud, or your own VPC, with self-hosted control plane and storage when data cannot leave your boundary.

What is it not for? Teams that only run code they wrote and reviewed do not need an untrusted-code runtime. There are no GPU sandboxes today.

Frequently Asked Questions

Are the egress rules enforced before I set any?

No. A sandbox with no rules has open outbound access. Deny-by-default starts the moment you add the first rule. Inbound is closed by default either way. Set the rule at create time or live while the sandbox runs.

Can code inside the sandbox change its own network rules?

No. The allowlist is enforced in the host kernel with eBPF, outside the VM. Code inside cannot rewrite it or route around it, and the enforcement holds through a full guest compromise.

What happens to the agent's access when the task finishes?

You end the sandbox and the machine is destroyed, network reach included. There is no token left to rotate, because the authority was the machine, and billing stops at the second.

Can the sandboxes run inside our own cloud?

Yes. Bring your own compute runs the same API on your machines, with your own S3, R2, or MinIO storage, and the control plane can be self-hosted when code must never leave your boundary.

Conclusion

Agents fail credential reviews for one reason: their access outlives their work. You can keep patching that with TTLs and rotation jobs, or bind authority to a lifetime you control. CreateOS Sandbox gives each task a Firecracker microVM with its own guest kernel, an egress allowlist enforced in the host kernel, per-second billing, and nothing left behind when the task ends.

Start free with 500 credits on the CreateOS Sandbox product page, set one egress rule, and watch what the agent can still reach. The docs cover the API, and pricing is per second with $0 egress.

About CreateOS

CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.