Safety and isolation

The safety you get under every agent — the policy controls you own, sandboxed code, spend limits, platform protections, and isolation between agents, subscribers, and accounts.

An agent that talks to strangers, spends money, and runs code needs more than a well-written prompt. This page describes the safety you own and the protections the platform provides underneath it.

The controls you own

Your policy is enforced by the platform, not just requested in the prompt. You have four layers, each acting at a different point:

Layer	What it does
Rules and purpose	Your Rules and Purpose are applied on every turn, and an optional judge scores each answer against your criteria
Tool parameter guards	Reject a bad tool call with a fix-it message, or silently pin, clamp, or normalize arguments — or block a tool outright
Blocking hooks	Your endpoint can halt a request, rewrite the prompt or a tool call, redact a result, or replace the final response
Consent gates	confirm_action / commit_action require a real user confirmation before a destructive action — the model can’t proceed by claiming the user agreed

A subscriber can tighten your rules for their own instance but never loosen them, and every tool — built-in, custom, MCP, connector, OpenAPI, or skill — passes through the same guards. For conversation-level control, your agent can escalate to a human, and you can take over a live conversation from the Inbox — see Multi-agent orchestration.

Sandboxed code

Every piece of code you author — custom code tools, event actions, per-goal Goal Checks, and event pre-processors — runs in an isolated sandbox, never inside the platform. The built-in execute_code tool runs there too.

Your code has no access to platform environment variables and no access to the platform filesystem.

The limits your code runs under:

Surface	Runtime	Limits
Custom code tools	Python or JavaScript	30 s, ~512 MB, up to 50 built-in-tool calls per run
Goal Checks	Python or JavaScript	Same isolated sandbox
Event pre-processors	Python or Node	~512 MB, ~30 s
Event actions	Python or JavaScript	Fire-and-forget: never block the agent

Your code reaches built-in tools only through the ctx bridge, and every call it makes goes through the same guards, billing, and logging as the model’s own tool calls. On public pages, embed blocks render inside sandboxed frames and uploaded SVG images are served isolated with scripts disabled.

Spend limits

Spend is bounded at every level, so no single runaway loop or hostile user can drain an account:

Limit	Scope	What you set
Per-turn limits	Every turn	Time, tool loops, tokens, and credits bound every turn — see How a turn executes
Response Limits	Per agent	Maximum answer time and tool loops (Purpose)
Subscriber budget	Per subscriber	A credit allowance with once / daily / weekly / monthly refresh
Ingress caps	Per channel instance	A credit cap per IM channel, email address, webhook, and schedule
Schedule budget	Per schedule	A cumulative spend cap; over-budget runs are skipped until the window resets
Outbound send cap	Per agent	A shared daily limit on email_send and im_send (Tools page)

Underneath every limit, your balance is the floor: a turn that runs out of credits stops rather than continuing to spend.

Platform protections

Underneath your controls, the platform protects your agent automatically:

• Inbound screening. Incoming messages are screened for prompt-injection and probing before your agent acts on them, and a hostile visitor learns nothing about what was detected.
• Untrusted content is framed. Retrieved passages, ingested documents, and uploaded files are clearly marked as data, not instructions, and anything your agent is about to remember is screened first — so a poisoned document can’t hijack your agent.
• Prompt-leak protection. Your agent’s output is screened so it doesn’t disclose its own configured prompt to a user.
• Abuse and cost protection. The platform blocks probing traffic at the edge and caps abusive usage before it reaches your account.

Isolation

• Per-agent data isolation. Each agent’s data is fully separated from every other agent and account.
• Per-contact memory. A subscriber’s visitors’ memories are private from the owner — a real boundary, not a hidden view. See User memory.
• Team roles. Collaborator grants carry per-area view/edit permissions, and anything without an explicit grant stays owner-only. Collaborator actions bill to the owner.
• Machine access. Management MCP keys are account-scoped and owner-only; per-agent API keys are scoped to their agent.
• Separate surfaces. The web app, public API, MCP, A2A, and management surfaces are served separately and don’t cross over.

Audit trails

• Activity log — one record per billable operation, with cost line items and source attribution. Message content is kept separately and reachable from the record.
• Conversation records — the full per-turn detail on the Monitoring and Conversations pages. See Observability and debugging.
• Your own audit events — your sandboxed code can record structured audit events with ctx.audit(event, data).