Yes, if the executor understands destination but the authorizer does not. The JSON can pass validation and every old policy test can pass while the meaning of the request changes. The dangerous mismatch is between the bytes the policy evaluated and the bytes the effectful tool executes. A policy decision must cover the effective action after defaults, aliases, and normalization, not a familiar subset of an evolving JSON object.

I would version the tool's effect contract and its policy together. A request identifies the contract version. The gateway parses with a closed schema for security relevant fields, canonicalizes values, computes the effective destination, and asks policy about exactly that canonical action. Unknown fields in an effectful request fail closed until a reviewed adapter has defined their meaning. additionalProperties: false can catch unknown JSON keys for a particular schema, but it cannot prove that a known field is safe. The actual authorization must evaluate destination, recipient, account, amount, tenant, and approval scope as applicable.

Suppose the old version has an implicit destination of the account's original payment method and the new version allows an external bank account. A request with no field cannot silently inherit different behavior depending on which backend worker processes it. Pin the version and default as part of the accepted operation. If a client asks for the new version, it must carry an approval that includes the new destination. If a model emits the new field while claiming the old version, reject it. If it emits an alias or odd encoding, canonicalize before policy or reject if the result is ambiguous. The logged payload digest should match the executed canonical payload.

The two day coexistence period needs two explicit lanes. Old clients remain on a pinned adapter that preserves old behavior. New clients use a new schema, policy bundle, and tests, with a small canary. The gateway can translate only if the meaning is preserved. If not, return an incompatibility error and make the application upgrade deliberately. In flight runs keep their approved action version, but a stale approval cannot authorize a new effect just because a serializer changed.

I would test the change adversarially: new field set, omitted, empty, encoded differently, redirecting destination, conflicting alias, old client calling new backend, and rollback while new requests are pending. Capture the policy's input and the provider's effective input and compare them. A test that asserts only “HTTP 200” misses the issue. The broader provider format rollout has its own compatibility concerns, but this question is about one security invariant: what got authorized is what gets executed.

Schema validation is still worth doing. It prevents malformed inputs and narrows ambiguity. OpenAI's function calling documentation describes structured tool arguments and strict schemas for supported APIs. That does not make a schema a business permission policy. The new field is a change in possible effects, and it needs an owner who can approve that new capability before the tool ships.