# AI Agent Sandbox for Customer Deployments

> Customer-scoped agents need isolation and always-on, not a shared-kernel free-for-all. How FDEs should think about sandboxes, fleets, and production.

- Published: 2026-07-28 · Updated: 2026-07-29 · jurniti
- Canonical: https://www.jurniti.com/blog/ai-agent-sandbox-for-customer-deployments

An **AI agent sandbox for customer deployments** is not a toy REPL. It is the boundary that lets a forward deployed engineer put **tools + credentials + long-running work** in production without inviting the next customer into the same blast radius.

If you only remember one sentence: **ephemeral code execution ≠ always-on customer agent.**

This is the densest deploy-craft post in the FDE set. Role definition lives elsewhere; here we talk isolation models, when categories fail, always-on economics, BYOK, restore/fork, and a migration ladder you can run with a field team next week.

## What “sandbox” means in three different mouths

| Speaker | Often means | Fits always-on FDE agents? |
| --- | --- | --- |
| App platform | Short-lived code exec for a single tool call | Rarely |
| Security team | Network + FS + syscall jail | Necessary but not sufficient |
| FDE shipping fleets | Isolated guest that stays up with customer keys | Yes—if isolation + persist + restore exist |

Marketing collapses these. Production does not.

Kevin Bai’s public FDE 101 framing (Anthropic Applied AI; founding Rippling FDE; ex-Palantir) is load-bearing for *why* you need craft at all: sell **outcomes** on **platform primitives**, not 55 one-off systems. For agents, the runtime *is* one of those primitives. Attribute frameworks carefully; do not invent quotes.

## The FDE checklist for customer-scoped agents

Print this. Score each engagement before you ship credentials.

1. **Who can the agent reach?** tools, networks, data stores  
2. **Who can reach the agent’s secrets?** other tenants, host operators, side channels  
3. **What survives restart?** memory, files, config, local skill state  
4. **What is the restore story?** snapshot, rollback, fork  
5. **What is the cost model when the agent never sleeps?**  
6. **What is the handoff?** can a non-hero operate it  
7. **What is the audit trail?** who ran what, when, with which keys  
8. **What is the kill switch?** revoke tools, revoke keys, stop the guest  

If your “sandbox” only answers (1) for five minutes, it is not a customer deployment environment.

### Pass/fail rubric (use in design reviews)

| Question | Pass looks like | Fail looks like |
| --- | --- | --- |
| Isolation | Per-customer guest boundary | Shared home dir / shared kernel hope |
| Always-on | Guest stays up independent of laptops | Process dies when a human sleeps |
| Keys | BYOK inside tenant boundary | API keys in chat logs and personal shells |
| State | Persist volume + restore path | “We’ll just re-bootstrap” |
| Reuse | Template/fork for next logo | Copy-paste README from last engagement |
| Ops | Second person can run it | Hero-only tribal knowledge |

## Isolation models FDEs actually choose between

Ignore brand names. Choose **categories**.

### 1. Laptop fleets

**What they are:** personal or corporate laptops running agents, often with MDM if you are lucky.

**Why people start here:** zero procurement, fast demos, “it works on my machine.”

**Failure modes:**

- Airport / sleep / OS update ends the outcome  
- Credentials leave buildings on devices  
- Multi-customer hygiene is social, not technical  
- Impossible clean handoff when the FDE is sick  
- Security reviews either fail or never happen  

**Acceptable uses:** local development, short demos with non-production keys, personal experiments.

**Unacceptable as production:** anything with customer production credentials or multi-tenant obligations.

### 2. DIY VPS snowflakes

**What they are:** one (or many) virtual machines you provision and babysit per customer or per project.

**Why people graduate here:** always-on is possible; SSH is familiar.

**Failure modes:**

- Every logo becomes a unique ops novel  
- Patching, backups, and identity are optional until they are not  
- No template culture → setup tax compounds  
- Isolation quality equals your discipline that week  
- Restore is “hope the disk image exists”  

**Acceptable uses:** early always-on when volume is tiny and you will invest in runbooks.

**Still incomplete without:** snapshot/fork discipline, key standards, and a path to productized primitives.

### 3. Shared-kernel containers / density hosts

**What they are:** many agent processes or containers on one shared kernel for cheap density.

**Why people love them:** cost curves look friendly; orchestration is familiar.

