Claude Desktop setup

Claude Desktop is Anthropic’s native Mac/Windows app for Claude. Installing InPolicy into Claude Desktop takes five minutes per machine.

Two ways to authenticate

Pick the path that matches your deployment:

Path	Who it’s for	What the user does
API key	IT-deployed installs where you can pre-provision a credential	Nothing. IT bakes the key into the MCP config.
Sign in with InPolicy	BYOD / unmanaged-device users where each person authenticates as themselves	Click through a one-time browser sign-in the first time the AI uses InPolicy.

The API-key path is described in this page below. For the sign-in path, see Sign in with InPolicy (BYOD) at the bottom — same claude_desktop_config.json shape, just no INPOLICY_API_KEY env var. The MCP server detects the missing key and runs the OAuth flow on first call.

Prerequisites

Claude Desktop installed and signed in.
Node.js 18+ on each employee machine. Most engineering laptops already have this. For non-engineering users, install Node from nodejs.org. It’s a one-time install, no ongoing maintenance.
An InPolicy API key from your admin dashboard (see overview) — only for the API-key path.

One-user setup

Open Claude Desktop and go to Settings → Developer → Edit Config. This opens claude_desktop_config.json. If the file doesn’t exist, Claude Desktop will create it.

Add this entry inside the mcpServers object (create the object if it’s not there):

{
  "mcpServers": {
    "inpolicy": {
      "command": "npx",
      "args": ["-y", "@inpolicy/mcp-server"],
      "env": {
        "INPOLICY_API_KEY": "inp_live_REPLACE_ME"
      }
    }
  }
}

Replace inp_live_REPLACE_ME with the actual API key from your dashboard.

Save the file and fully quit Claude Desktop (Cmd-Q on Mac, not just close the window). Relaunch it.
You should see an inpolicy server listed under Settings → Developer. The status should be green.
Now apply the system prompt template under Settings → Profile → Custom Instructions.

That’s it. Claude now has access to your company’s policies on every turn.

Fleet deployment (IT)

For rolling out to many machines, three options depending on your MDM stack:

Option A: MDM config profile (Jamf, Intune, Mosyle, Kandji)

Ship claude_desktop_config.json to each user’s ~/Library/Application Support/Claude/ (Mac) or %APPDATA%\Claude\ (Windows) as a managed file. Most MDM tools support file deployment with variable substitution so the API key can be injected from a central secret.

Templated file (substitute ${INPOLICY_API_KEY} at deploy time):

{
  "mcpServers": {
    "inpolicy": {
      "command": "npx",
      "args": ["-y", "@inpolicy/mcp-server"],
      "env": {
        "INPOLICY_API_KEY": "${INPOLICY_API_KEY}"
      }
    }
  }
}

If the user has customized their config, your deploy will overwrite it. Consider merging instead if your MDM supports it.

Option B: Script-based deploy

Run a one-shot script on each machine (via your RMM or ansible equivalent). On macOS:

#!/usr/bin/env bash
set -euo pipefail

CONFIG_DIR="$HOME/Library/Application Support/Claude"
CONFIG_FILE="$CONFIG_DIR/claude_desktop_config.json"
mkdir -p "$CONFIG_DIR"

cat > "$CONFIG_FILE" <<EOF
{
  "mcpServers": {
    "inpolicy": {
      "command": "npx",
      "args": ["-y", "@inpolicy/mcp-server"],
      "env": {
        "INPOLICY_API_KEY": "$INPOLICY_API_KEY"
      }
    }
  }
}
EOF

echo "InPolicy MCP configured. Restart Claude Desktop to activate."

Option C: Announce + email

For smaller teams, email the config snippet with instructions. Include the API key (it’s a tenant identifier, not a user secret, so it’s safe to share within your org).

Verify it’s working

Open a new conversation in Claude Desktop and ask:

“What tools do you have available from InPolicy?”

Claude should list the InPolicy tools (record_turn, check_output, get_conversation_state, etc.). If it doesn’t, check:

The inpolicy entry appears in Settings → Developer with a green status.
Node.js 18+ is installed (node --version).

The API key is valid. Quick sanity check that exercises the real pre-inference endpoint:

curl -X POST https://api.inpolicy.ai/api/v1/agent/governance/pre-inference \
  -H "Authorization: Bearer $INPOLICY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"sessionId":"verify-$$", "prompt":"hello"}'

A 200 response means the key works. A 401 means the key is bad or revoked.

What to tell your users

See What employees will see. Two key points:

They don’t need to do anything differently. The system prompt handles it.
Sometimes Claude will mention a policy by name (e.g. “I should note that per Policy 4.2…”). That’s expected and a sign it’s working.

For deployments where each user authenticates as themselves rather than sharing a tenant API key, omit the INPOLICY_API_KEY env var:

{
  "mcpServers": {
    "inpolicy": {
      "command": "npx",
      "args": ["-y", "@inpolicy/mcp-server"]
    }
  }
}

When the user first asks Claude to do something policy-relevant:

The MCP server detects there’s no cached token.
It opens the user’s default browser to the InPolicy sign-in page, on a randomly-bound localhost callback URL.
The user signs into InPolicy as themselves, sees a consent screen (“Claude Desktop on andrew-mbp wants access”), and clicks Allow.
The browser tab confirms “Connected, return to your AI assistant.”
Claude resumes whatever the user originally asked. Subsequent calls use the cached token.

The token is stored on disk at:

OS	Path
macOS	`~/Library/Application Support/InPolicy/oauth.json`
Windows	`%APPDATA%\InPolicy\oauth.json`
Linux	`$XDG_CONFIG_HOME/inpolicy/oauth.json` (default `~/.config/inpolicy/oauth.json`)

File mode is 0600 on POSIX. Future versions will move this into the OS keystore (Keychain / DPAPI / libsecret).

Tokens auto-refresh. The user only sees the browser flow again if they revoke their grant from Settings → Connected Apps in the InPolicy dashboard, or if an admin revokes it.

Self-hosted backends

If you run an InPolicy backend yourself, point the MCP at it via INPOLICY_API_URL. The MCP derives the dashboard URL from the API URL by convention (api.x.com → app.x.com); override that with INPOLICY_DASHBOARD_URL if your dashboard lives somewhere unusual.

{
  "mcpServers": {
    "inpolicy": {
      "command": "npx",
      "args": ["-y", "@inpolicy/mcp-server"],
      "env": {
        "INPOLICY_API_URL": "https://api.acme.internal/api/v1",
        "INPOLICY_DASHBOARD_URL": "https://policies.acme.internal"
      }
    }
  }
}

You’ll also need to register an OAuth client in your InPolicy backend so it recognizes the MCP server’s client_id. Run make seed-oauth-clients against your backend’s database to register the shipped mcp_inpolicy_v1 client — the seed is idempotent and safe to re-run. A UI for registering custom clients is on the roadmap.