MCP Governance Admin Guide

Arbitex MCP Security governs Model Context Protocol (MCP) server integrations. When AI agents use MCP tools to access enterprise data sources — Salesforce, Jira, internal databases, knowledge bases — the platform inspects every tool call through the same DLP pipeline and policy engine used for all other content channels.

MCP governance extends the existing policy engine. There is no separate MCP rule system. Administrators register MCP servers, bind policy rules to specific servers, and configure tool-level authorization per agent identity. Rules without an mcp_server condition continue to apply to all traffic, including MCP — backward compatibility is preserved.

What MCP governance provides:

Per-server policy enforcement — different policy rules for each MCP server
DLP scanning of MCP payloads — both tool call requests and responses pass through the 5-tier DLP pipeline
Audit trail for all MCP operations — server registration, tool call evaluation, policy decisions, and blocks are logged with source: "mcp"
Tool allowlists and blocklists — control which tools are available per server and per agent identity
Headless evaluation API — evaluate MCP payloads against the policy engine without a chat session (see MCP Security API Reference)

Registering MCP servers

MCP servers are registered per organization. Each server record stores the server URL, encrypted authentication credentials, transport type, and a cached tool manifest.

curl -X POST https://your-platform/api/v1/admin/mcp-servers \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "salesforce-prod",
    "server_url": "https://mcp.internal.example.com/salesforce",
    "auth_token": "sf_token_here",
    "transport": "sse",
    "enabled": true
  }'

Server fields

Field	Type	Required	Description
`name`	string	Yes	Unique name within the org. Used in policy conditions (`mcp_server: ["salesforce-prod"]`).
`server_url`	string	Yes	MCP server endpoint URL. Validated against SSRF protection rules.
`auth_token`	string	No	Authentication token. Fernet-encrypted at rest.
`transport`	string	No	`sse` (default), `stdio`, or `streamable-http`.
`enabled`	boolean	No	Whether the server is active. Defaults to `true`.

Server names must be unique per organization. The platform validates the URL against SSRF protection rules before saving — private IP ranges, localhost, and metadata endpoints are blocked.

Updating a server

curl -X PATCH https://your-platform/api/v1/admin/mcp-servers/{server_id} \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "auth_token": "new_sf_token",
    "enabled": false
  }'

Updating any field triggers a tool manifest refresh (see below). Disabling a server immediately blocks all tool calls to that server.

Deleting a server

curl -X DELETE https://your-platform/api/v1/admin/mcp-servers/{server_id} \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Deleting a server emits a mcp.server_deleted audit event. Policy rules referencing the deleted server’s name are not automatically removed — they simply stop matching and should be cleaned up.

Listing servers

curl https://your-platform/api/v1/admin/mcp-servers \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Returns all registered servers for the org, including health status, tool manifest, and last health check timestamp.

Server health monitoring

The platform probes registered MCP servers periodically and records health status.

Health status values

Status	Meaning
`healthy`	Server responded to the last health probe within the expected timeout
`degraded`	Server responded but with elevated latency or partial errors
`unhealthy`	Server failed to respond or returned an error
`unknown`	No health probe has been attempted yet (newly registered)

Each server record includes health_status and last_health_at timestamp. The Cloud portal displays health status with color indicators on the Settings > MCP Servers page.

Health probe behavior

Probes run on a periodic interval (configurable per deployment)
A probe sends a lightweight request to the server URL and validates the response
Failed probes do not automatically disable the server — tool calls to unhealthy servers are still attempted but may fail
Consecutive failures update the status from healthy to degraded to unhealthy

Tool manifest caching

When a server is registered or updated, the platform fetches the server’s tool manifest and caches it in the tool_manifest JSONB field.

What the manifest contains

The cached manifest lists all tools the server exposes, including their names, parameter schemas, and descriptions. This data drives:

Tool allowlist/blocklist validation — the platform can enforce which tools are permitted before the call reaches the server
Policy condition matching — rules can target specific tool names
Cloud portal display — the MCP Servers page shows available tools per server

Refreshing the manifest

The manifest refreshes automatically when:

A server is first registered
A server record is updated (any field change)

To force a manual refresh, update the server with no changes:

curl -X PATCH https://your-platform/api/v1/admin/mcp-servers/{server_id} \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'

If the server is unreachable during a manifest refresh, the previous cached manifest is retained.

Policy binding

MCP governance uses the standard policy engine. Rules target specific MCP servers using the mcp_server condition field.

How policy evaluation works for MCP

