Identity & attribution

"Which agent called this tool?" is a question the logs answer on their own. "Whose agent, and on behalf of which user?" is not. That answer lives inside the credential the caller presented, in a shape only you know. Identity configuration is how you tell Elva where to find it.

Once configured, the client and user identifiers appear on every tool-call log entry and on every webhook delivery, so MCP traffic can be attributed the same way the rest of your platform is.

Two identifiers, declared separately

Each MCP server configures two sources independently, because they answer different questions and are rarely found in the same place.

Each can be drawn from one of several places:

• oauth_client_id: the OAuth client_id the caller authenticated with. Client ID only.
• scope: a named capture group from a pattern you supply, matched against the OAuth scope string.
• token_claim: a claim you name, read from the caller's JWT.
• header: a request header you nominate.
• none: nothing is recorded.

Why your user IDs may be empty

This is the one result that surprises people, and it is a property of OAuth rather than of Elva. Under the client_credentials grant there is no end user. The scope is fixed when the connection is established and sent unchanged on every later call, so anything embedded in it identifies a connection, not a person. A thousand employees behind one service account produce exactly one identifier.

Genuine per-user attribution therefore needs one of two things:

• One connection per user, so that the credential itself is the identity.
• A per-request header, where your client passes the acting user on each call and you point the User ID source at that header. This is why header is an available source rather than an afterthought.

Where to go next

MCP authentication and OAuth

How the gateway authenticates, and which grant your deployment is using.

MCP insights and logs

Where these identifiers show up once you have configured them.