ServiceNow is a high-impact system of record for ITSM and operations, so agents must be constrained by permissioned execution, not prompt-only instructions. With Claw EA, you run ServiceNow-facing work in OpenClaw as the baseline agent runtime, and you gate every write or admin action behind a WPC and a CST.
ServiceNow connectivity is not a native connector on Claw EA today. It can be connected via official API with enterprise buildout controls, while still producing gateway receipts and proof bundles for audits and replay checks.
Step-by-step runbook
-
Decide the blast radius in ServiceNow first: which tables, which fields, and which actions are allowed. Separate read-only triage from write paths like incident updates, knowledge publishing, and change workflow transitions.
-
Write a WPC that describes the allowed ServiceNow operations and the required approvals for writes. Store the signed, hash-addressed WPC in the WPC registry (served by clawcontrols) and treat the policy hash as the contract for this workflow.
-
Issue a CST from clawscope for the specific job, with a scope hash and optional policy hash pinning to the WPC. Use job-scoped CST binding to reduce replay risk across runs.
-
Run the agent in OpenClaw with a narrow tool policy and sandboxing enabled where appropriate. OpenClaw already distinguishes sandboxing, tool policy, and elevated execution, so keep elevated off unless you have a specific need.
-
Implement the ServiceNow calls via official API, and keep the agent tool interface explicit (for example: list incidents, fetch record, propose patch, apply patch). For write actions, require a WPC approval gate and log the target record identifiers you touched.
-
Route all model traffic through clawproxy so you get gateway receipts for model calls. Attach receipts, the WPC hash, and the CST scope hash into a proof bundle at the end of the run.
-
Store the proof bundle (and optionally a Trust Pulse) for later review. If an incident happens, you can answer: which policy allowed the action, which token authorized it, and which model outputs led to the request.
Threat model
ServiceNow agent work fails in predictable ways: the tool can be too powerful, the agent can be tricked into acting on untrusted input, or an operator can ship a configuration that silently expands privileges. The goal is fail-closed behavior enforced by policy and tokens, with artifacts you can verify after the fact.
| Threat | What happens | Control |
|---|---|---|
| Prompt-only “do not modify tickets” is ignored | The model updates incidents or closes tasks because the tool allows it and the prompt was overruled by context or injection. | Permissioned execution: write endpoints are blocked unless the run presents a WPC that explicitly permits the method, table, and fields, plus a CST pinned to that WPC hash. |
| Mis-scoped ServiceNow credential | An OAuth client or service account can write to more tables than intended, including users, roles, or CMDB. | Least-privilege auth scopes on the ServiceNow side, and a WPC that denies unlisted tables and methods. Even with a powerful credential, the agent tool should refuse non-WPC actions. |
| Malicious or compromised agent tool/plugin | The tool exfiltrates data, fabricates actions, or performs writes outside the intended workflow. | OpenClaw tool allow/deny policy plus sandboxing to limit local blast radius. For remote calls, constrain behavior with a WPC and require WPC approval gates for writes. |
| Replay of an earlier authorized write | A previously valid token is reused to apply a change again, possibly in a different context. | Marketplace anti-replay binding using job-scoped CST binding, and strict TTLs. Verify the CST binding and policy hash pinning as part of the run’s proof bundle review. |
| Unverifiable model behavior in audits | You cannot show what the model saw or what it produced when it decided to act, so approvals become paperwork only. | Route model calls through clawproxy to obtain gateway receipts, then package them into a proof bundle with run metadata. Store a Trust Pulse when you need a stable review artifact. |
Policy-as-code example
This is a JSON-like sketch of a WPC for a ServiceNow triage agent that can read broadly, but can only write to a narrow set of fields and must stage changes as proposals. In an enterprise buildout, your ServiceNow tool enforces this WPC before making any official API call.
{
"wpc_version": "1",
"policy_name": "servicenow-itsm-triage-v1",
"tool": "servicenow",
"connection_mode": "official_api",
"default": { "allow": false },
"allow_read": [
{ "table": "incident", "fields": ["number","short_description","description","state","priority","assignment_group","assigned_to","comments","work_notes"] },
{ "table": "sys_user", "fields": ["name","email"] }
],
"allow_write": [
{
"table": "incident",
"fields": ["assignment_group","assigned_to","comments","work_notes","priority"],
"methods": ["PATCH"],
"approval_gate": "required",
"change_window": "business_hours_only"
}
],
"deny": [
{ "table": "sys_user_role", "methods": ["POST","PATCH","DELETE"] },
{ "table": "cmdb_ci", "methods": ["POST","PATCH","DELETE"] }
],
"runtime_requirements": {
"cst": {
"policy_hash_pinning": true,
"job_scoped_binding": true,
"max_ttl_minutes": 30
},
"logging": {
"record_identifiers": ["sys_id","number"],
"redact_fields": ["description"]
}
}
}
What proof do you get?
Every model call routed through clawproxy produces gateway receipts that can be verified later. Those receipts let you prove which model was called, when, and under what job context, without relying on an app log that can be edited.
At the end of a run, Claw EA packages receipts and run metadata into a proof bundle. In practice, you use the proof bundle to bind the run to a specific WPC hash (from clawcontrols) and a specific CST scope hash (from clawscope), plus the job-scoped CST binding used to reduce replay risk.
If you publish a Trust Pulse, it is a marketplace-stored artifact for audit/viewing. Use it when you need a stable pointer for reviewers to inspect the run’s proof material and outcomes.
Rollback posture
ServiceNow changes are often logically reversible, but not always safely reversible automatically. The safer pattern is to keep the agent in read-only or “propose-only” mode by default, then require an explicit, WPC-approved write step for any state transition.
| Action | Safe rollback | Evidence to keep |
|---|---|---|
| Patch incident comments or work notes | Add a corrective note and tag it as agent-authored, rather than deleting content. Avoid automated deletion policies. | Proof bundle plus the incident identifiers (number, sys_id) recorded by the tool wrapper. |
| Change assignment group or assignee | Revert to the prior values captured before the patch. Prefer two-phase writes: read current, propose delta, then apply. | Proof bundle plus the pre-change snapshot fields captured during the read step. |
| Change incident priority or state | Rollback requires operational review because downstream workflows may trigger. Gate these writes behind explicit WPC approval and, if needed, human confirmation. | Gateway receipts for the decision step, plus the WPC that permitted state transitions. |
| Create new records (incidents, tasks) | Prefer to mark as duplicate or cancel via normal process rather than delete, depending on your ServiceNow governance. If deletion is allowed in your org, keep it out of the agent path. | Proof bundle plus created record identifiers and the approval record for the write step. |
FAQ
Is this a native ServiceNow connector in Claw EA today?
No. ServiceNow can be connected via official API with enterprise buildout controls, and you can still use WPC gating, CST pinning, gateway receipts, and proof bundles for the run.
Why is prompt-only control not enough for ServiceNow?
Because prompts are not an execution boundary. If the tool can call a write API, the agent can be induced to use it, so the boundary must be policy-as-code enforced before the request is sent.
What is the minimum safe starting posture for a ServiceNow agent?
Start with read-only workflows: search, summarize, classify, and propose patches. Add writes only after you have a WPC that limits tables and fields, and a CST pinned to that policy hash.
How do approvals work for write actions?
Use WPC approval gates so the agent cannot execute write or admin actions unless the policy explicitly permits them for that job. In an enterprise buildout, you typically implement approvals as a separate step that issues a new CST for the write phase.
What do auditors actually verify after an incident?
They verify that the run used a specific WPC hash, that the CST was scoped and optionally pinned to that policy, and that the model calls have gateway receipts. Then they review the proof bundle to connect the decision outputs to the resulting ServiceNow API requests.