Installation, identity and privacy
Does a visitor’s email address prove their identity?
No. A visitor typing an email address into chat does not prove that they own the address or the associated account. Use identity established by your authenticated application and signed on your server before allowing support integrations to retrieve private account information.
What can a typed email address be used for?
It can provide a follow-up destination, subject to the delivery and verification behavior of your product. It is not sufficient authority to disclose billing records, identity documents, or another customer’s activity. Anyone who can type into a form can enter someone else’s address.
What should a signed identity contain?
Use a stable account identifier established by your server and the signing mechanism documented by your chat product. Keep the signing secret on the server. Do not generate trusted identity claims in browser code where a visitor could inspect or replace the secret.
Who decides which records may be returned?
Your integration must map the verified account to the records it is allowed to access. Treat model-generated tool arguments as untrusted input. Signing an identity does not replace authorization checks in the system that holds the data.
Practical checklist
- Distinguish contact details from authenticated identity.
- Create trusted identity on the server.
- Authorize every private record lookup.
- Test an unverified visitor and a different signed-in account.
Worked example
Someone types the billing email of another company and asks for its payout status. That address alone must not enable the lookup. A signed-in customer should receive only records authorized for the stable account identity supplied by your application.
How Fire Away fits
Fire Away supports server-signed visitor identity. Its private support tools use the verified subject rather than allowing the model to choose whose account to query.