A standing API key is access that never ends. A scoped, short-lived credential is access to do one thing for a few minutes. For an AI agent, the second is the only responsible default, and PastKeys mints it per operation so nothing long-lived ever reaches the agent.
What "scoped and short-lived" means
When an agent asks to perform an operation, the broker produces a credential that is limited to that operation and set to expire quickly, uses it, and lets it lapse. The agent receives the result, never the credential. A leak is then worth little: the credential is already narrow and already expiring.
How it works per provider
AWS
The broker uses STS to assume a role and returns temporary credentials scoped by the role's policy, valid for a short session. The agent never holds your long-lived AWS keys; it gets the outcome of the call the broker made.
GitHub
The broker performs the GitHub operation with a token it holds and governs by policy, so the agent cannot read the token or use it outside the allowed operations. Access is mediated per call rather than handed over as a reusable secret.
Postgres
This is dynamic secrets in the classic sense. For each operation the broker connects as an admin credential it holds, creates a temporary login role that inherits a least-privilege base role and is VALID UNTIL a short TTL (15 minutes by default), and runs the operation as that role. Login is disabled automatically at the TTL, and a background reaper drops the expired role objects so they do not accumulate. The agent gets query results, never a database password.
Policy and audit around every mint
Minting is always gated by a default-deny policy: the broker produces a credential only for an operation a rule allows, and writes one audit record per request. You get least-privilege access, short lifetimes, and a complete trail, without putting a provider secret in the agent.
See getting started to set this up, or the whitepaper for the full design.