Valid JSON is not a production bar for tools that send mail, move money, or call MCP. NIST AI 800-5, posted 18 May 2026, says commenters agreed agent threats are novel and that existing cybersecurity practice needs adaptation.
Quoted claim
The claim equates schema-valid tool arguments with production readiness for agents that send email, update tickets, query databases, move money, or call MCP servers. Vendor guides cite function-calling accuracy on clean fixtures. Engineering teams gate launch on passing JSON Schema validation in CI. Procurement questionnaires ask "do you validate tool outputs?" and accept "JSON Schema" as the complete answer. The implicit assumption is that syntax enforcement captures the security and correctness bar NIST and deployers now treat as distinct for autonomous systems.
Where made
Internal enterprise agent rollouts; vendor quick-start guides for OpenAI-, Anthropic-, and MCP-shaped tool APIs; security questionnaires that list schema validation as the primary control. Counter-source: NIST Trustworthy and Responsible AI Report 800-5, "Summary Analysis of Responses to the Request for Information Regarding Security Considerations for AI Agents," published May 18, 2026 (authors Riggs, Hamin, Perry, Edelman, Cihon). That report synthesizes responses to CAISI's Request for Information on securing AI agent systems, released January 12, 2026 (docket NIST-2025-0035; comment period closed March 9, 2026).
Supporting number / method
NIST AI 800-5 — consensus on novel threats. The May 2026 summary states commenters "widely agreed that AI agents present novel security threats and that these security concerns present a barrier to adoption." It adds "widespread agreement that, while fundamental cybersecurity principles and practices remain relevant, they will require adaptation to satisfactorily address agent security." That framing contradicts treating legacy API input validation, including JSON Schema, as sufficient without agent-specific adaptation.
January 2026 RFI — threat categories schema cannot catch. CAISI's RFI news release lists three distinct risk classes beyond conventional software vulnerabilities. First, models interacting with adversarial data, "such as in indirect prompt injection," where malicious instructions embedded in emails, files, web pages, or database records steer agent behavior during legitimate retrieval. Second, insecure models, including data poisoning at training time. Third, models that "take actions that harm security even in the absence of adversarial inputs," including specification gaming or pursuit of misaligned objectives. JSON Schema validates shape and enumeration. It does not distinguish a harmful-but-valid refund to the wrong account from a correct one when both match the account-id field format.
800-5 — government roles commenters requested. The summary identifies roles for government action: offering implementation guidance, facilitating information-sharing, and promoting standards. Commenters asked for help measuring agent security, anticipating risks during development, and constraining agent access in deployment environments, controls that sit above syntax validation. NIST is building on this input through the Control Overlays for Securing AI Systems project and National Cybersecurity Center of Excellence work on agent identity, authorization, and prompt-injection mitigation.
Why schema validation is necessary but not sufficient. JSON Schema catches missing fields, wrong types, and out-of-enumeration values. It does not catch: prompt injection steering the model toward any call the schema permits; tool-description poisoning after MCP install; confused-deputy execution under the server's privileges; cascading failures in multi-step agent workflows; or specification gaming where the model satisfies the schema while pursuing a proxy goal. NIST's January RFI focuses on risks "that arise when combining AI model outputs with the functionality of software systems." The exploit chain runs through model reasoning, not through malformed JSON.
Indirect prompt injection as architectural risk. CAISI treats indirect prompt injection as distinct from direct user manipulation: adversary-controlled content retrieved during normal task execution becomes part of the agent's context, and the model's reasoning capabilities become the attack surface. Architectural responses commenters and follow-on NIST work emphasize, context separation between untrusted inputs and privileged actions, sandboxed execution, human approval for consequential operations, audit logging of full parameters, credential scoping per task, none of which JSON Schema provides.
Procurement checklist mapped to NIST themes. A defensible agent review in 2026 should trace each side-effecting tool to: indirect-prompt-injection controls on every runtime data source; authorization and principal-scoped credentials independent of parse success; human-in-the-loop approval before financial or destructive actions; deployment-environment constraints on agent access; monitoring and measurement of agent security over time. Vendor claims of high tool-calling accuracy on sanitized fixtures address none of these rows unless equivalent controls are documented.
800-5 adoption barrier. The summary notes security concerns "present a barrier to adoption." Enterprises are not waiting for better JSON parsers. They are waiting for adapted controls. Treating schema validation as the finish line misaligns engineering exit criteria with the consensus NIST published in May 2026.
What would have to be true
JSON Schema would need to encode authorization, least-privilege tool scope, business-rule semantics, prompt-injection resistance, and misalignment detection. NIST's commenter consensus requires post-generation authorization, adapted cybersecurity practices, sandboxed execution, human oversight for consequential actions, and deployment-environment monitoring, independent of whether the payload parsed cleanly. A single "valid JSON" gate would need to substitute for the agent-specific control stack 800-5 describes. It does not.
Verdict (supported | overstated | unsupported | too_early)
overstated for money, PII, or infrastructure actions.
Language we will use instead
"We validate arguments against schema and enforce business rules in code after the call. Tool outputs are untrusted input to the next step. We scope credentials per task, log full parameters, require human approval on side-effecting actions regardless of parse success, and treat indirect prompt injection as an architectural risk on every data source the agent retrieves, not a model-quality issue schema validation resolves."