A server issues step-up scope challenges when users first try privileged tools. Security auditors want to review how permissions grew over time. What should the server log, according to MCP's scope minimization guidance?
Select an answer to reveal the explanation.
Short Explanation
You want a trail of breadcrumbs showing every time someone asked for a bigger key and what they actually got. That's scope requested, scope granted, and a correlation ID to tie it to the request. Logging the tokens themselves just hands thieves a souvenir.
Full Explanation
The scope minimization section of the security best practices tells servers to emit precise scope challenges rather than returning the full catalog, and to log elevation events, recording the scope requested and the subset granted, with correlation IDs. Because authorization servers may issue only a subset of requested scopes, logging both values shows auditors exactly how each permission expanded and lets them tie each event to the operation that triggered it. Logging full access tokens creates a store of live credentials; token theft guidance warns that tokens cached or logged on a server can be used by attackers in requests that look legitimate, and log policy forbids credentials in log messages. Logging only failures misses the very events auditors care about, namely successful privilege growth. clientInfo is self-reported and unverified, and the specification says it should not be relied on for security decisions, so it cannot prove who requested a scope; the verified token subject can. Exam caveat: the same guidance warns that a single omnibus scope masks user intent per operation, so elevation logs are only meaningful when scopes are fine-grained. Operational check: trigger a step-up flow in a test environment and confirm one log entry records the challenged scopes, the granted scopes, the user subject and a correlation ID, with no token value.