Describe five steps: how you would detect it, how fast you can revoke the token, what the token could reach, how you rotate dependent credentials, and how you review logs for misuse. The strongest answer shows the blast radius is small because scopes were narrow and tokens short lived.
Why this question is a design test
The question sounds like incident response, but it tests design. If a leaked token can read everything forever, the incident path is long and painful. If it is scoped and short lived, the path is short.
The MCP security guidance gives an example of a token with broad scopes obtained through log leakage, memory scraping or local interception, and says poor scope design increases impact and obscures audit trails. The authorization specification says authorization servers should issue short-lived access tokens and that refresh tokens for public clients must be rotated.
The five steps
- Detect. Sources include a user report, a vendor or scanner alert, unusual tool calls in logs, or a token turning up in a repository. Say which you have and which are planned.
- Revoke. Name who can do it and how long it takes. "An administrator can revoke a client immediately from the console" is a good sentence if it is true.
- Assess reach. Use the scope list to state what the token could do. Narrow scopes make this a one line answer.
- Rotate. Replace the token and any credential the same server held for downstream systems. Do not forget configuration files and environment variables on laptops.
- Review. Search logs from the exposure window for calls the legitimate user would not make, and record the outcome.
Prevention you can mention
| Control | Effect on a leak |
|---|---|
| Short lived access tokens | Shrinks the usable window |
| Refresh token rotation | Detects reuse and limits theft |
| Per user, per server tokens | Contains the damage |
| Narrow scopes | Limits what can be done |
| Keeping secrets out of git | Avoids the most common leak path |
See short lived tokens and refresh rotation and keeping MCP secrets out of git.
Sample wording
"Tokens are issued per user and per server with narrow scopes and short lifetimes. If a token is reported exposed, the security team revokes it, assesses reach from its scopes, rotates related credentials and reviews tool call logs for the exposure window. We record the outcome and notify affected customers where our agreements require it."
What not to promise
Do not promise detection of every leak or a fixed response time unless you have measured it. A drill makes any number believable, so run a small tabletop and keep the notes.
Evidence
The revocation procedure, a tabletop record and the scope list. Safeguard's agent identity gives each agent its own identity that can be revoked separately, and the MCP Guardrail limits which tools it may call.
Quick check
Do we notify customers about every leaked token?
Not automatically. Notification depends on whether customer data was reached and on your contracts, so check with counsel. Say that in your answer rather than promising either way.
How do we find a token in a repository?
Use your existing repository controls and review process. Then rotate regardless of whether anything was misused.
Sources
Last reviewed: 19 October 2026.
