An agent asks its HTTP tool to fetch 0.¹.0.0. That is not an IP address, and the egress allowlist standing in front of the tool agrees, so the request goes through. UTS-46 mapping then folds the superscript one down to a plain 1, and what the socket opens is 0.1.0.0, which the allowlist would have refused on sight.

Nothing technically malfunctioned. The guard and the runtime read the same request and saw different bytes, and in an agent stack that is architecture rather than accident. A guardrail, a policy engine, a tool runtime, a provenance verifier: each sits behind a decode boundary, some distance from whatever finally consumes its input. Agent architectures multiply those boundaries. Check ahead of a transform and you have approved something the transform is about to change. Check after a decode and whatever the decode discarded is already gone. The boundary decides which mistake you get.

I have watched this happen six times now, independently, in reviewed code written by people who knew the rule perfectly well. Myself among them. Twice. One vocabulary-safety check passed a label because what it inspected was a decoded string; the bytes underneath were ill-formed CESU-8, and a lenient decoder had substituted them long before the check ran. Another: five implementations of one specification, handed byte-identical bytes, rejected them unanimously and disagreed about why. Three tested the parse type, so 1e2 fails as a non-integer token. Two tested what the literal denotes, so the integer 100 fails only because 1e2 spells it wrong. All five reject, so no accept-or-reject conformance test can see the disagreement.

Check the bytes the consumer will actually act on, not whatever arrived at your door.