> ## Documentation Index
> Fetch the complete documentation index at: https://agentheya.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/sidebar-menu/purpose) are applied on every turn, and an optional [judge](/runtime/evaluation) scores each answer against your criteria |
| [Tool parameter guards](/reference/tool_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](/sidebar-menu/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](/sidebar-menu/conversations) — see
[Multi-agent orchestration](/runtime/multi-agent).

## Sandboxed code

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

<Note>
  Your code has no access to platform environment variables and no access to the
  platform filesystem.
</Note>

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](/custom-tools-ctx), 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](/runtime/turn-execution) |
| Response Limits   | Per agent            | Maximum answer time and tool loops ([Purpose](/sidebar-menu/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](/sidebar-menu/tools))                      |

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](/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](/manage-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](/sidebar-menu/activity)** — 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](/sidebar-menu/monitoring) and
  [Conversations](/sidebar-menu/conversations) pages. See
  [Observability and debugging](/runtime/observability).
* **Your own audit events** — your sandboxed code can record structured audit
  events with [`ctx.audit(event, data)`](/custom-tools-ctx).