Guard MCP Server

Govern Claude Code tool calls routed through the sector8-guard MCP server with evaluate-before-dispatch decisions and fail-closed connector behavior.

What it does

Sector8 governs Claude Code tool calls that are routed through the sector8-guard MCP server. Other MCP-compatible clients can use the same connector when they route tools the same way.

When a tool call is routed through sector8-guard, the caller-visible decision is ALLOW or DENY. On this connector path a borderline action can be held for a human before that decision is returned; if nobody answers, it is denied.

Coverage applies to tool calls routed through the connected Sector8 MCP server. Unconnected tools, direct shell access, and other agent paths are not automatically covered.

This is not a separate policy engine. The MCP server uses the same policy, reason-code, and evidence model as REST evaluate. The difference is that the connector can wait on a human before returning ALLOW or DENY. POST /api/v1/evaluate does not wait; it fails closed to DENY.

Installation

Primary path after installing the SDK:

pip install sector8-sdk

Then run:

sector8-guard install

This writes .claude/settings.json for the current project and preserves existing settings keys.

The installer writes a relative command entry that targets the checked-in MCP server launcher from the repo root. On Windows it prefers the .cmd wrapper when present.

Manual fallback:

{
  "mcpServers": {
    "sector8-guard": {
      "command": "python",
      "args": ["sector8-backend/scripts/mcp_stdio_server.py"],
      "env": {
        "SECTOR8_API_KEY": "${SECTOR8_API_KEY}",
        "SECTOR8_CLIENT_ID": "${SECTOR8_CLIENT_ID}"
      }
    }
  }
}

On Windows, replace the args path with the .cmd wrapper if present:

{
  "mcpServers": {
    "sector8-guard": {
      "command": "scripts/run_sector8_guard_mcp.cmd",
      "args": []
    }
  }
}

How it works

Claude Code tool call
(routed through sector8-guard)
        |
        v
Guard MCP Server
        |
        v
Sector8 evaluate
  |- pre-filter
  |- rate and multi-turn checks
  |- tool registration and capability checks
  |- BOLA and BFLA checks
  |- semantic and segmented-input checks
  |- request-risk checks
        |
   +----+----+
   |         |
   v         v
 DENY      ALLOW
   |         |
   |         +-- tool may execute
   +-- tool does not execute

On this connector path, a borderline action can be held for a human before ALLOW or DENY is returned. If nobody answers, the connector denies. That hold is connector behaviour, not a third public decision value. REST evaluate does not wait.

Honor the returned decision before any side effect starts. Policy, telemetry, and decision evidence are unified with Sector8’s runtime evidence model.

Runtime semantics

decision	Runtime behavior
ALLOW	The MCP connector may execute the proposed tool call
DENY	The MCP connector must block the proposed tool call
Missing / unknown	Fail closed on the connector path; do not execute

Do not execute while a human hold is unresolved. TTL expiry is a deny.

Fail-closed on evaluation failure

If the routed evaluate path is unavailable or returns an invalid decision while the tool call is going through sector8-guard, the connector should fail closed and not execute that call. Fail-closed applies to the connected MCP path; it does not stop actions on bypassed or unconfigured tool paths.

Returned denial may include:

• reason_code: GUARD_INTERNAL_ERROR
• non-empty evidence_hash
• has_forensic_payload: true
• decision_trace_id
• policy_version_id

Decision evidence on deny

Denied MCP responses include the standard decision artifact:

• decision
• reason_code
• evidence_hash
• has_forensic_payload
• decision_trace_id
• policy_version_id

Exact reason_code and policy_version_id values depend on your active policy and environment.

What is enforced on the MCP path

For tool calls routed through Sector8, admission checks include:

• tool registration
• capability checks
• object-level authorization (BOLA)
• function-level authorization (BFLA)
• semantic threat scoring
• segmented-input safety
• request-risk checks such as SSRF and sensitive path access
• admission rate limiting

Governed tools

Tool	What gets checked
bash	shell injection, destructive commands, obfuscated command payloads, rate limiting
read_file	sensitive paths, object ownership, authorization
write_file	content safety, authorization, object scoping
web_fetch	SSRF, private IP ranges, localhost, DNS resolution to private targets, unsupported schemes, URL credentials, external domain policy

These tools are governed when the client routes them through sector8-guard. Connecting the MCP server does not automatically cover tools the agent can still call outside that path.

web_fetch protections

web_fetch is not guarded by a simple hostname allowlist.

The current request-risk path blocks:

• raw private IP targets
• loopback and localhost
• link-local targets such as 169.254.169.254
• DNS results that resolve to private IP space
• unsupported URL schemes
• URL credentials
• non-allowlisted external domains

This is designed to stop common SSRF paths, including cloud metadata access, on the governed MCP path.

Example - blocked call

{
  "decision": "DENY",
  "tool_name": "bash",
  "reason_code": "MCP_SHELL_INJECTION_BLOCKED",
  "evidence_hash": "bdbde1558fb883573b0f6e8630ccba1edaf6bed8cb035fa6a48912809149f287",
  "has_forensic_payload": true,
  "decision_trace_id": "32819155-d21a-49c8-9509-79338d980fa9",
  "policy_version_id": "0dbca364d66447469637bafa2282e635124fcb99eecd6383038e3b652577ebc7"
}

Example - allowed call

{
  "decision": "ALLOW",
  "tool_name": "bash",
  "reason_code": "ALLOW_PASS",
  "evidence_hash": "4cb7f786d1f3b57e6f98f3e60d2eb6b81c402d6d3efeb6c9551049f7c14df2f0",
  "has_forensic_payload": false,
  "decision_trace_id": "17e797c0-eb5c-4f97-b4a1-2d3e4f5a6b7c",
  "policy_version_id": "0dbca364d66447469637bafa2282e635124fcb99eecd6383038e3b652577ebc7",
  "result": {
    "stdout": "hello",
    "stderr": "",
    "exit_code": 0
  }
}

Verify the connection

Inside Claude Code:

/mcp

You should see sector8-guard as a connected server.

Then test one allow and one deny through the Sector8 MCP server:

Use the sector8-guard MCP server to run bash: echo hello
Use the sector8-guard MCP server to run bash: rm -rf /

Expected when those calls are routed through sector8-guard:

• echo hello -> ALLOW
• rm -rf / -> DENY
• unknown, missing, or unavailable evaluate results -> connector fails closed and does not execute that call

Fleet deployment

Distribute .claude/settings.json through the repo or developer environment management so engineers connect sector8-guard consistently.

Coverage still depends on the client routing governed tool calls through that MCP server. Connecting the server does not cover unconnected tools or alternate execution paths.

Non-MCP agents

MCP-compatible clients can use this connector. Non-MCP tool callers, including containerized Codex CLI integrations, should use the SDK adapter and POST /api/v1/evaluate.

See the non-MCP integration guide for the container pattern, required environment variables, and enforcement examples.

For the shared decision contract, see Evaluate and Guardrails.