Server-Side Identity Injection

Where identity has to come from

Every multi-user Claude integration has to answer one question before it can scope a response correctly: who is this user, really? The Claude Certified Architect - Professional exam treats the answer as foundational. The user's verified identity and role are established by the authentication layer, and they are injected into the system prompt by the server. They are never read out of the user's own message. That single design choice, identity from the server rather than from the conversation, is what the rest of the authorization topic is built on.

The reason is a trust boundary. The authentication layer sits outside the model conversation and verifies who the user is before any prompt is assembled. Whatever it establishes is trustworthy. The conversation content, by contrast, is fully under the user's control, so anything an identity claim rides in there is only as trustworthy as the user choosing to type it, which is to say not at all. Server-side injection puts the identity on the trusted side of that boundary.

Trustworthy identity scopes the response

Once identity is injected server-side, Claude can shape its response to what that user is authorised to see. A support agent knows it is speaking to a standard customer rather than an internal admin; a records assistant knows which account's data is in scope. That scoping is only sound if the identity driving it is sound. Feed the model a forged role and it will scope to the forged role, because the model has no independent way to verify who it is talking to. The correctness of every scoped response therefore rests on the identity being established by authentication, not asserted in the chat.

This is why the injection has to happen on the server. The server has access to the authenticated session; it knows the verified role and can place it in the system prompt where the model will treat it as ground truth. Handing that job to the user, even implicitly by reading a role field out of their message, hands the user control over their own authorization.

It is required for every multi-user integration

A common misread is that server-side identity injection is a heavyweight control reserved for high-sensitivity systems, banking, health records, and the like, while an ordinary app can take the shortcut of trusting the message. The exam rejects that. Any integration where responses differ by user needs a trustworthy identity source, and that is most multi-user systems. The sensitivity of the data raises the stakes of getting it wrong, but it does not change the requirement. If the response depends on who the user is, the who has to come from authentication.

What the exam trips candidates on

Two traps show up. The first is reading the user's role from a field inside the chat message and treating it as authoritative, which puts identity on the untrusted side of the boundary. The second is assuming server-side injection is only needed for high-sensitivity applications rather than every multi-user integration. The credited answer sources identity from the authentication layer, injects it server-side, and applies the rule universally to multi-user systems.

Common misreadings to avoid

How this shows up on the exam

Expect a design where a role or identity field arrives inside the user message or client payload and is used to scope responses. The reliable reading is that identity must come from the authentication layer and be injected by the server, and that this applies to every multi-user integration. This knowledge point is the base of the authorization topic: it unlocks user-asserted role claims as an attack vector, minimal necessary identity context, and authorization model parity, and it is one of the components you evaluate when spotting auth gaps in an integration design.