> For the complete documentation index, see [llms.txt](https://docs.icustomer.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.icustomer.ai/iharness/gates.md). # Gates The checkpoints that stop iHarness: what gates guard, where approvals happen, and per-tool approval modes. A gate is the checkpoint between a proposal and the real world. iHarness can think, plan, and draft freely; the moment an action would commit something, budget, sends, credits, a change to your CRM, it stops at the gate and waits for a human. ## What gates guard Gates sit exactly where spend and consequence sit: activating a play, pushing an audience to a channel, writing to CRM records, committing budget. Reading, scoring, and drafting never need a gate, which is why the system can be always-on without being dangerous. ## One approval, anywhere An approval request reaches you where you are: in [Pulse](/pulse/queue.md), in chat, in Slack. It is the same request in every surface, and approving in one place resolves it everywhere. The approval itself, who, when, for what, is recorded on the decision's [trace](/concepts/decisions-and-traces.md). ## Per-tool approval modes Gates are tunable per tool, three modes: * **Always allow**: the action runs without asking. For reads and low-stakes writes you trust. * **Needs approval**: the default for anything that writes. The action waits for you. * **Blocked**: the action is off entirely. Writes default to needs-approval. As trust builds, you widen specific gates deliberately, which is the practical mechanics behind [Autopilot vs approval-first](/pulse/autopilot-vs-approval-first.md). ## Gates are not friction A gate fires once per commitment, not once per step. Approve a play and it runs, within its bounds, without re-asking on every send. The design goal is a system that asks rarely, asks clearly, and never acts beyond what you granted. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.icustomer.ai/iharness/gates.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.