The MCP server holds PK_AUTHDOG. The caller holds the bearer. Whichever process mints a client_credentials token also holds the client secret. The sample's token_verifier accepts the token when userinfo does, whether the subject is an agent or a person.
Two ways to get the bearer
Caller
How they get a token
Unattended agent
client_credentials at the environment token endpoint. The exchange is in Agent frameworks.
An RFC 8693 token in the same Authorization header. sub stays the user. act names the agent.
Which machine credential
Credential
Use it when
Agent identity
A named agent, with verify, revoke, and allowed tools. Agents is sales-gated until access is approved.
M2M application
A backend or job, or Agents access is not approved yet. Same grant.
Personal access token
One person's local script. Keep it out of the MCP server process.
Service account
Authdog REST automation. Not what token_verifier is written to consume.
There is no refresh token on the client_credentials response. Repeat the exchange before expires_in. User tokens from the hosted login follow the session lifetime and can be revoked from Connected Apps.
Where each value goes
Variable
Process
PK_AUTHDOG
MCP server. Selects the identity host.
MCP_RESOURCE_URL
MCP server. Passed to AuthSettings. Defaults to http://127.0.0.1:8000 in the sample.
AUTHDOG_CLIENT_ID / AUTHDOG_CLIENT_SECRET
The process that mints the agent token. The server does not read them.
Access token
Authorization header on POST /mcp.
A vault API key is not this bearer. The verifier calls userinfo with the access token.
