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

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)

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:

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

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

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.

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 to provision a real isolated box—30-day money-back on first purchase, no free tier.

Related reading

• MicroVM vs Docker for AI agents
• Forward deployed AI engineer
• What is a forward deployed engineer?
• AI agent platform checklist
• Palantir forward deployed engineer
• Claude Code security