ACAgentic Craft

Advanced~14 minHazelJS

Agent Sandbox

Reduce blast radius for HazelJS agents using session/tenant isolation, curated tools, and policy—without claiming an unreleased OS/container sandbox product.

Authors
editorial-team
Published
Last reviewed

Problem

Code-execution, browser, filesystem, or broad MCP tools expand RCE and data-exfiltration risk when the model can reach them.

Context

Agents that might run code, hit untrusted URLs, or touch shared credentials. HazelJS today documents session/tenant isolation and tool curation—not a dedicated sandbox runtime package.

Forces and constraints

  • Product wants powerful tools
  • Security needs isolation boundaries
  • Inventing a fake ‘sandbox API’ creates false confidence
  • Skillgate/MCP exports are easy to over-broaden

Recommended design

Compose isolation from verified pieces: (1) separate AgentIdentity + capabilities per trust tier, (2) Skillgate/MCP curated registries (no shell/SQL by default), (3) Guardrails on tool I/O, (4) sessionId / tenant guards for data plane isolation, (5) HITL on irreversible tools, (6) run high-risk tools in a separate worker/network identity if your infra provides it. Document explicitly that OS/container/browser sandbox products are out-of-scope until HazelJS ships them.

Minimal pseudocode

// Trust-tier agent — no high-risk tools on the registry
const gate = Skillgate.fromOpenApi(spec, { include: { tags: ['safe-read'] } });
const registry = new ToolRegistry();
gate.register(registry, 'reader-bot');

// Separate high-risk worker identity (infra-level), not model-owned creds
const runtime = new AgentRuntime({
  toolRegistry: registry,
  policyEngine: new PolicyEngine([
    { id: 'deny-shell', tool: 'shell', effect: 'deny', priority: 100 },
  ]),
});

await runtime.execute('reader-bot', goal, {
  // session isolation where memory/docs document sessionId
  maxSteps: 6,
  budget: { maxTokens: 20_000 },
});

Failure modes

  • Labeling ‘sandbox’ while exporting admin MCP tools
  • Shared service account across trust tiers
  • Assuming guardrails stop RCE from a code-exec tool
  • Session isolation without tenant auth on HTTP

Security considerations

  • Never give the model raw cloud credentials
  • Network-egress allow-lists at infra for high-risk workers
  • Separate DNA/capability sets per trust tier

Observability signals

  • Tag runs with trustTier
  • Alert on denied high-risk tool proposals
  • Audit MCP server exports

Evaluation approach

Penetration-style tests: prompt attempts to reach denied tools; confirm deny + no side effect. Registry snapshot tests for unexpected tools.

Trade-offs

  • Strong isolation slows feature velocity
  • Weak isolation is faster and incident-prone

Sources

Related patterns