Tool Schema Default-Fallback Auto-Approve: An Empty Field Is Not a Yes

Modern agents increasingly call tools through structured schemas. A model chooses a function, fills arguments, passes JSON, and a runtime validates the call before dispatch. That is good engineering. It creates typed boundaries where free-form language can become controlled action.

But schema validation is not the same as runtime trust. A schema can prove an argument has a shape while still hiding a dangerous semantic default. If an approval field is missing, null, renamed, or omitted by a fallback parser, the safe result is a hard stop. The unsafe result is “default approved equals true.”

Attackers do not have to win a loud prompt-injection fight if the execution path already has a quiet approval bypass. A malicious message or API response can shape the tool arguments so the consent field disappears. A compatibility layer can auto-fill old defaults. A retry path can drop the explicit denial and dispatch through a fallback that looks valid.

Imagine a checkout form where the “I approve this purchase” checkbox is missing. A safe system refuses to submit. An unsafe system says, “the field is absent, so use the default value from the schema,” and the default value happens to mean approved. That is the whole bug.

In AI-agent workflows, the same bug can live inside function calling, tool routing, API wrappers, JSON schema validators, and compatibility shims. The agent wants to call a tool. The tool expects arguments. Somewhere in the path, a security-critical field is absent. Instead of failing closed, a default or fallback mechanism creates an allow value.

The attack is especially uncomfortable because the payload can look technical rather than persuasive. It may not say “ignore previous instructions.” It may simply cause an argument object to omit consent, set permission to null, rely on a legacy default, or route through a fallback where execute becomes true. Text-based filters can miss that because the dangerous move is not a sentence. It is a missing field.

That is why this belongs in the runtime-trust family. The question is not only whether the JSON is valid. The question is whether the current action has fresh, explicit, source-bound authorization.

An agent receives a tool argument object for a deployment helper. The object includes service name, version, region, and rollout mode, but omits consent. The validator applies a default because earlier internal jobs used implicit consent. The deployment proceeds even though the current user never approved it.

A function schema was updated to require explicit approval, but a compatibility layer still maps missing approval to a legacy default. An attacker shapes the request so the new field is absent. The primary validator would fail closed, but the fallback path fills approval and dispatches the tool.

A first tool call is denied because permission is missing. The agent retries with slightly different arguments after a tool error. During retry normalization, permission: null is treated as “use default permission.” The second call succeeds through data-shape drift rather than real authorization.

Schema validation is necessary. It is not the final authority. The final authority for an agent action should be an action-time trust check that sees the tool, arguments, user intent, approval receipt, policy, and risk together.

A clean system has the opposite shape: missing consent fields cause hard failure; defaults apply only to non-sensitive metadata; security-critical fields are required; and every privileged call receives fresh authorization before execution.

Sunglasses is a content-layer input filter for AI agents. For tool schema default-fallback auto-approve, the defense sentence is: schema validity proves the call is well-formed; runtime trust decides whether the call is authorized now.

That boundary is easy to blur because schemas feel formal. A JSON schema, OpenAPI description, function declaration, or SDK wrapper can look more trustworthy than prose. But attackers can target formal structures too: absence, nulls, aliases, retries, fallback mappings, and defaulted fields can hand the action path a valid-looking object with unsafe authority.

The founding pattern for this category, GLS-TSDF-001, shipped earlier in v0.3.4 (not in this bundle) alongside the structured tool-output authority release. This release completes the family's tool-output flank with nine detection rows — GLS-V3-029, GLS-V3-035, GLS-V3-036, GLS-V3-037, GLS-V3-040, GLS-V3-049, GLS-V3-051, GLS-V3-052, GLS-V3-053 — covering tool output that launders dry-run previews, sync and CI status text, stream checkpoints, and authorization introspection into forged permission. All searchable in the pattern database.

This page is grounded in Sunglasses' tool-calling and tool-output pattern research. It describes an attack model and defense posture for schema-mediated tool execution; it does not claim a specific public function-calling implementation ships an unsafe default.