Support ticket classification and routing is safe to automate when the agent runs under permissioned execution, not prompt-only instructions. In Claw EA, you run an OpenClaw agent with a WPC that constrains what it can read, what it can write, and which routing actions require approval.
This workflow classifies the ticket, proposes a route, and only applies irreversible actions (assign, change priority, notify customers) when the policy allows it and the run is auditable via gateway receipts and a proof bundle.
Step-by-step runbook
-
Define the routing surface area. Decide what the agent is allowed to do without a human: read ticket text, redact, label, and recommend a queue. Treat assign, priority changes, and outbound notifications as high risk and default them to “propose only”.
Integrate your ticket system and chat or email intake via official API or via MCP server, then keep the agent’s tool list minimal.
-
Publish a WPC and pin it for the job. Create a WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols) that encodes the allowed tools, redaction requirements, and whether “apply route” is permitted. Pin the policy hash so the job fails closed if the runtime is presented with a different policy.
This is the key difference from prompt-only controls: the policy is checked by the execution and proxy layers, not “suggested” to the model.
-
Issue a job-scoped CST. Request a CST = scoped token (issued by clawscope) for this single routing job, scoped to the minimum set of actions (for example: read ticket, write labels, create internal note). Use optional policy hash pinning in the CST so the token cannot be reused under a different WPC.
This reduces blast radius if an agent session is prompt-injected or a token leaks.
-
Route model calls through clawproxy. Configure the OpenClaw provider so model traffic goes through clawproxy (for example OpenRouter via fal routed through clawproxy). clawproxy emits Gateway receipts = signed receipts emitted by clawproxy for model calls.
Receipts let you later prove which model was called, when, and under which job and policy constraints, without relying on application logs alone.
-
Enforce redaction and DLP before classification. Run an intake step that strips secrets and sensitive identifiers from the text that will be sent to the model. Keep raw content in your ticket system, but only pass a redacted view into the LLM step.
Make redaction a policy requirement, not a best-effort instruction.
-
Apply rate limits and concurrency limits. Set per-queue throughput limits (for example: max tickets per minute) and a strict concurrency cap (for example: max in-flight tickets per agent). If a spike arrives, the workflow should degrade to “classify only” and stop routing changes.
Cost budget enforcement can be implemented, but do not assume it is present unless you add it as an enterprise buildout.
-
Two-phase commit for irreversible actions. Phase 1: classify and propose route, priority, and notification template in an internal note. Phase 2: a separate tool call applies the changes only if the WPC permits it, the CST scope includes it, and your control plane records the approval decision.
This is how you keep “notify customer” from becoming an accidental or injected action.
Threat model
This workflow is mostly about controlling where untrusted text can steer the system. Ticket bodies frequently contain prompt injection, credential strings, and social engineering attempts that try to trigger routing changes or customer outreach.
The table below lists common failure modes and the concrete control that should stop them.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection inside ticket text | Ticket content instructs the agent to reassign VIP accounts, escalate priority, or message customers. | WPC forbids direct “apply” tools by default; two-phase commit; CST scoped to propose-only for most runs. |
| Data leakage to the model | Secrets, tokens, or personal data are sent to the LLM during classification. | Policy-required redaction step and DLP rules; send only a redacted “model_view” field to the model. |
| Tool overreach | Agent uses broad API permissions to query unrelated tickets, customers, or internal docs. | Minimal tool allowlist in OpenClaw plus WPC tool constraints; CST contains only the job’s read and write scopes. |
| Replay of an old authorization | A previously valid token is reused to apply routing on new tickets. | Marketplace anti-replay binding (job-scoped CST binding) so the token is bound to this job context. |
| Unbounded throughput | A backlog spike or loop causes thousands of tickets to be processed, amplifying mistakes. | Rate limits and concurrency limits; fail closed to “classify only” when thresholds are hit. |
Policy-as-code example
Prompt-only routing rules fail because they are optional to the model. A WPC makes the constraints enforceable by the execution and proxy layers, so “do not notify customers” is not merely advice.
Below is a compact JSON-like sketch of a ticket routing WPC. Treat it as a shape example; your exact fields depend on your internal policy compiler and tool naming.
{
"wpc_version": "1",
"workflow": "ticket_auto_routing",
"tools": {
"allow": ["tickets.read", "tickets.add_label", "tickets.add_internal_note"],
"deny": ["tickets.notify_customer", "tickets.set_priority", "tickets.assign"]
},
"outputs": {
"mode": "propose_only",
"required_fields": ["category", "confidence", "recommended_queue", "rationale"],
"redaction": {
"required": true,
"dlp_rules": [
{"type": "secret", "pattern": "api_key_like"},
{"type": "pii", "pattern": "email"},
{"type": "pii", "pattern": "phone"}
],
"max_chars_sent_to_model": 6000
}
},
"limits": {
"rate_limit_per_minute": 60,
"max_concurrency": 5,
"max_model_calls_per_ticket": 3
},
"high_risk_actions": {
"requires_approval": ["tickets.assign", "tickets.set_priority", "tickets.notify_customer"]
}
}
If you later decide to allow auto-assign for a single queue, do it by changing the WPC and re-pinning the policy hash for that job. Do not “just update the prompt” and hope the agent complies.
What proof do you get?
Every model call routed through clawproxy produces Gateway receipts. Those receipts are assembled into a Proof bundle = harness artifact bundling receipts and related metadata for audit/verification.
Operationally, this gives you evidence that a specific ticket classification was generated under a specific WPC hash and a job-scoped CST. If you store the resulting artifact in Trust Pulse, reviewers get a stable object for audit and viewing without asking engineers to reconstruct logs.
-
Gateway receipts: show the model call inputs and outputs in a verifiable envelope, plus binding metadata (job context, token scope hash, optional policy hash pinning).
-
Proof bundle: packages receipts plus run metadata (tool decisions, timestamps, and identifiers you choose to include) so verification can be automated later.
-
Anti-replay binding: reduces the chance that a valid CST from one run can be used to mutate tickets in a different run.
Rollback posture
Rollback for ticket routing is mostly about preventing further writes, then repairing the small set of wrong writes you already made. Design the workflow so the agent can keep classifying while routing mutations are paused.
Use the table below as a concrete “what to do at 2 AM” checklist.
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop all irreversible writes | Switch to a WPC that denies assign, priority change, and customer notification; issue new CSTs pinned to that policy hash. | New proof bundles show the deny policy hash; old proof bundles identify when the last write was allowed. |
| Quarantine a bad classifier version | Disable the routing “apply” phase, keep “propose only”, and require approval for affected categories. | Gateway receipts show the exact model outputs and confidence that triggered proposals. |
| Undo wrong assignments | Run a repair job that reads a bounded set of affected tickets and restores prior owner and priority via official API, with strict limits. | Repair run produces its own proof bundle; compare ticket diffs to receipts for traceability. |
| Contain data exposure risk | Increase redaction strictness (for example reduce max_chars_sent_to_model), and block categories that tend to include secrets until rules are updated. | Proof bundles show the redaction configuration used per run, and receipts show what was actually sent. |
FAQ
Can I let the agent auto-assign tickets without human approval?
Yes, but do it per queue and per action in the WPC, not as a global behavior. Start with “propose only”, then allow “tickets.assign” only where misroutes are low risk and easy to reverse.
Why is policy-as-code necessary if the prompt already says “do not notify customers”?
Because the prompt is not an enforcement boundary. A WPC plus CST scoping makes “notify customer” impossible unless the execution layer authorizes the tool call.
How do I integrate with ServiceNow, Zendesk, or Jira Service Management?
Use the vendor’s official API or an MCP server, and keep the tool surface minimal. If you need deeper controls like custom field mappings and idempotent repair jobs, that is typically an enterprise buildout.
What should I log for audits without storing full customer text?
Prefer proof bundles with redacted model inputs and include hashes or ticket IDs that let you correlate back to your system of record. Gateway receipts give you verifiable call metadata without requiring you to keep verbose, sensitive transcripts everywhere.
Does sandboxing replace WPC and CST controls?
No. Sandboxing reduces blast radius for tool execution, but it does not define business permissions like “can reassign a ticket”. Use sandboxing and tool policy in OpenClaw, then use WPC and CST for permissioned execution and verifiable runs.