Skip to content

Validate AI Tool Result Schemas

Parse AI tool responses into bounded approved fields and reject malformed, oversized, or unexpected output.

A tool result is an input to the next model decision. A malformed result can make an agent use a wrong identifier, display private fields, or treat an error as success. Define the expected shape at the tool boundary and reject surprises before the model sees them. OWASP's secure MCP guidance calls for strict validation and careful treatment of tool responses.

Begin with one tool and the smallest useful result. Distinguish required data from optional display fields. Put an upper bound on arrays, text, and nesting. If the upstream API adds a new field, the adapter should not automatically pass it through to the model. Unknown fields may contain secrets or instructions.

Result contract

FieldRuleFailure case
recordIdNon-empty stable IDMissing or wrong type
statusKnown enumUnexpected value
summaryBounded plain textOversized or instruction-like text
ownerDerived from trusted sourceCross-tenant or client-supplied owner
nextCursorOpaque bounded tokenUntrusted URL or command

Keep raw upstream responses outside model context. Parse into a new object with only approved fields. A JSON schema check proves shape, not truth, so also verify ownership and source identity. Do not let a field such as suggestedAction become an executable instruction just because it is valid JSON. Treat it as data to display or reject it.

Fixture tests

Use an owned mock that returns the normal shape, then remove one required field, add an unknown secret field, expand an array beyond the limit, and return a nested object where a string is expected. For each malformed case, the adapter should fail closed with a typed error. The model should receive neither the raw body nor a misleading partial success.

Add a positive control that proves the normal response remains useful. Record the validator version, exact fixture, rejected field class, and resulting tool event. If a schema change is intentional, review it together with the tool catalog and authorization rules. New fields can change what an agent knows even when the tool's name and permission remain the same.

Know what your agents can reach

Map data access, tool actions and approval boundaries before testing. Use the scope guide, or discuss a review of your AI application.

Sources

  1. OWASP Top 10 for LLM ApplicationsAccessed
  2. OWASP Practical Guide for Secure MCP Server DevelopmentAccessed