Customer Support
AI Agent DELETE on Zendesk Tickets Blocked Before It Landed
A support agent interpreted 'clean up old tickets' as a DELETE. RequestRocket blocked the call before Zendesk saw it — and the security team's inbox notification already named the proxy and the agent, with no log trawling required.
The Challenge
Support Agents With Delete Capability Are a Liability Waiting to Happen
A customer support team deployed an AI agent to manage their Zendesk queue — reading, triaging, routing, and closing tickets. The agent's tool definition wrapped the full Zendesk Tickets API, including DELETE on /api/v2/deleted_tickets/{ticket_id}. When a team member asked the agent to 'clean up my old tickets,' the model selected this as the shortest path to task completion. Zendesk's close and solved states are PUT operations; a DELETE on the deleted_tickets endpoint permanently destroys the ticket after a soft-delete. No more audit trail for deleted tickets.
Over-Scoped Tool Definition
The agent's Zendesk tool was built from a generic API wrapper that included GET, POST, PUT, PATCH, and DELETE. Nobody reviewed whether the agent's actual task scope — reading and closing tickets — required delete capability at all.
"Close" Is Not "Delete" — But the Model May Not Know That
Zendesk uses a PUT to set ticket status to "closed" or "solved". A DELETE soft-deletes a ticket, but calls to DELETE on the deleted_tickets endpoint can permanently destroy up to 100 tickets in bulk. When asked to clean up old tickets, a language model may select DELETE as the literal completion of the task — especially for tickets it interprets as already deleted / stale.
No Named Agent Identity on the Upstream Credential
The Zendesk API key was shared across multiple integrations. If a deletion had gone through, the platform's audit log would show the shared key — not which agent or which tool call made the request.
No Push Notification Path From Zendesk
The security team had no way to be notified in real time when a destructive operation was attempted, let alone which system was responsible.
The Solution
Scope the Tool, Name the Rule, Alert on Breach
The team placed RequestRocket in front of their Zendesk subdomain. The Zendesk API key was vaulted as a target credential — no integration holds the upstream key directly. The support triage agent received its own scoped RequestRocket credential. A default-deny proxy policy allowed only GET, POST, PUT, and PATCH on ticket paths; a dedicated deny rule for DELETE was added with an alert policy and a human-readable note naming the proxy and the agent. When the rule fired, the in-app digest and email carried that note — security knew exactly which API and which agent were involved without opening a log.
"We wrote the rule for that agent specifically. When it fired, the notification already told us which which agent the rule was written for — so it was easy to investigate."
How it works
- 1
Create a RequestRocket target pointing at https://{subdomain}.zendesk.com and store the Zendesk API key as an encrypted target credential. No integration holds the upstream key directly.
- 2
Issue a dedicated RequestRocket credential for the support triage agent. This credential is scoped only to the Zendesk tickets proxy — no other proxy is accessible with this key.
- 3
Set proxyDefaultRuleEffect to 'deny' on the Zendesk proxy. Add allow rules covering only the HTTP methods the agent legitimately needs: GET (read tickets), POST (create tickets), PUT and PATCH (update, close, and solve tickets).
- 4
Add a deny rule for method DELETE with alerts.enabled set to true, cadence 'minute', and alertNote set to 'Deny DELETE on Zendesk tickets — support-triage agent'. When this rule triggers, the in-app inbox and email digest carry the note verbatim — security immediately knows which proxy was hit and which agent the rule was written for.
- 5
Point the agent's Zendesk tool definition at the RequestRocket proxy URL, passing the scoped RequestRocket credential in the Authorization header. The agent calls the proxy exactly as it would call Zendesk — no change to its reasoning or tool schema.
The Results
Measurable Impact
Zero Zendesk tickets permanently deleted
The DELETE was blocked at the proxy before it reached Zendesk. Ticket history, audit records, and customer data remained intact. The upstream API never saw the request.
Security alerted with proxy and agent context
The deny rule's alertNote named the Zendesk proxy and the agent it was written for. The in-app inbox and email digest delivered that context immediately — no log trawling, no Zendesk audit trail inspection required.
Ticket close and update operations unaffected
PUT and PATCH on Zendesk ticket paths were explicitly allowed. The agent continued resolving, closing, and updating tickets normally. Only the destructive method was blocked.
Full request log for every agent call
Every proxied call is captured with the agent credential identity, endpoint path, HTTP method, status, and timestamp — an independent audit record that does not rely on Zendesk's own logging infrastructure.
FAQ
Frequently Asked Questions
Add outbound API security
without changing code
Start on your own or talk to our team about improving the security of every API call you make.