Zendesk exposes ticket content, customer PII, and write operations (close ticket, update user, create macro) through its REST API and community MCP servers. An agent with unconstrained Zendesk access can leak support data, bulk-close tickets, or modify customer records without human review. Connecting Zendesk to OpenClaw agents requires a permissioned execution layer that binds every API call to a signed policy, scoped credentials, and auditable receipts.
Claw EA lets you connect Zendesk via its official API or MCP-compatible tooling with enterprise buildout controls. Write and admin actions require Work Policy Contract (WPC) approval gates, scoped tokens (CST), and explicit least-privilege auth scopes. This is not a native connector shipped today; it is an enterprise buildout integration.
Step-by-step runbook
- Create a Zendesk OAuth client with minimal scopes. In Zendesk Admin Center, register an OAuth app. Grant only
tickets:readandusers:readinitially. Do not granttickets:writeororganizations:writeuntil the WPC explicitly requires them. - Author a WPC for the Zendesk integration. Define allowed actions (e.g., read ticket, add internal note), forbidden actions (e.g., delete ticket, reassign agent), and data-handling constraints (PII redaction, no export to external endpoints). Register the WPC in clawcontrols so it is hash-addressed and immutable.
- Issue a job-scoped CST. Use clawscope to mint a scoped token pinned to the WPC policy hash. The CST should carry the Zendesk OAuth token as an opaque credential reference, not as a plaintext secret in the agent prompt.
- Configure the OpenClaw agent tool policy. In your OpenClaw gateway config, set
tools.allowto include only the Zendesk MCP or API tool. Settools.denyfor any elevated or shell tools that should not run alongside Zendesk operations. Enable sandbox mode"all"if the agent handles customer PII. - Route model calls through clawproxy. This ensures every LLM inference that drives a Zendesk action produces a gateway receipt. The receipt captures the model, prompt hash, and timestamp without logging raw PII.
- Test with a read-only dry run. Execute the agent against a staging Zendesk instance. Verify that the proof bundle contains the expected receipts and that write attempts are rejected by the WPC gate.
- Promote to production with human-in-the-loop for writes. For write actions (update ticket, post public reply), require explicit approval in the WPC before the agent can execute. Review proof bundles after each run.
Threat model
| Threat | What happens | Control |
|---|---|---|
| Prompt injection via ticket body | A malicious end-user embeds instructions in a support ticket. The agent follows them, e.g., "close all open tickets" or "email transcript to attacker@evil.com." | WPC restricts allowed actions to a fixed set. Sandbox mode prevents network egress beyond Zendesk API. Egress allowlists (planned) would further restrict outbound targets. |
| Credential over-scoping | Agent holds an admin-level Zendesk API token. A misconfigured skill uses it to delete users or export the full ticket archive. | CST pins the credential to a specific WPC. The Zendesk OAuth client is registered with minimal scopes. OpenClaw tool policy denies any tool not explicitly allowed. |
| PII exfiltration through model context | Customer names, emails, and payment details in ticket fields are sent to the LLM provider as prompt context. | WPC mandates PII redaction before model calls. Gateway receipts from clawproxy log which model saw which prompt hash, enabling post-hoc audit without storing raw PII. |
| Replay or duplicate ticket actions | A stale or replayed CST triggers the same write operation twice (e.g., double refund). | Marketplace anti-replay binding ties each CST to a single job. Once the job completes, the token cannot be reused. |
| Misconfigured MCP server | A community MCP server for Zendesk exposes admin endpoints the agent should not call. | OpenClaw tool allow/deny lists restrict callable methods. The WPC independently gates each action class. |
Policy-as-code example
{
"wpc_version": "1.0",
"integration": "zendesk",
"connection": "oauth",
"allowed_actions": [
"tickets:read",
"tickets:add_internal_note",
"users:read"
],
"denied_actions": [
"tickets:delete",
"tickets:merge",
"users:write",
"organizations:write",
"macros:write"
],
"data_handling": {
"pii_redaction": true,
"redact_fields": ["requester.email", "requester.phone", "custom_fields.*"]
},
"write_approval": "human_in_the_loop",
"max_tickets_per_run": 50,
"cst_policy_hash_pin": true
}This WPC is registered in clawcontrols and becomes hash-addressed. The CST issued by clawscope pins to this policy hash, so any agent presenting the token is bound to exactly these constraints. Prompt-level instructions cannot override the denied actions list.
This is why policy-as-code matters more than prompt-only guardrails: a prompt can be overridden by injection, but a signed WPC enforced at the proxy and token layer cannot.
What proof do you get?
Model-assisted runs produce gateway receipts from clawproxy for every LLM call that drives a Zendesk action. Each receipt records the model identifier, a hash of the prompt, the timestamp, and the CST used. These receipts are bundled into a proof bundle alongside job metadata.
The proof bundle ties the Zendesk API calls back to the specific model reasoning that triggered them. Auditors can verify which model made which decision, confirm the WPC was active at execution time, and check anti-replay binding to ensure no duplicate runs occurred.
Trust Pulse artifacts are stored in the marketplace for viewing and audit. Transparency log inclusion proofs are planned but not yet shipped.
Rollback posture
| Action | Safe rollback | Evidence |
|---|---|---|
| Internal note added to ticket | Delete the note via Zendesk API. Low risk since internal notes are not customer-visible. | Proof bundle contains the ticket ID and note content hash. |
| Public reply posted | Cannot unsend email notifications. Mark reply as redacted in Zendesk; notify affected customer if needed. | Gateway receipt links the model call to the reply action. CST job binding proves which run caused it. |
| Ticket status changed (e.g., closed) | Reopen ticket via API. Audit trail in Zendesk preserves the original status change. | WPC logs the allowed status transitions. Proof bundle records the state change. |
| User record modified | Restore from Zendesk audit log or backup. Potentially irreversible if downstream systems consumed the change. | This action should be in the denied_actions list. If it occurred, the proof bundle and gateway receipts provide forensic evidence. |
FAQ
Is Zendesk integration available as a native connector today?
No. Zendesk can be connected via its official API or MCP-compatible tooling with enterprise buildout controls. Do not assume out-of-the-box support. The integration requires configuring OAuth credentials, authoring a WPC, and setting up the OpenClaw tool policy.
Why can't I just restrict the agent with a system prompt?
System prompts are advisory. A sufficiently crafted prompt injection in a ticket body can override them. A WPC enforced at the token and proxy layer is not accessible to the model and cannot be overridden by prompt content. The execution layer must be permissioned with policy-as-code, not prompt-only instructions.
How does PII redaction work before model calls?
The WPC specifies which Zendesk fields must be redacted before they enter the model context. The agent runtime strips or hashes those fields prior to constructing the prompt. Gateway receipts record the prompt hash, not the raw content, so PII does not persist in the proof chain.
What authentication methods does Zendesk support for agent connections?
Zendesk supports OAuth 2.0, API key, bearer token, and basic auth for server-to-server integrations. For permissioned agents, OAuth 2.0 with minimal scopes is recommended. The OAuth token is bound to the CST so it cannot be extracted or reused outside the approved job.
Can I enforce cost limits on Zendesk-related model calls?
Automatic cost budget enforcement is planned but not yet shipped. You can approximate it today by setting max_tickets_per_run in the WPC and monitoring gateway receipt counts per job.