The core risk in one sentence
A hosted agent that carries a static, ambient cloud credential into someone else's infrastructure turns every isolation guarantee the vendor sells you into a single point of failure — the credential, not the sandbox, becomes the actual boundary.
The eight-step checklist
1.Decide build vs. buy before you evaluate any vendor
A third-party sandbox or VM provider usually wins when you don't have a dedicated platform team to build and patch isolation infrastructure, when you need agents isolated from your own production environment rather than sharing it, when usage is bursty and you don't want to own idle capacity, or when you want a vendor's dedicated isolation expertise instead of rolling your own. In-house hosting usually wins when you already run a container or VM platform your team maintains, when the workload touches data that can't leave an environment you control, or when data-residency rules constrain where it can physically run. Most teams land somewhere hybrid: a third-party sandbox for lower-risk, bursty, or dev/test agents, and in-house hosting for anything that touches regulated production data.
2.Pick an isolation model on purpose, not by default
Every hosting option draws an isolation boundary somewhere, and where that boundary sits determines what a compromised or misbehaving agent can actually reach. Don't accept whatever a vendor's marketing name implies — ask what runs under the hood (container, microVM, user-space kernel, WASM sandbox, or full VM) and what it protects against. See the comparison below.
3.Give every hosted agent its own identity — never an ambient cloud credential
Don't bake a long-lived AWS, GCP, or database key into the sandbox image. Each agent gets its own identity and short-lived, narrowly scoped credentials issued per session or per task, so a compromised sandbox yields a token that expires in minutes and was never able to do more than that one agent's job required.
4.Put a broker in your own network between the sandbox and your data
Rather than handing the hosted sandbox direct network access to your systems, route its data calls through a broker or proxy that runs inside your own network. The broker authenticates the specific agent and task, issues a scoped, short-lived credential for that one call, and enforces an egress allowlist so the sandbox can only reach the hosts it's declared it needs — nothing else, even if the agent (or an injected prompt) asks for it.
5.Default every data path to read-only; gate writes behind human approval
Most of what an agent needs to do its job — search, read, summarize, draft — never requires write access. Grant read-only scopes by default and require an explicit, logged human approval before any write, delete, or send action reaches production data, especially anything regulated.
6.Treat the agent's memory store as governed data, not scratch space
A memory or retrieval store (conversation history, retrieved documents, embeddings) accumulates real enterprise data over time even when no individual write looks sensitive. Know what's in it, which agents and tenants can read from it, whether it can hold regulated data (PHI, PII, credentials), and whether writes to it go through the same approval and audit path as writes to your primary systems — a shared memory store is a shared blast radius.
7.Run vendor due diligence like you would for any subprocessor
A hosting or sandbox vendor that touches your data (even transiently, even just in memory) is a subprocessor, and it should go through the same review as any other one. At minimum, ask for a current SOC 2 report, whether they'll sign a BAA or DPA, where data resides at rest and in transit, how long VM snapshots and disk images are retained after a session ends, what their actual tenant-isolation model is, whether a bring-your-own-cloud or bring-your-own-VPC option exists, their breach history, and who their own subprocessors are.
8.Once it's live: inventory, tamper-evident logs, drift monitoring, and a kill switch
Hosting is a decision you make once; operating it is ongoing. Keep an accurate inventory of every agent you've deployed and where it runs, record each run to a log that can't be quietly rewritten, alert when an agent's behavior or egress pattern drifts from its baseline, and make sure every agent has a kill switch you've actually tested — not just one you assume works.
Isolation models compared
"Sandbox" covers a range of real isolation strengths. Ask a vendor which of these actually runs under their product name before you compare pricing.
| Model | What it protects | Watch out for |
|---|---|---|
| Container (namespaces + cgroups) | Process, filesystem, and network isolation from the host process tree. | Shares the host kernel — a kernel exploit or container-escape CVE can reach every tenant on that host. |
| MicroVM (lightweight, hardware-virtualized) | Own kernel and a virtualized hardware boundary per workload, with container-like startup speed. | Still shares a physical host and hypervisor with other tenants; rarer than a container escape, not impossible. |
| User-space kernel (syscalls intercepted in user space) | The workload never talks to the real kernel directly — syscalls are re-implemented in a sandboxed layer. | Narrower syscall compatibility can break agent tooling that expects a full Linux surface; added syscall overhead. |
| WASM / WASI sandbox | Capability-based sandbox with no ambient filesystem, network, or host access unless explicitly granted. | Agent-framework and native-dependency support is still maturing — not every tool compiles to WASM yet. |
| Full VM (dedicated hypervisor-backed) | Strongest boundary — separate kernel and hardware virtualization, often with a hard multi-tenancy guarantee. | Slower to provision and scale, and typically the most expensive option per agent run. |
Cheat sheet
- •Build vs. buy: no platform team, or need isolation from prod → third party. Regulated data that can’t leave your environment → in-house.
- •Isolation: pick container / microVM / user-space kernel / WASM / full VM based on what you need to protect against — don't take the vendor's default.
- •Identity: one identity per agent, short-lived scoped credentials — no static keys, no ambient cloud credentials baked into the sandbox.
- •Data path: broker/proxy in your own network, an egress allowlist, read-only by default, human approval before any write.
- •Memory: know what's stored, who and what shares it, whether it holds regulated data, and who controls writes to it.
- •Vendor diligence: SOC 2 report, BAA/DPA, data residency, snapshot retention, isolation model, bring-your-own-cloud option, breach history, subprocessors.
- •Operations: an agent inventory, a tamper-evident run log, drift/health alerts, and a kill switch you’ve actually tested.
Where KollGuard fits — and where it doesn't
KollGuard doesn't host, run, or sandbox your agents, and it doesn't enforce anything at the infrastructure level — you keep hosting and running them, in-house or with a third-party provider. What it does is govern and watch them: an agent inventory and hash-chained, tamper-evident run log via Agent Watch; least-privilege checks against each agent's declared tools and scopes; a declared egress allowlist compared against what an agent actually reports contacting; opt-in output scanning for secrets and PHI indicators (samples are scanned in memory and never stored); and a kill switch per agent. On the vendor side, Vendor Watch keeps a register of your hosting and sandbox providers with web-verified breach and SOC 2 checks, subprocessor chain tracking, BAA tracking, and security questionnaires — so the due-diligence list above doesn't live only in a spreadsheet.
Frequently asked
- Should I host AI agents myself or use a third-party sandbox?
- It depends on what you have and what the agent touches. A third-party sandbox makes sense when you lack a dedicated platform team, need isolation from your own environment, expect bursty usage, or want the vendor's isolation expertise. In-house makes more sense when you already run container/VM infrastructure, or when data-residency or regulatory constraints mean the workload can't leave an environment you control. Many teams run both, split by risk.
- What isolation model is safest for running AI agents?
- There's no single safest option — a full VM gives the strongest isolation but costs the most and is slowest to provision; a container is fast and cheap but shares the host kernel; microVMs, user-space kernels, and WASM sandboxes sit in between with different trade-offs. Pick based on what you're protecting against, and confirm what actually runs under a vendor's marketing name rather than assuming.
- How does a hosted agent get access to our enterprise data if it's running on a third party's infrastructure?
- The pattern that holds up: give the agent its own identity, issue short-lived scoped credentials per task instead of a static key, route data calls through a broker or proxy in your own network with an egress allowlist, never bake ambient cloud credentials into the sandbox image, default to read-only, and require human approval before any write reaches production data.
- Is an agent's memory store in scope for SOC 2 or HIPAA?
- If it can hold regulated data (PHI, PII, credentials) or is shared across agents or tenants, yes — treat read and write access to it the same way you'd treat access to any other production data store, with the same approval and audit expectations.
- What should we ask a sandbox or agent-hosting vendor before signing?
- A current SOC 2 report, whether they’ll sign a BAA or DPA, where data resides at rest and in transit, how long VM snapshots and disk images are retained after a session ends, their actual tenant-isolation model, whether a bring-your-own-cloud or bring-your-own-VPC option exists, their breach history, and who their own subprocessors are.
- Is there a cheat sheet for agent hosting and deployment?
- Yes — see the compact checklist on this page: decide build vs. buy, pick an isolation model on purpose, give every agent its own identity with short-lived scoped credentials, route data through a broker with an egress allowlist and read-only defaults, govern the memory store, run vendor due diligence, and keep an inventory, a tamper-evident log, and a tested kill switch once it's live.
- Does KollGuard host or run our AI agents?
- No. KollGuard doesn't host, run, or sandbox your agents, and it doesn't enforce anything at the infrastructure level — you keep hosting and running your agents yourself, in-house or with a third-party provider. What KollGuard does is govern and monitor them: an agent inventory (Agent Watch), a hash-chained tamper-evident run log, least-privilege checks on each agent's declared tools and scopes, a declared egress allowlist compared against what an agent actually reports contacting, opt-in output scanning for secrets/PHI indicators (samples are never stored), and a per-agent kill switch. On the vendor side, Vendor Watch keeps a register of your hosting and sandbox providers with web-verified breach and SOC 2 checks, subprocessor chain tracking, BAA tracking, and security questionnaires.