When an MCP tool call arrives, the platform routes it through the Channel.MCP channel. The policy engine evaluates rules with the following context:

Context field	Value
`channel`	`mcp`
`mcp_server`	Name of the registered MCP server
`direction`	`output` (tool call request) or `input` (tool response)
`tool_name`	Name of the specific tool being invoked

The policy engine uses the same evaluation logic as all other channels — rules in packs, packs in chains, evaluated per the chain’s combining algorithm (first_applicable or deny_overrides). See Policy Engine — Deep Dive for the full evaluation model.

Creating per-server rules

Create policy rules that target specific MCP servers by adding the mcp_server condition:

{
  "name": "Block PII from Salesforce MCP",
  "conditions": {
    "mcp_server": ["salesforce-prod"],
    "dlp_label": ["ssn", "credit_card"]
  },
  "action": {
    "type": "block",
    "message": "PII detected in Salesforce tool call"
  }
}

This rule blocks any Salesforce MCP tool call (request or response) that contains SSN or credit card data. The same 5-tier DLP pipeline (TF-IDF, regex, NER, DeBERTa, CredInt) scans the payload.

Rule composition (AND logic)

All conditions on a rule use AND logic. A rule with both mcp_server and dlp_label conditions matches only when both are true:

mcp_server = "salesforce-prod"  AND  dlp_label IN ["ssn", "credit_card"]
→ MATCH: block

This is the same composition model used throughout the policy engine — no MCP-specific logic.

Backward compatibility

Rules without an mcp_server condition apply to all traffic, including MCP. This means existing DLP rules and compliance bundles automatically protect MCP channels without configuration changes.

Rule: "Block SSN everywhere" (no mcp_server condition)
  → Applies to: interactive, api, smtp, email, sidecar, MCP

Rule: "Block trade secrets from Salesforce" (mcp_server: ["salesforce-prod"])
  → Applies to: salesforce-prod MCP server only

Per-server rule composition examples

Each MCP server can have any combination of rule bindings. Rules from compliance bundles compose with custom per-server rules:

mcp-salesforce:      HIPAA bundle + custom PII block
mcp-internal-wiki:   HIPAA bundle + custom PII block + trade secret rules
mcp-jira:            SOX bundle
mcp-dev-tools:       (no specific rules — global rules still apply)

Channel behavior

Channel.MCP in the pipeline

MCP tool calls flow through the same inspection pipeline as all other content, identified by Channel.MCP. The channel value determines which channel-specific rules apply.

Channel.INTERACTIVE  → browser chat sessions
Channel.API          → API completions
Channel.SMTP         → email relay
Channel.MCP          → MCP tool calls

Rules can target MCP traffic specifically by setting channel: "mcp" as a condition, or they can apply globally by omitting the channel condition.

Bidirectional DLP scanning

The DLP pipeline scans MCP traffic in both directions:

Tool call requests (direction=output)

When an LLM generates a tool call to an MCP server, the platform intercepts the outbound payload and runs the policy engine with direction=output. This catches sensitive data before it leaves the platform boundary.

Example: An LLM attempts to send a customer SSN to a Jira MCP server as part of a ticket creation tool call. The DLP pipeline detects the SSN and blocks the outbound request.

Tool call responses (direction=input)

When an MCP server returns data, the platform scans the inbound payload with direction=input before injecting it into the AI context. This catches sensitive data flowing back from external systems.

Example: A Salesforce MCP server returns contact records containing credit card numbers. The DLP pipeline detects the credit card pattern and either blocks or redacts the response before the LLM sees it.

Data flow

User sends chat message
  → LLM generates tool call request
  → Policy engine evaluates: channel=MCP, server=<name>, direction=output
    → BLOCK?  → Reject tool call, emit audit event
    → REDACT? → Redact sensitive content from request, forward to MCP server
    → ALLOW?  → Forward to MCP server
  → MCP server processes request, returns data
  → DLP pipeline scans response: channel=MCP, server=<name>, direction=input
    → BLOCK?  → Reject response, emit audit event
    → REDACT? → Redact sensitive content, inject sanitized data into AI context
    → ALLOW?  → Inject data into AI context
  → Audit: tool_name, server_name, direction, policy decision, DLP findings

Tool allowlists and blocklists

Administrators can control which tools are available per MCP server. Tool authorization operates at two levels.

Server-level tool control

Configure which tools from a server’s manifest are permitted:

{
  "name": "salesforce-prod",
  "tool_allowlist": ["query_contacts", "search_accounts"],
  "tool_blocklist": []
}

