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

# Agent safety rules

> Cross-surface safety for agents operating Reply.io — high-stakes gating, scoped keys, and rate-limit etiquette.

An agent operating Reply.io can send real messages to real prospects. A successful call executes
immediately — there is no undo. These rules apply across all four access layers.

## What counts as high-stakes

Confirm with the user before any action that:

* **Sends to a prospect** — inbox replies, approving Jason drafts, one-off outreach actions
* **Starts outreach** — starting a sequence, enrolling contacts into a sequence
* **Changes ownership or reach** — reassigning contacts, blacklisting an email or a whole domain
* **Removes work irreversibly** — rejecting a Jason draft (this also removes the contact from the
  sequence), deleting contacts or lists
* **Removes supervision** — switching Jason from Review to Autonomous mode

Configuration changes (assigning mailboxes, schedules, attaching offers/playbooks) are
production-affecting but not prospect-visible — usually worth confirming too.

## How each surface enforces it

| Surface    | Mechanism                                                                                                                                                                                                                                                       |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **MCP**    | Every tool is annotated in `tools/list`: `readOnlyHint` (31 tools) or `destructiveHint` (39). Gate on these before adding your own confirmation UX. See the [tool contract](/mcp/tool-contract) and the [high-stakes list](/mcp/agent-guide#high-stakes-tools). |
| **CLI**    | No built-in gating — `reply api` sends exactly the request it is given. The caller owns the confirmation step: show the exact request, get approval, then run it. See [Using the CLI from agents](/cli/agents).                                                 |
| **Skills** | Every workflow ships with hard confirmation gates — nothing sends, starts, or deletes without explicit approval — plus previews and verification steps. See [Skills](/skills/overview).                                                                         |
| **API**    | No built-in gating — your integration is the gate. Use scoped keys (below) to bound the blast radius, and verify state with a read before retrying any timed-out write.                                                                                         |

<Warning>
  A timed-out send may already have succeeded server-side — on any surface. Verify with a read
  before retrying anything that reaches a prospect.
</Warning>

## Scoped keys bound the blast radius

API keys support granular `domain:verb` scopes (`contacts:read`, `sequences:operate`,
`inbox:write`, …) that behave identically on every surface — a key with `sequences:read` can list
sequences but not start them, whether the call arrives via REST, MCP, or the CLI.

Give an agent the narrowest scope that covers its job; issue separate keys for separate agents so
one can be revoked without stopping the others. Details: [Authentication](/api-reference/authentication).

## Rate-limit etiquette

One budget covers all surfaces — see [Rate limits](/api-reference/rate-limits).

* Honor `Retry-After` on `429`; back off exponentially on `5xx`. (The [CLI](/cli/agents) and MCP
  server handle this for you.)
* Paginate instead of hammering: `top`/`skip` on MCP, and the endpoint's own paging parameters
  (usually `top`/`skip`) when calling through REST or `reply api`.
* Never auto-retry a send, approval, start, or enrollment — verify first (see the
  [safe-retry matrix](/mcp/tool-contract#safe-retry-matrix); the same logic applies to REST and CLI).

## Report honestly

Batch operations return per-item results (`NotProcessed`, `AffectedContactIds`, per-row import
failures). Read them and report exact counts — "reassigned 48 of 50" — and never claim an item
succeeded unless the response says so.

## Next

* [Drop-in system prompts](/agents/prompts) — these rules, pre-packaged for your agent
* [MCP tool contract](/mcp/tool-contract) — envelopes, error codes, and the retry matrix in detail