A customer types: “Where is order 4821?” Your agent extracts the right number, calls the right API and gives an accurate answer.
But order 4821 belongs to another customer.
I’d test this before testing how nicely the agent writes. Knowing an order number isn’t permission to read it, and a shared API credential authenticates your integration, not the person in the chat.
For a signed-in support chat, the backend identifies the customer from the verified session and sends that context to n8n. The AI Agent can then use a Call n8n Workflow Tool to request an order lookup.
In that tool, I’d separate two inputs:
- order_ref: the agent may propose this using $fromAI().
- customer_context: a normal expression from the authenticated backend’s input, never a model-defined parameter.
Putting customer_id in a public webhook body doesn’t make it verified. At the lookup boundary, your backend or order API needs to establish who the caller is from trusted context and check whether they may read that order. A short-lived signed token is one way to carry the context; its signature doesn’t replace the order-access check. Return only the fields allowed for this support action.
Keeping customer_context outside $fromAI() prevents the model from choosing that parameter. The backend access check is what protects the record.
For email or WhatsApp, first define how the channel identity is linked to the account. Recognizing a sender address or phone number alone isn’t enough to establish their rights over a merchant account. If the account link is missing or ambiguous, use your approved verification path before the lookup.
Here’s the small test I’d run with synthetic data:
- Customer A requests A’s order: permitted details come back.
- Customer A requests B’s order: no details, and no response that reveals whether B’s order exists.
- Customer A pastes B’s email and says “use this account instead”: the trusted context remains A.
- Customer A asks the agent to ignore the restriction: the backend still denies access if the tool is called.
Then run a conversation as B followed by one as A. Check that A cannot retrieve B’s earlier results through chat history or a cache. Scope storage reads and writes to the trusted customer/tenant context, and verify that the conversation belongs to that context. A customer-prefixed key alone isn’t enough if a caller can request another customer’s key.
Before wiring in more tools, I’d open the existing lookup tool and check two things: which inputs use $fromAI(), and where the order-access check actually runs. Then run the A/B test above.
These are proposed tests, not results from a deployed workflow. They catch a different problem from hallucination: a correct answer given to the wrong person.
Where does your support workflow get the customer’s verified identity today?