Skip to main content
Customer-supplied data arrives from sources a visitor can manipulate: chat widget variables come from the browser, and email From: headers can be spoofed. The Trusted only check on an action or lookup input locks that input to verified values: the AI Agent runs the tool only when the mapped context variable arrived through a trusted path on this conversation. When it didn’t, the tool doesn’t run. This lets your external system validate permissions against real identity: that a customer is refunding their own order, editing their own account, or reading their own data.

​
Which inputs to protect

Use Trusted only on every input that decides who the action runs for: user_email, tenant_id, account_id. Use Static for fixed configuration (API region, default priority). Leave inputs on Auto only when the customer is the legitimate source of the value (an order number for their own order, a free-form reason). For the mechanics, declaring variables, mapping inputs, per-channel trust paths, and the failure outcomes, see Context Variables.

​
What the check guarantees

  • A Trusted only input never runs with an unverified value. The check runs outside the AI, so no conversation content can satisfy it.
  • An unverified user_email triggers customer verification: a one-time code on chat (what the customer sees), a reply on email. Any other unverified variable hands the conversation to a Human Agent. Full table: when a Trusted-only input is not satisfied.
  • To verify the customer before any Trusted-only input comes up, mention the Verify email address system action in Specialist instructions or channel guidelines.

​
What it doesn’t guarantee

Trusted only is not a substitute for permission checks in your integration. A “Refund order” tool must still confirm the user_email has access to the order_id. Typewise guarantees only that the value is trustworthy.

​
See also