Consent records are bound to the account id in the URL. A normal call with another account's id was rejected. The same call with a matrix parameter on that path segment was accepted, as long as the parameter value was the caller's own account id.
The edge filter matched the decorated segment. The service behind it stripped the parameter and loaded the bare id. The caller, logged in as themselves, received the other account's consent records. A write on the same route appended a consent record to that account. Both accounts were ours. We restored the written state in the same session.
A recheck in November 2026, read-only, still returned the other account's records when the parameter was the caller's id, and still rejected the call when the parameter was someone else's id. A missing token was rejected. An encoded semicolon was rejected as a bad parameter, which is a different failure from the bypass.
What we proved
Byte-level agreement between the bypass read and the account owner's own read, on consent purpose, status, country, language, and timestamp. No name, email, or phone in that payload. The write was the original test, between two accounts we control.
What this is not
Not a dump of a stranger's inbox. Consent state for an account whose id is known: marketing and legal accept/reject records. The id is a UUID, so this is not an open listing of every customer. It is a broken binding once any id is known.
Why a scanner misses it
The rejected call looks like authorization working. The bypass is a path-parameter trick that most clients encode away. A tool that percent-encodes the semicolon never hits the filter split.
Buyer takeaway: Subject binding has to use the same identifier the backend uses. If a filter and a service disagree on what the path segment is, the filter is decorative.
