API discovery: Mastra’s public request-context contract now includes MASTRA_MESSAGE_AUTHOR_KEY. A server can set it to an object with a required id and optional name and avatarUrl; AgentController sessions then copy that data into the message’s Mastra provider metadata. The new merged source carries it through normal sends, steering, and follow-ups.
Who said that?
Consider a shared support thread. One verified operator submits a customer’s export failure; a colleague later steers the agent toward the account record; a third person asks for a plain-language summary. Without a per-message author, the transcript can show activity while hiding which human introduced or redirected the work. With this key, a host can place the verified person’s identity beside the turn that person actually sent. Mastra’s Factory UI can display that provenance, and a custom interface can read the same stored metadata.
Try it
In the server-side path that has already authenticated the support operator, use the existing request context—not a name received in the browser body:
import { MASTRA_MESSAGE_AUTHOR_KEY } from '@mastra/core/request-context'
requestContext.setRaw(MASTRA_MESSAGE_AUTHOR_KEY, {
id: verifiedUser.id,
...(verifiedUser.displayName ? { name: verifiedUser.displayName } : {}),
...(verifiedUser.avatarUrl ? { avatarUrl: verifiedUser.avatarUrl } : {}),
})
Pass that request context to the session message. The public core tests show the author stamped on a direct message and preserved on a queued follow-up; an unstamped request stays unattributed.
Copy-paste agent instruction
Add verified sender attribution to our Mastra AgentController integration. In server-side auth middleware, after identity verification, write the verified subject—not a client body field—to the existing RequestContext with MASTRA_MESSAGE_AUTHOR_KEY and { id, name?, avatarUrl? }. Pass that same RequestContext to session.sendMessage, session.steer, and session.followUp. Keep MASTRA_RESOURCE_ID_KEY and MASTRA_THREAD_ID_KEY authorization checks unchanged: author metadata is attribution only. Test stamped and unstamped messages at content.providerMetadata.mastra.author, and do not backfill old messages or expose profile data we do not already permit.
Test caveat
This key does not authenticate the author. Mastra’s docs reserve automatic ownership validation for resource and thread keys, so the name is only as credible as the server middleware that sets it. The PR did not test a live two-browser/SSE exchange; old messages remain unattributed; and Factory’s display is not an automatic UI for every Mastra app. Treat the source as an alpha-era implementation receipt, not a stable-release or identity-system claim.