Server Spoofing Detection

Validate the identity of every MCP server before routing agent traffic to it — addressing OWASP MCP Top 10 #8. ShieldAgent performs cryptographic server identity verification, terminating connections immediately on any mismatch.

The Threat

OWASP MCP Top 10 #8 (Server Spoofing) covers scenarios where a malicious actor presents a fake MCP server that impersonates a legitimate one — intercepting tool calls, exfiltrating data passed as tool arguments, or returning crafted tool responses designed to manipulate the agent.

Man-in-the-middle server substitution

critical

An attacker routes agent traffic to a server they control that presents the same MCP tool manifest as the legitimate server, silently intercepting all tool call arguments (which may contain sensitive data).

DNS hijack / ARP spoofing

critical

Network-layer attacks cause the agent's MCP connection to reach a spoofed server at the same hostname. Without identity pinning, the agent has no way to detect this.

Compromised server impersonation

high

After a legitimate MCP server is decommissioned or rotated, an attacker reuses its DNS name or URL but presents a different certificate and capability set.

Rogue internal server

high

An internal developer or compromised service deploys a local MCP server that mimics a production server to capture tool-call credentials or intercept agent actions.

How ShieldAgent Detects It

ShieldAgent uses a two-layer identity validation approach. Both checks run at connection establishment time, before any tool calls are forwarded.

Certificate identity validation

The upstream server's TLS certificate is cryptographically verified against the registered baseline on every connection. Any change from the expected certificate immediately terminates the connection and emits a spoofing event.

Capability baseline verification

After the TLS handshake, the server's declared capabilities are verified against the registered baseline. Any unexpected change — in the server name, protocol version, or capability set — triggers a spoofing alert even if the certificate is valid.

New connection

→

Certificate check

→

Capability check

→

Both match → allow|Any mismatch → terminate

Server Spoofing Detection Record

The following fields are stored per server and used for spoofing detection:

Field	Description
registeredAt	ISO 8601 timestamp of initial registration.
lastValidatedAt	Timestamp of the most recent successful identity validation.

Configuration

Server identity validation is enabled by default and configurable per deployment. See the deployment guide for the full configuration reference, including options for enforcement mode and planned rotation windows.

Use the API to open a rotation window before rotating a server's credentials. During the window, identity mismatches are demoted to alerts and the new identity is learned. Once the window expires, enforcement reverts to block mode.

Audit Events & API

Every spoofing detection is persisted as a server_spoofing audit event with the mismatch type, the expected and observed values, and the connection termination timestamp.

json

{
  "id": "aev_...",
  "agentId": "agt_...",
  "tenantId": "ten_...",
  "eventType": "server_spoofing",
  "action": "block",
  "riskScore": 98,
  "details": {
    "serverId": "srv_...",
    "serverName": "github-mcp",
    "mismatchType": "certificate_mismatch",
    "connectionTerminatedAt": "2026-04-25T10:00:00.042Z"
  },
  "timestamp": "2026-04-25T10:00:00.000Z"
}

API endpoints

GET/tenants/:tenantId/audit-events?eventType=server_spoofing—List server spoofing events. Supports ?serverId=, ?from=, ?to= filters.

GET/tenants/:tenantId/servers/:serverId/identity—Get the stored identity record for a server.

POST/tenants/:tenantId/servers/:serverId/rotation-window—Open a planned certificate rotation window.

DELETE/tenants/:tenantId/servers/:serverId/rotation-window—Close a rotation window early (immediately re-enforce identity validation).

Policy Integration

Server spoofing events are connection-level and block all traffic on the affected connection. You can additionally use security.serverSpoofing.detected in a policy rule to quarantine the agent that triggered the connection while the incident is investigated:

json

{
  "name": "Quarantine agent on spoofing detection",
  "priority": 1,
  "conditions": [
    { "field": "security.serverSpoofing.detected", "op": "eq", "value": true }
  ],
  "action": "block",
  "response": {
    "code": 503,
    "message": "Agent quarantined: MCP server identity validation failed."
  }
}

A priority of 1 ensures this rule evaluates before all other policies so the agent is blocked immediately regardless of other allow rules that may otherwise permit the specific tool call.