Intercom is a high-impact surface for agents because a single misfire can message customers, change ticket state, or leak conversation history. For enterprise use, treat Intercom actions as permissioned execution: policy-as-code enforced by a WPC, authenticated with a CST, and evidenced by gateway receipts and a proof bundle.
Claw EA runs agents on OpenClaw as the baseline runtime, then adds machine-checkable authorization and audit artifacts around every model-assisted run. This keeps “what the agent is allowed to do” out of prompts and inside signed policy, scoped credentials, and verifiable receipts.
Step-by-step runbook
-
Define the Intercom blast radius you will permit: read-only triage, draft-only replies, or limited write actions such as tagging and assignment. Write it down as a WPC = Work Policy Contract (signed, hash-addressed policy artifact; served by clawcontrols), including explicit tool/action lists and data handling rules.
-
Stand up authentication for Intercom via official API with an enterprise buildout that supports least-privilege scopes and separation between environments. Keep “admin” capabilities out of the agent path; route them through an approval gate described by the WPC.
-
Issue a CST = scoped token (issued by clawscope) for each job or queue drain, and bind it to the WPC hash (policy hash pinning) so the token cannot be replayed under a looser policy. Use job-scoped CST binding to reduce replay risk across runs.
-
Run the agent in OpenClaw with a minimal tool profile and sandboxing aligned to your environment. OpenClaw tool policy and sandboxing reduce local blast radius, but your Intercom authorization should still be enforced at the execution layer, not in chat text.
-
Route model calls through clawproxy so you receive gateway receipts for each model call, then package the run into a proof bundle. Store the bundle and, when needed, publish it as a Trust Pulse for review.
-
Perform rollout in stages: start with “suggest-only” outputs to a human queue, then allow constrained writes such as tagging, assignment, and internal notes. Expand to customer-visible messages only after you have stable proof bundles and a reliable rollback plan.
Threat model
Intercom failures are rarely subtle. The common risk is an agent that was allowed to act, received untrusted content, and then used its tools too broadly.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection from customer message | The agent treats a customer instruction as operator intent and performs actions like changing ticket state or sending sensitive info. | WPC restricts allowed actions and fields; CST is minted only for the constrained policy; OpenClaw tool allow/deny keeps local tools narrow. |
| Over-privileged Intercom auth | A triage agent can escalate into admin-like writes, bulk edits, exports, or inbox-wide access. | Enterprise buildout enforces least-privilege scopes; write and admin actions require WPC approval gates and explicit scoping in the CST. |
| Misconfigured “write” defaults | The agent sends customer-facing messages when you intended drafts or internal notes only. | WPC defines message modes (draft vs send) as separate actions; require human approval for customer-visible send until proven safe. |
| Replay of a prior run | A captured credential or token is reused to re-run a previously valid action sequence. | Marketplace anti-replay binding using job-scoped CST binding; require a new CST for each run and pin it to the WPC hash. |
| Audit gaps after an incident | You cannot prove which model call produced which action, or whether policy was in effect at the time. | Gateway receipts from clawproxy for model calls, packaged into a proof bundle with run metadata for verification and review. |
Policy-as-code example
This is a JSON-like sketch of how teams typically express Intercom constraints in a WPC. The goal is to make “can read” and “can write” separate capabilities, and make customer-visible actions harder to reach than internal triage.
{
"wpc_version": "v1",
"tool": "intercom_via_official_api",
"allowed_actions": [
"conversations.read",
"conversations.search",
"conversations.add_internal_note",
"conversations.assign",
"conversations.tag"
],
"denied_actions": [
"conversations.send_message",
"contacts.export",
"admin.*"
],
"data_handling": {
"log_redaction": "on",
"store_customer_content": "no",
"allowed_fields": ["conversation_id", "subject", "body_redacted", "tags", "assignee_id"]
},
"approvals": [
{ "action": "conversations.send_message", "mode": "manual_gate" }
],
"auth": {
"cst_required": true,
"cst_policy_hash_pinning": true
}
}
In practice, this WPC is signed and hash-addressed, then fetched and verified by the execution path before Intercom writes are attempted. Prompts can describe intent, but they do not grant capability.
What proof do you get?
For each model call routed through clawproxy, you get gateway receipts that can be checked later to confirm which model was called, when, and under which run context. Those receipts are not a substitute for application logs, but they let you tie agent outputs to specific model interactions.
Claw EA bundles receipts and run metadata into a proof bundle suitable for audit and verification. When you need to share evidence with internal reviewers or external auditors, you can store and view the artifact as a Trust Pulse.
Operationally, this is what makes “permissioned agents” enforceable. You can show the WPC hash that governed the run, the CST that was scoped to it, and the receipts that demonstrate the model traffic that led to actions.
Rollback posture
Rollback for Intercom agents should assume you may need to stop writes immediately, then recover state with a bounded set of compensating actions. The safest approach is to design your WPC so rollback is mostly “disable capability” plus “human clean-up,” not “agent fixes agent.”
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop all Intercom writes | Mint new CSTs that are read-only and pinned to a stricter WPC; revoke or expire existing CSTs per your operations practice. | WPC hash change, CST scope hash, and proof bundles showing when the policy changed. |
| Rollback incorrect tagging or assignment | Use a human-run batch process via official API to revert specific fields, based on a list of affected conversation IDs. | Proof bundle run metadata to enumerate impacted items; Intercom-side audit and change history as applicable. |
| Rollback an incorrect customer message | Do not attempt automated deletion unless your governance allows it; send a corrected follow-up message with human approval. | Gateway receipts for the model call that drafted content, plus a record of the approved corrective action. |
| Suspected prompt injection campaign | Quarantine the queue: read-only triage, stricter content handling, and temporary manual review for any customer-visible action. | Proof bundles for the impacted runs and the pinned WPC version that was active during the event window. |
FAQ
Why is prompt-only safety not enough for Intercom agents?
Prompts can be overwritten by untrusted customer text, tool outputs, or a malicious plugin. A WPC makes the allowed actions machine-enforced, and a CST ensures the agent cannot exceed that policy even if the prompt tries.
Is Intercom a native Claw EA connector today?
No. Intercom can be connected via official API with enterprise buildout controls, and the run can still produce gateway receipts and proof bundles for audit and replay checks.
What Intercom actions should be allowed first?
Start with read-only triage plus non-customer-visible writes like internal notes, tagging, and assignment. Make customer-visible sends an approval-gated action in the WPC until you have stable operating evidence.
Can we use MCP with Intercom?
Intercom publishes MCP documentation, but you should treat MCP as an integration transport, not an authorization system. If you adopt it, do so via an MCP server and still enforce WPC and CST rules at the execution layer.
How do we prove what the model saw and did during an incident?
Gateway receipts from clawproxy provide verifiable records of model calls, and the proof bundle ties those receipts to the job context and policy hash. This gives you a concrete chain to review alongside Intercom-side logs and your own operational telemetry.