MCP Quality Security & Redaction

NAT MCP Quality v0.1 includes a bounded deterministic security baseline. It is intentionally narrower than model-in-the-loop agent security analysis.

Deterministic security checks

The v0.1 baseline can surface:

• duplicate or ambiguous tool names after normalization;
• obvious credential-like material embedded in tool descriptions;
• resource URIs without a valid scheme;
• default discovery of local file:// paths commonly associated with credentials or secrets;
• breaking contract drift when a baseline is supplied through the shared MCP service layer.

Tool input-schema structure remains part of deterministic functional coverage rather than being duplicated as a separate security implementation.

Quality-gate behavior

Raw findings remain separate from gate policy. By default, HIGH and CRITICAL findings block the MCP security quality gate. INFO-only additive drift does not block the default gate.

This separation is intentional so later policy customization does not alter raw drift detection.

Redaction boundary

NAT applies recursive redaction before NAT-native quality results and MCP inspection data are serialized. Obvious secret-bearing keys, bearer tokens, private-key material, and sensitive local paths are replaced with [REDACTED] rather than emitted in plaintext.

Do not put credentials directly in committed fixtures, tool descriptions, test specifications, or shell commands. Prefer environment variables, CI secret stores, or named profiles supported by the surrounding execution environment.

Example CI pattern:

env:
  MCP_TEST_URL: ${{ secrets.MCP_TEST_URL }}
 
steps:
  - name: MCP security gate
    run: nat mcp security --url "$MCP_TEST_URL" --output json > mcp-security.json

The URL itself should also avoid embedding credentials. Use the authentication configuration supported by the MCP endpoint/runtime rather than including tokens in a URL.

What v0.1 does not claim to detect

MCP Quality v0.1 does not perform semantic prompt-injection analysis, model-driven tool-poisoning detection, autonomous adversarial reasoning, behavioral goal evaluation, or LLM-as-judge security scoring.

Those require model-in-the-loop reasoning and are explicitly outside the frozen v0.1 scope.

Handling findings

Treat a HIGH or CRITICAL finding as a target quality failure that should be reviewed before promotion. Treat runtime/dependency errors separately: they mean NAT could not make a valid determination and should not be interpreted as either security success or target vulnerability.

When sharing JSON artifacts with a design partner, retain the redacted NAT output rather than raw protocol/debug logs that may bypass NAT's serialization boundary.