Valid JSON is not permission to act

JSON Schema validation is a check that a JSON value satisfies declared constraints. Authorization is a decision about whether a particular caller is permitted to perform an action on a particular resource.

Parsing, validation, authorization and execution return different results. Parsing produces a usable value from JSON text. Validation determines whether that value fits the schema. Authorization determines permission. Execution attempts the operation and reports what happened.

A schema defines the accepted request

Take a tool that exports a case record. This Draft 2020-12 schema requires a record identifier and an export format:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "record_id": {"type": "string", "minLength": 1},
    "format": {"enum": ["pdf", "json"]}
  },
  "required": ["record_id", "format"],
  "additionalProperties": false
}

The schema rejects an absent identifier, an empty identifier, an unsupported format and extra fields. Merely listing a field under properties would not require its presence; required supplies that constraint. In this schema, additionalProperties: false excludes names not declared under properties.

The request {"record_id":"case-123","format":"pdf"} passes. So does the same request with case-999. The schema contains no registry of cases and no relationship between a case and its requester. Both identifiers meet its declared constraints.

Permission depends on trusted context

The application must resolve the identifier to the resource on which it will act. It then evaluates whether the authenticated caller can export that resource in the requested context. A model’s claim that the user owns the record is request content, not authenticated evidence of ownership.

A schema can contain an allowed set of identifiers. That makes membership in the set a validation rule. The application still owns the security question: who constructed the set, which caller it applies to and whether it remains current. Encoding a permission-dependent value in a schema does not remove the need to establish that permission.

The Model Context Protocol’s June 18, 2025 Tools specification treats input validation and access control as separate server requirements. That distinction applies even when a tool exposes a detailed input schema. MCP Tools specification.

The executor must apply the decision

A policy engine can return permission without performing the operation. Open Policy Agent separates those functions: it evaluates structured input against policy and data, while the integrating application enforces the result.

If the export endpoint remains callable without the permission check, the decision service does not control that route. If the record changes after authorization, execution must not silently target the replacement under the earlier permission.

The integration also defines what happens when policy evaluation fails, returns an unexpected value or supplies no decision. A design requiring positive authorization cannot treat those conditions as permission.

Verification follows the action through

A boundary check uses requests that separate the stages. A malformed request tests validation. A well-formed request for another user’s record tests authorization. A denied request sent directly to the executor tests enforcement. An allowed request whose export fails tests outcome reporting.

Passing one of these checks does not imply passing the others. A structured tool call is a proposal precise enough to evaluate; its structure does not grant authority or establish completion.