What you’ll be able to do
- Store API keys where neither the model nor the client can read them
- Treat rotation as routine rather than incident response
- Verify access level at call time instead of assuming it
- Monitor authorized access, not just failed attempts
What you need to know
Where a key lives
Server-side, in an environment variable or a secret manager. That's the whole answer, and the wrong options are worth naming because each appears as a plausible convenience:
- Client-side JavaScript — anyone who opens devtools has your key. Not obscured, not protected, simply published.
- In a prompt — the model can then read it, and anything the model can read it can be induced to output.
- In a tracked config file or CLAUDE.md — committed to version control by design, and present in every clone and every fork of the history.
- In a repository README — the same, with search engines.
Rotation as routine
Rotation on a schedule, not only after a suspected leak. The reasoning: most credential exposure is never detected, so a policy that only rotates on detection never rotates for the cases that matter most.
Routine rotation also proves the mechanism works. A team that has never rotated doesn't know whether they can — which is exactly the wrong time to find out.
Verify at call time
Access level is checked when the action is attempted, not inherited from how the session began. A user whose permissions changed mid-session, or an agent whose task has moved on from what it was authorized for, must be evaluated against current state.
This pairs directly with least privilege: scoping credentials narrowly is what makes call-time verification meaningful rather than theatrical.
Monitor what succeeded
The item people skip. Failed authentication attempts get alerting because they look like attacks. Authorized access monitoring is what surfaces the subtler problem: a legitimate credential being used in an illegitimate pattern — an agent reading ten thousand records when its task needed twelve.
Nothing in the auth layer fires, because nothing about the auth layer failed. Only monitoring of authorized access — volume and pattern against expected behaviour — catches this.
Key concept
Keys live server-side in a secret manager, never in client code, a prompt, or a tracked file. Rotate on a schedule. Verify access at call time. And monitor successful access, because a manipulated agent uses valid credentials.
Practice scenario
Work it through, then open this
Nothing in the auth layer fires, because nothing about auth failed. This is exactly why authorized-access monitoring exists — volume and pattern against expected behaviour. Failure alerting will never see a manipulated agent, because it authenticates successfully every single time.
Build exercise — Find where your keys actually live
Beginner · 20 min
What you’ll learn
- Keeping credentials out of client code, prompts, and tracked files
- Monitoring successful access, not just failures
-
Search your repository history — not just the current tree — for anything resembling an API key.
- Why: Tracked files persist in every clone and every fork of the history. Deleting the line today does not remove it from the past.
- You should see: Ideally nothing. If something turns up, rotation is the response, not deletion.
-
Check whether any credential is reachable from client-side code or ever appears inside a prompt.
- Why: Anything the model can read it can be induced to output, and anything in client JavaScript is simply published.
- You should see: Keys server-side only, in an environment variable or secret manager.
-
Look at your alerting: does it fire on failed authentication only, or on unusual patterns of successful access?
- Why: A manipulated agent authenticates successfully every time. Failure alerting will never see it.
- You should see: Volume and pattern monitoring on authorized access — most teams find this missing.
Exam traps
Putting a key in a prompt
Anything the model can read it can be induced to output. Credentials never enter the context window.
Committing credentials to CLAUDE.md or a config file
Those are tracked by design and persist in the history of every clone.
Rotating only after a suspected compromise
Most exposure is never detected, so detection-triggered rotation misses the cases that matter.
Monitoring only failed authentication
A manipulated agent authenticates successfully every time. Pattern and volume on authorized access is what surfaces it.