Protocol
Exchange broad credentials for task-scoped access
Do not hand an agent the master key when it needs one door for one job.
When it fits
- An agent currently receives a long-lived API key with more authority than the current task requires.
When to avoid it
- Scoped tokens are not a substitute for authorization design, audit or human approval where the impact requires it.
Why it matters
At the tool boundary, exchange delegated identity for a short-lived credential scoped to the resource and action the task actually needs. Keep policy and approval outside the model, and log which authority was granted for each consequential call.
Steps
- Start scope design from the resource and action being requested.
- Issue or exchange for the narrowest practical short-lived credential.
- Enforce scope in the downstream service, not in prompt text.
- Require approval for authority the current task should not receive automatically.
- Log the granted scope with the action.
An example
An incident agent may read the current ticket and restart one service, but it does not inherit a broad cloud administrator key for the entire account.
Check your result
A mistaken model action outside the task's granted scope is rejected even if the prompt asks for it.
Keep this limit in mind
- Scoped tokens are not a substitute for authorization design, audit or human approval where the impact requires it.
Connected ideas
Useful withRun agent actions in the user's authorization context
Evidence and sources
Broad long-lived credentials can be exchanged at runtime for tool-specific, task-scoped credentials so an agent receives only the authority needed for the current action.
Token exchange does not replace authorization policy, approval or audit. The credential issuer and downstream service must actually enforce the requested scope.
It's 10pm. Do You Know Where Your Agents Are? · 4:52-21:32, enforcement point, token exchange, task-scoped credentials and resource-first scope design