An agent's tool call contains account ID 9007199254740993 as a JSON number. A JavaScript gateway parses it into a Number, which cannot represent that integer exactly. It can become 9007199254740992 before the downstream service ever sees it. Both IDs might exist. The model supplied the correct digits, the JSON parsed, the schema said “integer,” and the wrong account was updated.

JavaScript's largest safe integer is 2^53 - 1. RFC 8259 calls out this range as the interoperable integer range for implementations with binary64 numbers. The issue is not that JSON's text syntax has a 53-bit limit. It is that some readers immediately coerce a numeric literal into a type that loses precision. MDN's Number documentation gives the exact boundary.

Identifiers should usually be strings at external tool boundaries. They are labels, not quantities to add or average. Accept a decimal string, validate its syntax and namespace, and pass it through without numeric conversion. If a legacy provider insists on a 64-bit numeric field, parse losslessly into an appropriate integer type after validation and serialize using a library that preserves the value. Do not call BigInt(JSON.parse(...).account_id) after the parser has already rounded it.

I would trace raw model tool-call bytes, gateway parsed value, authorization lookup key and provider request bytes for both adjacent IDs around the boundary. Make the executor authorize the exact canonical identifier it sends, not a string representation captured before a lossy conversion. Add a contract test through every language hop with values just below and above 2^53, including a valid neighboring account. If the authorization check used the original ID but the provider saw the rounded one, this becomes a cross-account security incident as well as data corruption.

The pushback is that JSON Schema's integer type should protect us. It says the value has integral form. It does not make every runtime's numeric representation lossless. The system invariant is exact identity from approval through authorization and execution.