A nightly batch job with no human present must call tools on a remote MCP server to reconcile records. Which authorization approach fits this machine-to-machine case?
Select an answer to reveal the explanation.
Short Explanation
A night watchman doesn't borrow the manager's keys; he carries his own. The trap is reusing your own token for a robot job: when no human is in the loop, the client should prove its own identity.
Full Explanation
Standard MCP authorization assumes a resource owner who can approve access in a browser. The OAuth Client Credentials extension covers the case where no user is present: background services, CI/CD pipelines, daemons and server-to-server integrations authenticate with application-level credentials, either a signed JWT bearer assertion, which is the recommended form, or a client ID and secret, and receive an access token without any redirect. Borrowing an engineer's refresh token ties the job to a person, breaks when that person leaves or the token is revoked, and misrepresents who acted in audit logs. URL-mode elicitation directs a human user to an external page; an unattended job has nobody to consent, and elicitation is not how a client authorizes itself to an MCP server anyway. Enterprise-Managed Authorization delegates employee access decisions to the corporate IdP and still starts from a person's SSO login, so it does not fit a service identity. Exam caveat: the extension is optional and must be declared in the client's per-request capabilities; client secrets are long-lived and should be stored in a secrets manager and rotated. Operational check: confirm the server's authorization server accepts the client credentials grant for this client and that the issued token carries only the scopes the reconciliation needs.