**Failure modes:**

- Shared kernel means shared classes of escape and noisy-neighbor risk  
- Multi-tenant mistakes become multi-customer incidents  
- Security teams escalate when production keys land here  
- Density optimizes for the wrong unit when the unit is “customer trust”  

**Acceptable uses:** low-trust toys, internal batch jobs without production secrets, non-customer workloads.

**Stressful for:** production-credential customer agents under enterprise review.

### 4. Ephemeral sandboxes

**What they are:** short-lived execution environments for one-shot code or tool calls.

**Why they are excellent:** perfect for “run this code safely inside a product path.”

**Failure modes when misused as homes:**

- Always-on agents do not fit five-minute lifecycles  
- Metering punishes long-lived work  
- Memory and local state evaporate  
- Credential patterns get bolted on awkwardly  
- FDEs rebuild context every spin  

**Acceptable uses:** tool-call isolation inside an application, CI-style agent tests, untrusted code execution.

**Wrong category for:** inbox monitors, long-running ops bots, multi-day customer workflows with durable state.

### 5. Hardware-virtualized guests (microVMs)

**What they are:** per-tenant virtual machines with a **guest kernel** (Firecracker-class isolation is the teaching example).

**Why FDEs care:** different isolation story than packing many agents onto one shared kernel for density.

**What “good package” looks like in practice:**

- MicroVM per tenant / per customer scope  
- Persist volume for durable state  
- BYOK so model keys stay customer-boundary  
- Templates / fork so engagement two is not engagement one again  
- Flat economics that do not explode when the agent stays awake  
- Multi-harness option so the platform is not married to one agent brand  

That package is what [jurniti](/) sells as a managed service—not a free playground, not a framework, not a salary program.

## When ephemeral fails (scenarios)

### Scenario: “support triage agent” that must stay awake

Ephemeral sandboxes shine for one tool call. A triage agent that watches queues overnight is a **resident**. If the environment dies, the outcome dies. Prefer always-on isolated guests with persist.

### Scenario: “invoice exception agent” with ERP credentials

Keys in an ephemeral world tempt copy-paste into every run. Prefer BYOK inside a tenant boundary, least privilege tools, and a kill switch.

### Scenario: “week-long pilot” with memory and local files

If state evaporates on recycle, you re-pay discovery daily. Prefer persist + restore. Capture a template when the assembly works.

### Scenario: “second customer looks like the first”

Without fork, you rebuild. With fork, you start from a proven assembly and customize. This is the FDE anti-dev-shop rule applied to runtime.

## Always-on is a product requirement, not a flag

Always-on fails for boring reasons:

| Failure | Symptom | Fix category |
| --- | --- | --- |
| Human laptop sleep | Agent silent after 11pm | Dedicated guest |
| Process supervisor missing | Agent exits on error | Guest + service model |
| Host reboot | State gone | Persist + restore |
| Metered short sessions | Bill shock + forced stop | Flat always-on economics |
| No healthcheck | Silent degradation | Health + alerts |

FDE outcomes are often **time-shaped**: overnight processing, continuous monitoring, multi-day workflows. If your sandbox cannot stay up, you are selling demos.

## BYOK (bring your own key) without hand-waving

**BYOK** means the customer’s model API keys (and often other secrets) remain in a boundary you can defend in a security review—not in a shared vendor soup and not in an FDE’s personal shell history.

### Minimum BYOK discipline

1. Keys live in the tenant environment, not in chat  
2. Rotation path exists before go-live  
3. Revocation works without redeploying folklore  
4. Logs do not print secrets  
5. Operator access is audited and least-privilege  
6. No free-tier “shared key” temptation for production  

jurniti’s product stance is BYOK on isolated microVMs. That is a platform primitive for field teams assembling outcomes—not a claim that keys manage themselves.

## Restore, snapshot, and fork (the compounding loop)

Bai’s platform-primitives rule maps cleanly:

- **Bespoke to one customer** → stays on that customer’s guest / config  
- **Generalizable** → becomes a template or product feature  

Runtime version of the same loop:

1. **Assemble** on an isolated always-on guest  
2. **Prove** the outcome with real (scoped) credentials  
3. **Capture** the good state as a template  
4. **Fork** for the next logo  
5. **Promote** repeated integrations into your real product  

Without capture/fork, every engagement re-pays setup time. That is how FDE becomes a services firm with cloud bills.

