Vouched per-call caller identity for third-party MCP servers

[kkolodziej7]

Problem. A third-party MCP server configured for Claude or Codex sessions in T3 cannot tell which T3 thread is calling it. Tools that act on behalf of the calling thread (claim a role, send or sign a message as that thread) need an identity another thread cannot forge. T3's own t3-code server gets this from the per-thread session-registry bearer injected into each session's MCP config; third-party servers receive nothing equivalent, only self-asserted values (environment variables, _meta thread ids, tool arguments).

Today's workaround. Reconstruct identity from the native side: match the Codex _meta thread id or the Claude session marker to a native process, join it read-only to the app thread in T3's local store, then corroborate it with GET /api/orchestration/shell on every identity-bearing call. This couples us to process trees and the store schema, can break with driver changes, and costs a full environment shell read per call on the single reader.

Proposed shape. For MCP servers the user marks as trusted, T3 forwards a per-call identity assertion issued from the existing session registry: a short-lived signed token (issuer = environment, audience = that server; claims: environment, thread, provider instance, run, expiry) in a request header, with a public key or verification endpoint. Both Claude and Codex drivers inject it the way they inject the t3-code header today; revocation follows the session credential. An unsigned config header is forgeable, and exporting the t3-code bearer would grant far more than identity.

Benefit. Third-party servers drop process discovery and per-call shell reads, which also takes load off the reader.