[V2 Proposal] Schema-First Validation + Sanitization Profile (Aligned to OWASP Section 3)

[parmarmanojkumar]

Summary

Add a dedicated, schema-first validation and sanitization profile to the MCP Security whitepaper, aligned to OWASP Section 3: Data Validation & Resource Management.

This issue defines concrete requirements for validating and sanitizing MCP inputs/outputs/messages to reduce injection, overexposure, abuse, and unsafe tool execution.

Problem Statement

Current whitepaper coverage references validation and guardrails, but it does not yet provide a complete, enforceable profile that specifies:

• Exactly what must be schema-validated (message, tool input, tool output, resource payloads).
• Where sanitization must occur in the pipeline.
• What classes of unsafe data must be blocked/encoded.
• What resource limits are mandatory and how to verify them.

This creates implementation ambiguity and inconsistent defenses at trust boundaries.

Objective

Define a "Schema-First Validation + Sanitization Profile" that can be adopted as a normative control package and mapped to MCP threats (T3/T4/T5/T10/T12).

Scope

In scope

• Normative profile for:
  1. Message-level schema validation (JSON-RPC / MCP primitives)
  2. Tool input and output schema enforcement
  3. Resource payload validation and sanitization
  4. Structured invocation requirement (reject free-form privileged execution)
  5. Resource constraints: size, recursion depth, rate limits, timeouts
  6. Logging-safe encoding/redaction controls
• Fail-closed behavior for validation failures.
• Test cases and negative tests for bypass attempts.

Out of scope

• Prompt-only policy guidance not connected to structured validation.
• Framework-specific middleware code.

Proposed Control Profile (Draft)

SVP-1: Schema validation at every trust boundary

• MUST validate all inbound MCP messages against allowed schemas.
• MUST reject unknown fields when marked non-extensible.
• MUST enforce type, enum, format, and required field checks.

SVP-2: Tool invocation constraints

• MUST require structured tool invocation for high-risk actions.
• MUST NOT execute direct shell/SQL/API commands from unconstrained free-form model text.
• MUST enforce strict parameter allowlists and deny ambiguous polymorphic payloads.

SVP-3: Output validation and containment

• MUST validate tool outputs before re-injection into model context.
• MUST apply output size limits and truncation policy with explicit markers.
• MUST block control-channel injection patterns and reserved meta-fields.

SVP-4: Sanitization and encoding

• MUST sanitize file paths via canonicalization + allowlisted roots.
• MUST use parameterized queries for DB-bound operations.
• MUST context-encode output for shell/SQL/HTML sinks.

SVP-5: Resource management controls

• MUST define per-session quotas (requests, bytes, CPU time, tool calls).
• MUST enforce per-request timeouts and concurrency caps.
• MUST emit abuse telemetry when thresholds are crossed.

SVP-6: Fail-closed and auditability

• MUST fail closed on schema/sanitization errors for privileged paths.
• MUST log validation decisions without leaking sensitive payload content.
• SHOULD include policy decision IDs for cross-system correlation.

Required Whitepaper Artifacts

1. New subsection under controls (or appendix): "Schema-First Validation + Sanitization Profile".
2. End-to-end validation pipeline diagram (ingress -> normalization -> validation -> sanitization -> policy -> execution -> output validation).
3. Threat mapping table from SVP controls to MCP threats.
4. Test catalog with positive/negative cases.

Test and Verification Requirements

For each SVP control, define:

• Test type: unit / integration / adversarial
• Sample invalid payload classes
• Expected outcome (reject, sanitize, rate-limit, alert)
• Required evidence (test logs, policy config, runtime metrics)

Minimum required adversarial cases:

• Prompt-influenced command argument injection
• Path traversal in tool parameters
• Oversized/recursive payload DoS
• Hidden control instructions in tool output/resource content
• Schema confusion and type smuggling

Acceptance Criteria

• Whitepaper includes normative SVP control set with IDs.
• Validation pipeline and trust-boundary checkpoints are documented.
• Threat mapping table to MCP-T categories is included.
• Negative test suite requirements are explicitly defined.
• Fail-closed behavior for privileged operations is unambiguous.
• Profile is cross-referenced from deployment profiles and minimum-bar section.

Dependencies / Related Issues

• Related: Scope/Anti-scope: clarify scope, add prioritization & validation guidance #18, Cluster A: define MCP security invariants and trust boundaries #22, Cluster B: add MCP tool classes, descriptor security, provenance and hotplug policies #23, Cluster C: define MCP security profiles, extended deployment guidance and host posture #24, Cluster F: enhance MCP observability, threat modeling and testing guidance #27, Guardrails and Red Teaming Playbook #58
• Related playbooks: Secure Tool Design Playbook #54, Runtime Operations Playbook #55, Guardrails and Red Teaming Playbook #58
• Should be linked to new "Minimum Bar parity" issue for conformance.

Proposed Labels / Milestone

• Labels: whitepaper, review
• Milestone: MCP Security V2 Whitepaper

Suggested Owners

• Whitepaper controls editors
• Runtime operations + secure tool design contributors
• Threat-model and testing contributors

[parmarmanojkumar]

Triage update (2026-04-15)

Summary:
V2 proposal for schema-first validation and sanitization profile aligned to OWASP section 3.

Type:
conceptual

Recommendation:
Accept

Proposed wave:
Wave 2 conceptual

Proposed milestone/versioning:
mcp-security-whitepaper-v1.2-conceptual

Proposed labels/tags:
review, whitepaper, v2 branch

Related/dependencies: #23, #25, #63

Reasoning:
Complements tool governance and policy UX work; should define enforceable validation/sanitization checkpoints across MCP flow.