What you’ll be able to do
- Keep credentials on the execution side of the tool-calling boundary
- Choose an auth mechanism appropriate to the external service and caller
- Design token scope and lifetime to limit what a compromised call can do
What you need to know
The model requests an action; it should never hold the key
A tool call is, structurally, the model asking your system to do something on its behalf. The credential that authorizes that something belongs entirely on your side of that request — in the tool's execution environment, not in the model's context, not in a parameter the model fills in, not anywhere the model could echo it back into a response or a log the model can read.
This isn't a subtle policy — it's the same boundary that makes a browser's password manager useful: the thing asking for an action and the thing holding the credential that authorizes it are different parties, on purpose, so a mistake or a compromise on one side doesn't hand over the other.
Match the mechanism to the caller, not just the service
- API keys — simplest, appropriate for a single application acting as itself against a service, where fine-grained per-user permission isn't the point.
- OAuth — appropriate when the tool acts on behalf of a specific end user and needs that user's own permissions, not the application's blanket access.
- Service accounts / short-lived tokens — appropriate for server-to-server calls where the "who" is the system itself, and where a short lifetime limits the damage if the token leaks.
The architect's job isn't memorizing this list — it's matching the mechanism to who is actually being authorized. A tool that reads a specific user's private calendar needs that user's own delegated permission (OAuth), not a service-wide API key that would let the application read every user's calendar regardless of which one asked.
Scope and lifetime limit the blast radius, not the likelihood
Every credential eventually risks exposure — through a misconfigured log, a dependency vulnerability, or a tool bug that echoes more than intended. Scoping a token narrowly and giving it a short lifetime doesn't prevent that; it limits what the exposure is worth. A token scoped to "read this one resource type" and expiring in an hour is a minor incident. A token with account-wide write access that never expires is a severe one — for the exact same exposure event.
"The tool only reads data" is not a reason to skip scope review. A broadly-scoped read credential can still enumerate and exfiltrate far more than the tool's stated purpose requires, and the fix — a narrower scope — costs nothing at build time.
Key concept
Credentials live on the execution side of the tool boundary, scoped to exactly what the call needs and no longer than it needs it. The model should never see, hold, or be able to leak the key that authorizes an action it merely requested.
When a scenario describes a credential appearing in a prompt, a tool parameter, or a place the model's context could surface it, that's the violation under test — regardless of how convenient it made the implementation.
Practice scenario
Work it through, then open this
A tool parameter is part of the call the model constructs and can appear in its context — the token should never have been placed there. The fix is moving the credential entirely into the tool’s execution environment (an environment variable or secret store the handler reads directly), so the model only ever sees a request like “post this message” with no path to the credential that authorizes it.
Build exercise — Find a credential on the wrong side of the boundary
Foundational · 20 min
What you’ll learn
- Auditing where a tool’s credentials actually live relative to model context
- Matching an auth mechanism to who is being authorized
- Scoping a credential to limit blast radius rather than likelihood
-
For one tool in your system that calls an external service, trace exactly where its credential is stored and confirm the model never sees it in a prompt, parameter, or response.
- Why: This is the single most consequential check in the domain — a leaked path here compromises the external service directly.
- You should see: A credential that lives only in the execution environment, or a violation worth fixing immediately.
-
For the same tool, check whether its credential’s scope matches what the tool actually needs, not what was easiest to provision.
- Why: An over-scoped credential turns a minor tool bug into a major incident.
- You should see: Either a tightly scoped credential, or an obvious candidate for narrowing.
Exam traps
Putting an API key in a prompt or tool parameter the model can see
The credential boundary is violated the moment a key enters anything the model’s context includes.
Using one long-lived, broadly-scoped credential for every external call
It maximizes the damage of any single exposure instead of limiting it.
Assuming a tool’s auth is fine because it worked in testing with one user
Testing with one user’s broad access hides scope problems that surface only at multi-user scale.
Letting a tool’s error message leak part of a credential or token
Error content is still model-facing content and needs the same scrutiny as any other output.
Skipping scope review because “the tool only reads data”
A broad read scope can still expose far more than the tool’s stated purpose requires.