> For the complete documentation index, see [llms.txt](https://help.nightfall.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.nightfall.ai/data-exfiltration-prevention/ai-agent-security/ai-governance/choosing-a-control.md). # Choosing a control When to use Claude Inference Hooks, IDE hooks, the Claude Compliance API, and the MCP Gateway, and what each one can and cannot stop. Nightfall protects AI use at four different points. They overlap. None of them replaces the others. | | Inference Hooks | IDE hooks | Claude Compliance API | MCP Gateway | | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | | Where it sits | Inside Claude, before the model runs | On the laptop, inside the coding agent | After the fact, via Anthropic's API | On the path to remote MCP servers | | Can it stop the action? | Yes. A denied prompt never reaches the model. | Yes. A denied prompt, tool call, or shell command never runs, and a blocked tool response is redacted before the model reads it (macOS and Windows agents; not on VS Code Copilot). | No. Monitor and alert only. | Yes, for remote tools. A disabled tool or blocked server cannot be called through the gateway. | | Needs the Nightfall agent or MDM? | No. | Yes. Agent plus a hook deployment. | No. | No. Clients must use the Nightfall URL. | | What it covers | Claude Enterprise: claude.ai, Claude Desktop, mobile, Cowork, Claude Code, Claude in Slack | Claude Code, Cursor, VS Code Copilot on managed devices | Claude Enterprise chats and uploaded files | Any MCP client pointed at the gateway: Cursor, Claude, VS Code, Windsurf, ChatGPT, and others | | What it does not cover | Cursor, VS Code, Copilot, Windsurf. Claude Team. Bedrock, Vertex, and the Claude Platform API. Shell and tool calls before they execute. | claude.ai, Cowork, and any machine that never received the hooks. | Inline blocking. Claude Team. Bedrock, Vertex, and Platform API traffic. | Local stdio MCP. Clients that still point at a vendor URL. Prompt text that never becomes a tool call. | {% hint style="warning" %} Inference Hooks do not make Claude Code hooks optional, and they do not remove the MDM rollout, if you need to stop a shell command or a tool call before it runs. {% endhint %} ## The short answer Use **Inference Hooks** when the job is: stop sensitive text from reaching Claude, for the whole Claude Enterprise organization, including people who never installed anything. Use **IDE hooks** when the job is: stop the action itself, a shell command, an MCP tool call, or a file read, before it executes, on Claude Code, Cursor, or VS Code. Use the **Compliance API** when the job is an org-wide record of Claude Enterprise chats and files after they exist, for investigation and evidence. Use the **MCP Gateway** when the job is one sanctioned front door for remote tools, with credentials you can revoke and a log of who called what. Most Claude Enterprise customers run all four. ## What each layer actually sees ```mermaid sequenceDiagram participant User participant Client as Claude or IDE participant Hooks as IDE hooks participant Anthropic participant NF as Nightfall Inference Hooks participant Model User->>Client: Prompt, or a tool the agent wants to run alt IDE hooks installed Client->>Hooks: Before prompt, tool, or shell Hooks-->>Client: Allow or block end Client->>Anthropic: Governed request Anthropic->>NF: Transcript, before inference NF-->>Anthropic: Allow or deny alt Allowed Anthropic->>Model: Inference end ``` Two facts decide which control you need. **Inference Hooks run after the request has left the device, and before the model.** Anthropic sends the conversation Nightfall can see: the transcript, tool calls and their results, and text extracted from attachments. A deny stops that inference. The model never sees the content. **By the time a tool call is in that transcript, the tool has already run.** Inference Hooks can stop the model from reading a secret a command just printed. They cannot un-run the command. IDE hooks are the control that fires before `cat`, before an MCP tool, and before a file read. The Compliance API runs later still. It reads chats and files Anthropic has already stored. It never sits on the request. The MCP Gateway sits on a different path entirely: the call from a client to a remote MCP server. It does not scan the prompt, and it does not see local servers. ## What is covered, by content Five kinds of content show up in an agent session. Each control sees a different subset, and seeing content is not the same as being able to stop the action. | Content | IDE hooks | Inference Hooks | Compliance API | MCP Gateway | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | User prompt | Block before the prompt is submitted | Block before the model runs | Scan the stored chat afterward. No block | Not seen | | MCP tool call | Block before the tool runs | Scanned only after the tool has already run, inside the next prompt check. A deny stops the model. It does not stop the call | Not a tool log | Disable the tool or block the server, so the call never happens through the gateway. Request arguments are written to Audit, capped at 8 KiB. They are not scanned for sensitive data | | Tool response | Block after the tool has finished, before the model reads the output, on the macOS and Windows agents. The call already happened. VS Code Copilot cannot block tool responses | Scanned after the tool has finished, before the model reads the result. A deny stops the model from seeing it. The call already happened | No | Tool responses are not stored. Content scanning of the response is not available in this release | | Shell command | Block before the command runs | Not a separate check. A shell command arrives as a tool call after it has executed. The command string and its output can be inside the next prompt check. The command already ran | No | Not seen | | Model response | Monitor after the model has replied. No block | Not a separate check. Text the model already wrote can sit inside a later prompt frame, and a match denies that later turn | Scan the stored assistant message afterward. No block | Not seen | {% hint style="info" %} Inference Hooks evaluate **User Prompts** only. Tool Calls, Tool Responses, Shell Commands, and Model Responses are IDE hook controls. They do not fire on Inference Hooks. The MCP Gateway blocks servers and disables tools. It does not scan prompt text or tool-response content in this release. {% endhint %} ### How to read the Inference Hooks column Anthropic sends one frame per governed inference, before the model runs, containing the conversation so far. Nightfall scans the new text in that frame. New text can be the user's prompt, a tool call's arguments, a tool's result, or text extracted from an attachment. A finding denies the whole inference. That is why a secret typed into the prompt is stopped before Claude can act on it, and a secret a tool just printed is stopped before Claude can read it, while the tool itself is already done. A policy that selects only Tool Calls, Tool Responses, Shell Commands, or Model Responses never matches an Inference Hooks delivery. Those toggles are for IDE hooks. They do not apply on this integration. ### How to read the IDE hooks column The policy wizard is the contract. Each hook type is independent, but the action (Block or Monitor) is set once for the whole policy. | Hook type | When it fires | Block? | | --------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | User Prompts | Before the prompt is sent to the model | Yes | | Tool Calls | Before an MCP tool or subagent runs. Name and arguments | Yes | | Shell Commands | Before a terminal command or a built-in file tool (read, write, edit) runs, including the content being written | Yes | | Tool Responses | After the tool finishes, before the model reads the output. Name and output | Yes, on the macOS and Windows agents. Not on VS Code Copilot | | Model Responses | After the model replies | No. Monitor only | Cursor's pre-action hooks (`beforeSubmitPrompt`, `preToolUse`) are fail-closed: if the hook crashes, times out, or returns invalid JSON, the action is blocked. VS Code Copilot does not support blocking tool responses. #### Hook points by coding agent | Policy Hook Type | Claude Code | Cursor | VS Code Copilot | OpenAI Codex CLI | | ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- | | **User Prompts** | `UserPromptSubmit`: **Block** or Monitor | `beforeSubmitPrompt` (`failClosed: true`): **Block** or Monitor | `UserPromptSubmit`: **Block** or Monitor | `UserPromptSubmit`: **Block** or Monitor | | **Tool Calls** | `PreToolUse` (MCP tools, `Task`, `Agent`, `WebFetch`, `WebSearch`): **Block** or Monitor | `preToolUse` (`MCP:*`, `Subagent:*`, `failClosed: true`): **Block** or Monitor | `PreToolUse` (MCP and non-shell tools): **Block** or Monitor | `PreToolUse` (MCP tools): **Block** or Monitor | | **Shell Commands** | `PreToolUse` (`Bash`, `Read`, `Write`, `Edit`, `MultiEdit`): **Block** or Monitor | `preToolUse` (`Shell`, `Read`, `Write`, `Delete`, `Grep`, `LS`, `failClosed: true`): **Block** or Monitor | `PreToolUse` (`run_in_terminal`, `create_file`, `replace_string_in_file`, `read_file`): **Block** or Monitor | `PreToolUse` (`Bash`): **Block** or Monitor | | **Tool Responses** | `PostToolUse` (MCP tools): **Block** (replaces output via `updatedToolOutput` so the model never sees it) or Monitor | `postToolUse` (`MCP:*`): **Block** (replaces output via `updated_mcp_tool_output` so the model never sees it) or Monitor | `PostToolUse` (MCP tools): **Monitor only** (VS Code Copilot ignores post-tool block and redaction verdicts) | `PostToolUse` (MCP tools): **Block** (withholds output from the model) or Monitor | | **Shell Responses** *(evaluated under Shell Commands)* | `PostToolUse` (`Bash`): **Monitor only** (built-in tool output cannot be replaced in Claude Code) | `postToolUse` (`Shell`): **Monitor only** (`updated_mcp_tool_output` only applies to MCP tools) | `PostToolUse` (`run_in_terminal`): **Monitor only** | `PostToolUse` (`Bash`): **Block** (withholds output from the model) or Monitor | | **Model Responses** | `Stop`: **Monitor only** | `afterAgentResponse`: **Monitor only** | `Stop`: **Monitor only** | `Stop`: **Monitor only** | ### How to read the gateway column Server and tool governance is live. Block a server, or disable write and delete tools. Clients stop listing those tools and cannot call them. This does not look at the arguments. Content scanning is not available on the gateway in this release. Do not write a gateway content policy and expect a block. Use IDE hooks or Inference Hooks for the content, and the gateway for which tools exist. Audit records who called which tool and the request arguments. It does not record the tool's response. ## Use cases | You are trying to stop | Use | Why this one | | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------- | | A person pastes a customer list or an API key into claude.ai, Cowork, or Claude Code, including on a laptop with no agent | Inference Hooks, User Prompts, Block | The check is in Claude's cloud, before the model | | A coding agent runs a shell command or an MCP write tool | IDE hooks, Tool Calls and Shell Commands, Block | The check is before the process starts | | A tool returns a secret the model should not read | IDE hooks, Tool Responses, Block | The check is after the tool and before the model | | You want a record of what the tool returned | IDE hooks, Tool Responses, Monitor | The tool has finished | | You want the model's reply in the incident | IDE hooks, Model Responses, Monitor. Compliance API for the stored Claude Enterprise chat | The reply has already been generated | | GitHub MCP should be searchable and not able to delete | MCP Gateway: keep the server, disable the delete tools | The tool disappears from the client | | You do not know which MCP servers developers already added | MCP Server Visibility | The gateway only sees clients that use its URL | | Legal needs the chat that already happened | Compliance API | Inference Hooks have no retrospective view | | Claude Code on Bedrock, Vertex, or a Console API key | IDE hooks only | Inference Hooks and the Compliance API do not see that traffic | ## Best practices 1. Write separate policies per control. An Inference Hooks policy selects User Prompts only. An IDE policy selects the hook types that client can actually fire. 2. Turn on content scanning and add detection rules. A policy with content scanning off applies to every event in scope: Block denies all of them, and Monitor records all of them. 3. Leave Inference Hooks tool scope on All MCP servers. A rule narrowed to one tool does not apply to an ordinary chat turn, which names no tool. 4. Start IDE hook policies in Monitor for a week, except credentials. Credential detectors are specific enough to Block on day one. 5. Start Inference Hooks in Anthropic shadow mode, failure handling Allow the request, timeout at least 5,000 ms, 100% inspected. Move to enforce after a business day of decisions. 6. Name the policies so an admin can tell them apart. On IDE hooks, Tool Calls blocks before the tool runs. On Inference Hooks, tool text is scanned after the tool ran. 7. Pair the gateway with Visibility. Disabling a tool on the gateway does not remove a vendor URL from a local config file. 8. Keep the Compliance API on when Inference Hooks are on. Circuit-breaker trips and hook denials are recorded in Claude's activity feed only when that API is enabled. Policy templates and the rollout plan are on [Hook policy recommendations](/data-exfiltration-prevention/ai-agent-security/ai-governance/hook-policy-recommendations.md). --- # 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://help.nightfall.ai/data-exfiltration-prevention/ai-agent-security/ai-governance/choosing-a-control.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.