Why does tool-call argument validation that checks type, length and format pass an attacker-written value?

## Validity is a property of the value; authority is a property of its origin ### What an argument validator actually has in front of it When a tool call is validated, the checker is handed a value and a rule. The rule expresses admissible *shape*: this must be a string, of this length, matching this pattern, drawn from this set, within this range, satisfying this checksum. The checker evaluates the rule against the value and returns pass or fail. Now look at what is *not* in front of it. Not who authored the value. Not which stage of the pipeline produced it. Not whether it came from an internal record or from a document an outside party submitted this morning. Provenance is simply not an input to the function, so no configuration of the function can be sensitive to it. This is not a weak validator or a badly written schema; it is a category difference between the question the layer answers and the question in dispute. ### Two predicates, easily confused - **Validity**: does this value belong to the set of values this argument may take? Determined entirely by the value. - **Authority**: is this the value that the party entitled to choose it actually chose? Determined entirely by where it came from. A value can be perfectly valid and completely unauthorised. That sentence is the leaf. Everything else follows from it. ### Why a stricter format does not move the needle The instinct on seeing this class is to tighten the rule. It rarely buys anything, and it is worth being able to say why. Identifier formats — account strings, reference numbers, structured codes — are designed to be *self-verifying*: a checksum or a fixed structure lets any consumer confirm the string is well formed without consulting anyone. That property is a feature for the legitimate ecosystem and it is available symmetrically. Anyone with an account of their own has a well-formed identifier for it. A stronger format check makes the attacker's value *more* obviously correct, not less. The rule constrains the set of expressible values; the attacker only needed a value inside that set all along. Amount and range limits are worth separating out. They genuinely constrain magnitude, so they bound what a single instance is worth — but a payment within policy is exactly the shape of instance this class produces, and the beneficiary field is untouched by any bound on the amount. ### Enumerations are the interesting case An enumerated argument behaves better than a free-form identifier, because every admissible member was sanctioned in advance by whoever wrote the enumeration. The attacker cannot introduce a new member; the value space is closed. That is a real reduction, and it is not immunity. If two members of the enumeration differ in consequence — a scope that covers one record against one that covers a class of them, a mode that notifies against one that does not — then choosing between sanctioned members is still a choice, and the validator has no basis to prefer one. The narrower the enumeration and the flatter the consequence across its members, the less there is to influence. ### What this is not This is not a value that fails the schema. An out-of-enumeration string, an invented identifier that resolves to nothing, a type mismatch — those are accuracy and reliability defects, they are caught by exactly the layer under discussion, and they belong to a different subject. The whole difficulty here is that the value is in-specification *by construction*, because being in-specification is what lets it reach the operation at all. Nor is it an escape into another interpreter — no quoting boundary is crossed and the value is consumed as a value. And it is not a claim about the validator being poorly built. The best-written schema in the world evaluates the string. ### Where a check on an argument does bite It bites where the admissible set for this call is not a general rule but a specific one derived from state the outside party did not author — for instance, where the value must correspond to something already fixed by the request that opened the workflow. Then the comparison is against a source rather than a shape, and the property being tested is finally the one in dispute. That is a statement about where the class stops working, not a recipe: wherever the argument's value is a free choice constrained only by form, form is all any checker on that path can test. ### Direction of the claim A validation pass proves the value satisfied a shape rule. It does not prove the value is correct, does not prove anyone with authority selected it, and does not prove the operation will land where the requester intended.