Mode	Behavior
Allowlist only	Only listed tools are permitted (deny by default)
Blocklist only	All tools except listed ones are permitted (allow by default)
Neither set	All tools in the manifest are permitted
Both set	Blocklist takes precedence — a tool on both lists is blocked

Tool authorization is checked before policy evaluation and DLP scanning. A blocked tool returns immediately without consuming pipeline resources.

Agent-identity tool authorization

Different AI agents within the same organization can have different tool permissions per MCP server. This is configured through the agent identity model.

See Agent Security — Per-agent tool authorization for the full agent identity model and per-agent tool configuration.

Audit events

Every MCP operation generates audit events with source: "mcp". These events integrate with the standard audit log and are available through the same export and SIEM integration channels.

MCP-specific audit event types

Event	Trigger	Key Fields
`mcp.server_registered`	Admin registers a new MCP server	`server_name`, `server_url`, `transport`
`mcp.server_updated`	Admin updates server configuration	`server_name`, changed fields
`mcp.server_deleted`	Admin deletes a server	`server_name`
`mcp.tool_call_evaluated`	Tool call passes policy evaluation	`server_name`, `tool_name`, `direction`, `decision`
`mcp.tool_call_blocked`	Tool call blocked by policy or DLP	`server_name`, `tool_name`, `direction`, `matched_rule`, `dlp_findings`
`mcp.security_eval`	Headless evaluation via `/api/mcp/evaluate`	`server_name`, `tool_name`, `direction`, `decision`

Audit event fields

All MCP audit events include these fields:

Field	Description
`source`	`"mcp"`
`channel`	`"mcp"`
`mcp_server`	Name of the MCP server
`tool_name`	Name of the tool invoked
`session_id`	Agent session ID (links multi-turn chains)
`direction`	`output` (request to tool) or `input` (response from tool)
`dlp_findings`	DLP scan results (if any detections)
`policy_decision`	Policy engine outcome (`allow`, `block`, `redact`)

Querying MCP audit events

Filter audit logs to MCP events:

# All MCP events
curl "https://your-platform/api/v1/admin/audit?source=mcp" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# Events for a specific server
curl "https://your-platform/api/v1/admin/audit?source=mcp&mcp_server=salesforce-prod" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# Events for a specific agent session
curl "https://your-platform/api/v1/admin/audit?session_id=sess_01HZ...&source=mcp" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Session timeline

For agent sessions that span multiple MCP tool calls, all events share a session_id. This enables full timeline reconstruction of an agent’s actions across servers.

See Agent Security for comprehensive agent session auditing, including risk scoring and chain-of-thought capture.

Troubleshooting

Server unreachable

Symptom: Tool calls to a registered server fail. Server health shows unhealthy.

Verify the server URL is correct and the server process is running
Check network connectivity between the platform and the MCP server (firewall rules, DNS resolution)
Confirm the transport type matches the server’s actual transport (sse, stdio, or streamable-http)
If the server requires authentication, verify the auth_token is current — rotate it if expired

Authentication failures

Symptom: Server shows healthy but tool calls return authentication errors.

The server health probe may use a different authentication path than tool calls
Verify the auth_token stored in the server registration matches what the MCP server expects
Update the token via the admin API or Cloud portal

Policy misconfiguration

Symptom: Tool calls are blocked unexpectedly.

Check which rule matched: query audit logs for mcp.tool_call_blocked events and inspect the matched_rule field
Verify the rule’s mcp_server condition matches the server name exactly (case-sensitive)
Remember that rules without mcp_server conditions apply to all channels, including MCP — a global DLP rule may be triggering
Use the policy simulation API to test rule evaluation with MCP context

Tool calls blocked by allowlist

Symptom: A specific tool is blocked even though no policy rule targets it.

Check the server’s tool_allowlist and tool_blocklist configuration
If an allowlist is set, only tools on the list are permitted — all others are denied by default
If a tool was recently added to the server, refresh the tool manifest to update the cached tool list

Missing audit events

Symptom: MCP tool calls succeed but no audit events appear.

Verify that the tool calls are flowing through the platform’s MCP channel (direct LLM-to-server calls bypass the platform)
Check the audit log filter — MCP events use source: "mcp", not the default null source
Ensure the time range in your query covers the tool call timestamps

MCP Security API Reference — headless evaluation endpoint for external integrations
Agent Security — agent session model, per-agent tool authorization, risk scoring
Policy Engine — Deep Dive — rule evaluation model and action types
DLP Pipeline Architecture — 5-tier scanning pipeline
Security Architecture — CSRF — MCP path exemption details