AI support agent for Zendesk on AWS Bedrock: how it is wired.

What the agent may and may not do in Zendesk

The agent's Zendesk permissions are a job description, not admin rights. It may read a ticket and its requester, post a public reply, add an internal note, set tags and status, and assign the ticket to a group. It may not issue a refund, change a customer's plan or account, merge or delete tickets, or reply on a ticket outside the trigger's conditions. Those are not disabled by a prompt; they are absent from the allowed-action list the orchestration service enforces, so a wrong answer can be wrong but never irreversible. Adding an action later is a deliberate change, reviewed like code.

What the human agent sees on escalation

An escalated ticket arrives in the escalation group with an internal note in a fixed shape: the intent the agent assigned, the sources it retrieved and how confident it was in each, the reply it drafted but did not send, and the reason it stopped, such as low confidence, an out-of-scope request, or a customer asking for a person. The human starts from a summary, not from scratch. Tags record the outcome, so the resolution and escalation rates are ordinary Zendesk reports.

What leaves your Zendesk, and what does not

Ticket text and the relevant customer fields are sent to the model endpoint in your own AWS account through Bedrock, with PII redaction applied first where you require it. Nothing is sent to Aldenebai, and nothing is used to train provider models. The reply, the internal note, and the tags are written back through the Zendesk API under the agent's identity. The audit trail of every read, decision, and action lives in your logs, with the ticket ID, for as long as your retention policy says.

Two things stay entirely inside Zendesk: the trigger conditions that decide which tickets the agent ever sees, and the kill switch, which is simply disabling that trigger. Both are controls your admins already know how to use, which is the point.