The current answer to “how does my agent call this API on my behalf?” is usually: put a key in an environment variable and hope. The key is long-lived, it is scoped to everything, it is shared across every user the agent serves, and if the agent is compromised, so is the key.
What you build
An agent that calls a protected resource as you, specifically — and which, if you dumped its entire memory to disk, would reveal no credential at all.
You sign in. Your agent presents a token that says who you are. The Gateway verifies it, decides whether this caller may make this call, and attaches the upstream credential itself — scoped to you, on the far side of a boundary the agent cannot reach across.
Why it matters
This is the difference between an agent that has your permissions and an agent that has your credentials. The first is a delegation you can reason about, audit, and revoke. The second is a copy of your keys in a process you do not fully control.
Every enterprise you have worked in has an approval process built on the assumption that credentials and permissions are the same thing. They are not, and the demonstrable proof is a good thing to carry back.
Try to break it
Ask the agent to reveal the credential. Read the request in Payload Capture at the stage before injection. Then sign in as somebody else and confirm you get their data and not yours.