Agents should not hold credentials
A token in the context window is a token in the transcript, the logs, and eventually the incident report.
Where secrets end up
The common pattern is to hand an agent an API key so its tools work. That key now lives in the context window, which means it also lives in whatever stores that context: transcripts, traces, evaluation datasets, debugging dumps, screenshots in a ticket.
None of those stores were designed to be a secret manager, and most of them are readable by more people than the key ever should have been.
The broker pattern
The alternative is to keep upstream credentials in a vault the agent cannot reach, and mint a token per permitted call: scoped to that call, time-boxed, single-use, injected by the gateway rather than passed through the model.
The agent gets access without ever holding authority. A leaked token is worthless outside the window it was minted for, and the blast radius of a prompt injection stops at what policy already allowed.
Scrub the return path too
Inbound protection is only half of it. Tool responses routinely echo credentials, signed URLs and session identifiers. If the response goes into agent context unscrubbed, you have re-created the problem from the other direction.
What this does not solve
Brokering does not stop an agent from misusing access it legitimately has. That is policy's job, not the broker's. What it does is make the credential itself a non-event, so one class of catastrophic, irreversible leak simply stops being possible.
Decision boundary: Gleis evaluates each tool call against the policy your organisation approved and the evidence collected at the gateway. It does not determine legal rights, certify compliance, or replace legal review.