Verify Widget Identity Before Sharing Account Data

A visitor opens your support widget and asks why their latest payment failed. The widget sends an email address and an account ID. If the backend trusts those browser-supplied fields, someone who changes the widget request could get another customer's billing details.

The AI agent does not need to behave maliciously for this to happen. It can follow its instructions perfectly and still disclose information that should never have reached its context.

We need to establish identity before retrieving account-specific information, then check whether that identity can access the requested account and resource. Neither decision belongs in the model's prompt.

Treat browser identity as an unverified claim

Support widgets run in an environment the visitor controls. Someone can edit JavaScript, change request payloads, or call an endpoint without opening the widget at all.

An email address passed through a widget initialization call can help populate a contact form. It cannot prove that the visitor owns that address. The same applies to a hidden account field, a conversation ID, or a message saying, “I'm the workspace administrator.”

We should distinguish contact details from authenticated identity in both the backend and the support inbox. Otherwise, an agent may interpret a familiar-looking profile as evidence of account ownership.

An unverified visitor can still ask about public documentation. The boundary changes when the answer depends on private records: invoices, subscription status, workspace members, usage, or previous private conversations.

Establish identity through the application backend

The identity flow should start with the application's existing authenticated session. When a signed-in customer opens support, your backend validates that session and derives the user identity from server-side records, not from an email address supplied by the browser.

If the widget needs a separate identity credential, the backend can issue a signed, short-lived token. Its claims should identify the subject and intended recipient, include an expiry, and bind it to the appropriate application context. Signing secrets and private keys must remain on trusted infrastructure.

The receiving backend must validate that credential before accepting the identity. That includes checking the signature, expected issuer and audience, expiry, and permitted signing method. Decoding a token without verifying it does not establish trust.

A signed token is not necessarily encrypted. Keep unnecessary personal information and secrets out of its payload. Deliver credentials over HTTPS and prevent them from appearing in URLs, analytics events, or routine logs.

For a support lead, the practical acceptance test is straightforward: changing an email address or account ID in a browser request must not change the authenticated identity.

Check account access separately from identity

A valid identity answers “Who is this?” It does not answer “What may they see?”

A customer might belong to several workspaces, have billing access in one, and have limited access in another. A widget's selected workspace is a request for context, not permission to access it.

We should resolve membership and permissions on the server before retrieving private data. Every account-data endpoint needs that enforcement, including endpoints called by AI tools. A tool accepting an arbitrary account ID remains unsafe even if the conversation began with verified identity.

Prefer tools whose account scope comes from trusted server context. If the user asks about another workspace, verify access before switching scope. If access is denied, do not reveal whether that workspace exists or who owns it.

The model can interpret the customer's question. The application must decide whether the requested operation is allowed.

Keep unauthorized data out of the agent's context

Prompt instructions such as “only discuss the current customer's account” are useful guidance, but they are not an access-control boundary.

Once another customer's invoice enters the model's context, the system has already crossed the boundary. Asking the model not to mention it is too late.

Apply permission checks before database queries, private-document retrieval, and tool responses reach the agent. Return only the fields needed for the support task. A payment-status question rarely requires a complete customer record.

The same rule applies to retrieval indexes and caches. Private search results must respect account scope, and cached answers must not be reused across customers when they contain account-specific information. Source citations help explain an answer; they do not grant permission to read its source.

Make verification failures usable for support

When verification fails or expires, the agent should stop account-specific assistance without ending all assistance. It can still explain public product behavior and direct the customer through the application's sign-in flow.

Do not ask customers to paste passwords, session cookies, or authentication tokens into chat. Do not treat an invoice detail supplied in conversation as a substitute for the required authentication flow.

Human handoffs should carry the verification state, authorized account context, and unresolved request. Make clear which details came from trusted application context and which were typed by the visitor. Human agents should follow the same access rules rather than treating escalation as permission to bypass them.

Test the boundary before enabling private answers

Test with altered browser fields, expired credentials, removed workspace membership, and attempts to request another account's records. Include logout and account-switching flows so an old conversation cannot silently retain access to a previous user's information.

Record authorization outcomes and relevant request identifiers without logging credentials or unnecessary private content. Support should be able to distinguish a sign-in problem from a permission denial without exposing the protected record.

Chattering answers questions from a company's website and docs, cites sources, and hands conversations to humans with context. When designing an account-specific integration around that workflow, we should make verified identity and server-enforced permissions prerequisites for private retrieval—not assumptions the AI agent is expected to make.