### Anti-patterns

- Snapshot never tested for restore  
- Templates that include another customer’s secrets  
- Fork without re-keying  
- “Golden image” that is six months stale and unowned  
- Capturing root chaos instead of a clean assembly  

## How FDEs should choose per engagement

| Engagement shape | Prefer |
| --- | --- |
| One-shot code tool inside a product | Ephemeral sandbox product |
| Human IDE session | Cloud desktop / CDE |
| Always-on agent with customer credentials | Dedicated isolated guest (microVM lane) |
| Burst batch jobs with no secrets | Cheap workers / containers may be fine |
| Multi-customer fleet with production keys | Per-tenant isolation + templates + BYOK |
| Internal research bot, no customer data | Stricter than laptop; looser than enterprise guest |

Do not force one category to pretend it is another. That is how pilots die in security review—or worse, pass security review and fail in production.

## Category comparison matrix

| Criterion | Laptop fleets | DIY VPS | Shared-kernel density | Ephemeral sandboxes | MicroVM guests |
| --- | --- | --- | --- | --- | --- |
| Isolation story | Weak | Medium (discipline) | Weak–medium | Strong for short runs | Strong guest kernel |
| Always-on | Poor | Good if maintained | Possible | Poor as home | Good |
| Multi-customer hygiene | Poor | Medium | Risky | N/A if short | Designed for |
| Template / fork culture | Rare | DIY | Rare | Limited | Natural fit |
| BYOK realism | Chaotic | Possible | Awkward | Awkward | Natural fit |
| Ops tax | Hidden on humans | High | Medium | Low for short | Medium; managed option exists |
| Best for | Dev / demo | Early always-on | Low-trust density | One-shot exec | Production customer agents |

## A practical migration path for field teams

Run this ladder as a program, not a slogan.

### Step 1 — Inventory

Where do agents run today?

- Laptops (whose?)  
- DIY VPS (who has SSH?)  
- Shared hosts  
- Ephemeral paths  
- Already isolated guests  

List **customer names next to keys**. If that sentence makes you nervous, good—that is the point.

### Step 2 — Classify

For each agent:

- Always-on vs one-shot  
- Production credentials vs synthetic  
- Customer-scoped vs internal  
- Statefulness (files, memory, local tools)  

### Step 3 — Isolate production-credential always-on first

Do not start with the cute internal bot. Move the scary ones off shared laptops first.

Acceptance:

- Dedicated guest  
- Keys not on personal devices  
- Restart survives human sleep  

### Step 4 — Template the first good assembly

When one engagement works:

- Document tools, env, healthchecks  
- Capture template without foreign secrets  
- Name an owner for template freshness  

### Step 5 — Fork for the next logo

Second customer starts from template, not zero. Re-key. Customize. Measure time-to-outcome vs the first logo.

### Step 6 — Productize

Repeated integrations leave the guest folklore and enter your real product. Field becomes scouting again—exactly the healthy FDE loop.

### Step 7 — Kill snowflakes on a schedule

Every quarter, retire one unique host pattern. If snowflake count only grows, you are running a services backlog.

## Security review questions you should already own

Bring answers before the customer’s CISO invents them:

1. What is the isolation boundary between tenants?  
2. Who can access the guest and how is that audited?  
3. Where do model keys live and how are they rotated?  
4. What network egress is allowed?  
5. What data is persisted, where, and for how long?  
6. What is restore RPO/RTO in plain language?  
7. What is the incident path if a tool is abused?  
8. How do you deprovision a customer completely?  

If your stack cannot answer these, you do not have a sandbox for customer deployments—you have a demo environment with ambitions.

## Cost models: always-on vs metered theater

FDEs get burned by category mismatch in finance as much as in security.

| Model | Behaves well when… | Hurts when… |
| --- | --- | --- |
| Flat monthly always-on guest | Agent must stay awake | You only needed five-minute jobs |
| Per-second ephemeral | One-shot tool calls | Resident bots burn budget or die |
| DIY VPS “cheap” | Single instance, skilled ops | Human time + incidents dominate |
| Laptop “free” | Dev only | Lost machines + outages + key risk |

Prefer **economics that match the engagement shape**. Always-on outcomes on ephemeral pricing is a category error.

## Soft third way: managed microVMs still yours

