The agent knows who it is talking to

Consider a support agent that can cancel subscriptions. A visitor opens the chat and says: "I am [email protected], please cancel my plan." Should the agent do it?

Obviously not. An email address typed into a chat box is a claim, not a credential. Anyone can type anyone’s email address. Any agent that acts on account-specific requests based on what a visitor asserts about themselves is one determined person away from a serious incident.

The usual response to this is to refuse to automate anything sensitive, and route every account-related question to a human. That works, and it also means the AI is only allowed to handle the questions that were not costing you very much anyway.

Your application already knows who is logged in. It authenticated them. The problem is that the chat widget, running in the browser, has no way to trust anything the browser tells it.

A signed identity token closes that gap. Your backend takes the user it has already authenticated, puts their ID and email into a token, and signs it with a secret shared only with your agent. The widget passes the token along. The agent verifies the signature before it does anything with the contents.

A forged token fails the signature check. A copied token belongs to whoever it was minted for. The visitor cannot manufacture one from the browser, because the secret is on your server and never goes near the client. That is the entire security property, and it is enough to make account-specific automation safe.

Identity can be optional or required, and both are legitimate designs.

Optional is right for a marketing site with a logged-in area: anonymous visitors still get help, and signed-in customers get an agent that knows their plan and their history without asking. Required is right for a customer portal, a WHMCS client area, or anywhere the agent is only ever meant to be talking to real customers. There, the agent will not engage without a valid token.

You can also update identity part-way through a conversation. If someone starts chatting anonymously and then logs in, they become verified from that point, in the same thread. They do not have to start again.

On its own, verified identity is a nice piece of context. Combined with agent actions, it is the thing that lets you automate the expensive half of your support queue.

The pattern is simple. The action gives the agent the ability to call your API. The identity token tells the agent which customer to call it *for*, with proof. Together they let you safely say: this agent may cancel the subscription of the person it is talking to, because it knows, cryptographically, who that is. Without the identity half, that same action is a liability. Rotate the shared secret whenever you need to, and nothing about your widget installation has to change.