Claw EA turns Discord into a controlled front door for enterprise agents by running OpenClaw as the baseline agent runtime and binding every run to machine-enforced policy. Instead of trusting “the prompt” to behave, you permission the execution layer with a WPC and a CST, so the agent cannot exceed what is explicitly allowed.
For model calls, route traffic through clawproxy to produce Gateway receipts, then collect a proof bundle per job for audit. Discord is a good control plane for human visibility and lightweight approvals, but it is not a system of record, so you should treat it as an operator UI plus chat ingress, not as the authority for identity or data classification.
Step-by-step runbook
-
Stand up an OpenClaw Gateway with the Discord channel enabled, and start with a strict inbound posture. Configure Discord access so only known guilds and channels can trigger the bot, and require an explicit mention for non-thread traffic to reduce accidental triggers.
-
Define what “work” is allowed from Discord, separate from what the model can say. Put the operational constraints in a WPC and publish it as a signed artifact, then treat the policy hash as a deployable input to your agent runtime.
-
Issue a CST (scoped token) from clawscope for the Discord-run job, with a scope hash appropriate to the tools and providers you will allow. If you want fail-closed behavior when policy changes, pin the policy hash in the CST so the job is tied to an exact WPC version.
-
Route model traffic through clawproxy so every model call emits Gateway receipts. If you use OpenRouter via fal, route that through clawproxy as well so the same receipt pipeline applies.
-
Lock down execution in OpenClaw using sandboxing plus tool policy, not prompt instructions. Put risky tools behind an explicit allowlist, and prefer sandbox mode for Discord sessions so a compromised conversation has less filesystem and process access.
-
Run a “dry run” flow in Discord: the agent posts a plan and the exact tool set it intends to use, then an operator explicitly acknowledges before you issue the CST for the real run. This approval gate is typically implemented as an enterprise buildout that mints a job-scoped CST only after the operator signal is recorded.
-
After completion, export a proof bundle for the job and store it where your audit team can find it. If you use Trust Pulse, you can store the artifact for later viewing and verification workflows.
Threat model
Discord is high-risk for prompt injection because it mixes untrusted user text, links, and attachments in the same thread where tools may be available. Treat every Discord message as hostile input, and rely on policy and sandboxing rather than “please ignore the attacker” prompt patterns.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection in a public channel | Attacker messages the bot and tries to coerce tool use (file reads, network calls, posting secrets). | Discord allowlists and mention requirements in OpenClaw, plus WPC-based tool allowlists and sandboxing for Discord sessions. |
| Over-broad tools available in chat | A legitimate request accidentally triggers a destructive tool or touches sensitive files. | Policy-as-code that enumerates allowed tools per channel, plus “deny by default” tool profiles. |
| Token replay across jobs | A captured token is reused to run additional work later. | Marketplace anti-replay binding using job-scoped CST binding, so a CST is valid only for the intended job context. |
| Model-call repudiation | You cannot prove what the model saw or which provider was used when investigating an incident. | Gateway receipts emitted by clawproxy for model calls, bundled into a proof bundle with job metadata. |
| Discord bot token compromise | An attacker can impersonate the bot, read channels the bot can access, or send messages. | Limit bot permissions in Discord, rotate credentials promptly, and keep the agent execution policy strict so bot compromise does not imply tool compromise. |
Policy-as-code example
This is a JSON-like sketch of a WPC that constrains what Discord-triggered work can do. The point is that the control lives outside the prompt: the runtime enforces it, and the CST can pin the WPC hash so the agent cannot silently “upgrade” permissions mid-run.
{
"wpc_version": "v1",
"policy_name": "discord-control-plane-prod",
"channel": {
"type": "discord",
"guild_allowlist": ["123456789012345678"],
"channel_allowlist": ["234567890123456789", "345678901234567890"],
"require_mention": true,
"threads_only_for_work": true
},
"execution": {
"runtime": "openclaw-gateway",
"sandbox_mode": "all",
"workspace_access": "ro"
},
"tools": {
"profile": "deny-by-default",
"allow": [
"http.fetch",
"browser.navigate",
"read",
"write"
],
"deny": [
"exec",
"process",
"tools.elevated"
]
},
"model_calls": {
"route_via": "clawproxy",
"allowed_providers": ["openrouter-via-fal"],
"receipt_required": true
},
"auth": {
"cst": {
"issuer": "clawscope",
"scope_hash_required": true,
"policy_hash_pinning": "optional"
}
}
}
Operationally, you publish the WPC as a signed, hash-addressed artifact served by clawcontrols, then configure the runtime to fetch and verify the WPC before a Discord session can start tool execution. That gives you a stable policy surface you can diff, review, and roll forward safely.
What proof do you get?
For each model call routed through clawproxy, you get Gateway receipts that you can later use to show that calls were mediated by your gateway and associated with a specific job context. These receipts are designed to support verification workflows without relying on “trust me” logs from the agent process.
At the end of a run, Claw EA can emit a proof bundle that packages the relevant receipts and metadata needed for audit. Typical contents include the job identifier, the CST scope hash, any pinned WPC hash, and the set of model-call receipts that occurred during the run.
If you use Trust Pulse, you can store the resulting artifact for later viewing and review. Treat this as evidence attached to a run, not as a replacement for your internal ticketing or incident system.
Rollback posture
Discord is a chat surface, so rollback should focus on stopping new work quickly and making it obvious which permissions changed. You want rollback actions that are fast, scoped, and leave evidence behind.
| Action | Safe rollback | Evidence |
|---|---|---|
| Bad behavior from one Discord thread | Revoke the job CST and close the thread workflow so no new tool runs can start from that thread. | Proof bundle shows the last accepted CST scope hash and the Gateway receipts up to revocation time. |
| Policy mistake (too many tools) | Publish a new WPC version with tightened tool allowlists and pin the new policy hash for subsequent CST issuance. | Old and new WPC hashes are comparable, and new runs show the new pinned policy hash in job metadata. |
| Suspected token leak | Invalidate affected CSTs and re-issue with narrower scope hashes and shorter lifetimes. | Run evidence remains intact via proof bundles; new runs show different CST scope hashes. |
| Discord bot compromise | Rotate Discord credentials, reduce Discord-side permissions, and temporarily disable channel allowlists until the bot identity is re-established. | Discord-side rotation is separate; proof bundles still show what work ran and when via receipts. |
FAQ
Why not just put safety instructions in the prompt?
Prompt-only controls are not a permission boundary because the model can be coerced, confused, or simply make a mistake. A WPC plus CST-based scoping forces the runtime to deny actions even if the model “decides” to attempt them.
What does Discord approve, and what stays in policy?
Use Discord for operator intent and visibility, like “approve this plan” or “confirm these targets,” typically implemented as an enterprise buildout that mints a job CST after approval. Keep tool permissions, sandbox settings, and provider routing in the WPC so approvals cannot silently expand capability.
Can I restrict the bot to only respond when mentioned?
Yes, OpenClaw supports mention-gating behavior for Discord guild messages, and you can keep it strict outside bot-owned threads. This reduces accidental triggers and makes it clearer which messages are actually work requests.
How do receipts and proof bundles help during an incident?
Gateway receipts let you tie specific model calls to a mediated path through clawproxy, which helps answer “what was called, when, and under which job context.” The proof bundle packages those receipts with the job metadata so an auditor can review a run without scraping ad hoc logs.
Is Discord a good place to handle secrets?
No. Treat Discord as untrusted for secrets by default, and keep secrets out of chat history.