Connector identity
When the assistant calls a tool on your custom MCP server, Use Brian can tell your server who the end user is. The identity is resolved by Use Brian's backend from the authenticated session and sent as request headers, so your server can authorize per user. The model never sees or sets it, so it cannot be fabricated.
How your server learns who is calling
The sender identity is resolved server-side and attached as headers. The model only chooses the tool and its arguments, so it can never fabricate or alter who the request is for.
- 01SenderAuthenticated session
The verified end user sends a message on web, WhatsApp, Telegram, or Slack.
- 02Server-sideUse Brian resolves it
The backend reads the sender from the session. The model is never asked.
- 03HeadersX-UseBrian-Actor-*
The identity is attached to the request to your server, on discovery and every call.
- 04Your serverAuthorize on the header
Read the header to look up the user or scope the response.
The model only chooses which tool to call and its arguments. It is off this path: it never receives the identity, so it cannot hallucinate or change it.
Headers your server receives
Sent on the discovery calls and on every tool call, once the connector owner has enabled identity for your connector.
| Header | Value |
|---|---|
| X-UseBrian-Actor-Channel | The channel the message came from: web, whatsapp, telegram, or slack. |
| X-UseBrian-Actor-Id | The channel-native id of the sender: email on web, phone on WhatsApp, @handle on Telegram, user id on Slack. |
| X-UseBrian-Actor-Email | The sender's email when known, even on a channel turn. May be absent. |
| X-UseBrian-User-Id | The stable Use Brian user id. Use this as the durable key; the channel-native id above can change. |
X-UseBrian-Actor-Channel: telegram
X-UseBrian-Actor-Id: @alice
X-UseBrian-Actor-Email: [email protected]
X-UseBrian-User-Id: 7c2a9f04-...-e91When the headers are sent
Identity is off by default and opt-in per connector. The workspace owner enables it under Connectors, Settings, Send signed-in user identity. It applies to custom MCP servers only. Once enabled, every request to your server carries the headers.
The contract that keeps it un-forgeable
These headers are only as trustworthy as how your server uses them. Follow all four rules.
Authorize on the header, never on a tool argument
A tool argument is filled by the model and can be hallucinated or steered by the user's text. The header is set by Use Brian's backend after the model produced its call, so the model cannot touch it. Identify the user from the header only.
Do not expose an identity parameter in your tool schema
If your tool has a user or email parameter, the model will fill it, which reintroduces exactly the value you cannot trust. Leave identity out of the schema and let the header be the sole source.
Authenticate the connection
Give your connector a bearer token or a custom auth header. The identity header is trustworthy because only Use Brian can reach your authenticated endpoint, the same model as a reverse proxy adding X-Forwarded-User. On an open endpoint, anyone could send the header, so it would mean nothing.
Key on the user id
Store and match users by X-UseBrian-User-Id. The channel-native id and email can change; the user id does not.
Why the assistant can never fabricate it
The identity is resolved from the authenticated session, which the model never reads, and it is attached to the request after the model has produced its tool call. The model has no path to read, set, or alter it. User-configured headers also cannot use the X-UseBrian- or legacy X-Sidanclaw- prefixes, so the namespace cannot be spoofed from configuration either.
Other headers
Beyond identity, a connector owner can attach fixed preflight headers (for tenant, routing, or tracing) and the connector's own auth header. Identity uses the reserved X-UseBrian- namespace and always takes precedence. During the rebrand transition each header is also sent with its legacy X-Sidanclaw- twin; new integrations should read X-UseBrian- only.