You can build the isolation layer yourself. Many teams should—until the ops tax exceeds the product tax.

jurniti is the managed option: **Firecracker microVMs**, multi-harness catalog, BYOK, always-on shape, persist + templates/fork, first-purchase **30-day money-back**, **no free trial or free tier**. FDEs stay on outcomes; the host layer stops being a snowflake hobby.

Reader is the hero. The platform is a primitive. Buy or build—but do not ship production keys on a laptop fleet and call it “agile.”

### Build vs buy checklist

**Build when:**

- Isolation is core IP you will fund for years  
- Compliance requires custom control planes  
- You already run a mature multi-tenant fleet org  

**Buy managed when:**

- Your product is agent outcomes, not hosts  
- Field volume is rising and snowflakes are multiplying  
- You need multi-harness without rewriting ops each time  
- You want flat always-on economics without inventing billing  

## Worked engagement plan (two-week pilot)

**Days 1–2 — Scope outcome**  
Name the business metric. List tools and data. Forbid production keys on laptops.

**Days 3–4 — Choose category**  
If always-on + production credentials → isolated guest lane. If one-shot code tool → ephemeral.

**Days 5–7 — Assemble on primitives**  
BYOK, least privilege tools, healthcheck, kill switch. Write the handoff doc while building.

**Days 8–9 — Security pass**  
Answer the eight review questions. Fix egress and logging first if needed.

**Days 10–12 — Production-shaped run**  
Stay up overnight. Practice restart/restore. Capture template.

**Days 13–14 — Review**  
Time-to-outcome, open risks, what productizes. Schedule fork for logo two.

## Anti-pattern gallery (name them in retros)

1. **Demo keys forever** — synthetic keys that never graduate, so “production” never happens  
2. **Shared home directory multi-tenancy** — folders as isolation  
3. **ChatOps secret store** — tokens in messages  
4. **Hero laptop HA** — high availability equals one human online  
5. **Ephemeral cosplay** — short-lived envs forced to act as homes  
6. **Template with secrets** — fork becomes a data leak  
7. **No kill switch** — agent keeps acting after trust expires  
8. **Infinite snowflake** — every logo is a new novel  

## Get the free series

FDE 101 covers role definition, when you need the function, primitives vs services traps, and deploy craft for agent fleets—including sandboxes that actually fit customer deployments.

[See pricing](/pricing) to provision a real isolated box—30-day money-back on first purchase, no free tier.

## Related reading

- [MicroVM vs Docker for AI agents](/blog/microvm-vs-docker-agent-hosting)
- [Forward deployed AI engineer](/blog/forward-deployed-ai-engineer)
- [What is a forward deployed engineer?](/blog/what-is-a-forward-deployed-engineer)
- [AI agent platform checklist](/blog/ai-agent-platform)
- [Palantir forward deployed engineer](/blog/palantir-forward-deployed-engineer)
- [Claude Code security](/blog/claude-code-security)

## Frequently asked questions

### What is an AI agent sandbox in a customer deployment?

A bounded runtime where an agent can use tools and data without unrestricted access to other customers or the host. Production deployments also need always-on shape, key custody, and restore—not only short-lived code execution.

### Are ephemeral code sandboxes enough for FDE work?

They are excellent for one-shot execution inside an app. They are a poor fit for always-on agents that must hold credentials, memory, and long-running workflows.

### What isolation should FDEs demand?

Prefer hardware-backed guest isolation for production credentials. Shared-kernel containers maximize density; they also share blast radius.

### What fails first when teams improvise with laptops or VPS?

Key hygiene and multi-customer blast radius fail first; then always-on reliability; then restore/fork when the first good assembly is lost.

### What is BYOK and why does it matter?

Bring-your-own-key keeps model API credentials in the customer boundary. Without it, key custody becomes a shared liability and security reviews stall.

### How does jurniti implement this?

Each tenant runs in a Firecracker microVM with a persist volume and BYOK. Templates and forks help FDEs reuse a proven customer assembly. Multi-harness catalog, flat monthly plans, no free tier.

### Is there a free sandbox tier?

No free trial or free tier. First purchase has a 30-day money-back guarantee so you evaluate a real isolated box.

### What is a practical migration ladder off laptop fleets?

Inventory → classify always-on vs one-shot → isolate production-credential agents first → template the first good assembly → fork for the next logo → productize repeated integrations.