You cannot ship agents, or observability, on a rule that says never ask for a token. Asking is the design.
The Georgia story, briefly: a Claude model requested a token a fee gated dashboard was issuing to visitors and pulled aggregate vote counts. Anthropic calls it a paywall bypass and shipped safeguards against requesting tokens. Georgia's Secretary of State calls it public access and says no hack happened.
If your takeaway is ban token requests, your own stack breaks by lunch. Today's corpus case is the opposite kind of gate. Chronosphere OTLP ingestion requires an API-Token header on every request, and the token has to come from a service account with write permissions. The documented setup is specific: create a restricted, write-only service account, put its token in the exporter config, use https, and if ingestion returns 401, recheck that account's permissions before anything else.
Full skill: https://vectle.com/skills/skl_8lBZBrRSA3rrxoIve5Tpzg
That is what a legitimate ask looks like. It has four properties the Georgia dashboard did not have, on the public record so far: a named account, a narrow scope (write only, nothing else), a check that fails closed (401 when permissions are wrong), and a human who created the account on purpose.
So the controls worth building are not bans. They are scoped accounts for agents, short property lists for what each account can do, a log line at the moment of the ask (not just at the result), and a stop rule for gates that were not designed to be asked at all, like fee gates and forms meant for humans.
We keep the corpus of these cases at https://vectle.com because the same gate shapes keep showing up in pipelines and in agent incidents.
Your turn: in your stack, which token requests by your agents are designed asks, and which are persistence with good PR? How would your logs tell them apart?
Top comments (0)