Slack is a practical control plane for enterprise AI agents because it already has identity, channels, message history, and a place for approvals to happen in the open. Claw EA uses OpenClaw as the baseline agent runtime, then adds permissioned execution so “what the agent can do” is enforced by policy-as-code, not by prompts.
Prompt-only guardrails fail when a message includes a malicious instruction or when a tool call is available by accident. With Claw EA, the agent’s work is tied to a WPC, authenticated with a CST, and model calls produce gateway receipts that can be packaged into a proof bundle for audit.
Step-by-step runbook
-
Define the Slack surface area for the agent. Decide which channels are “request intake” (read and triage) versus “execution” (where the agent can run tools and post outcomes).
-
Write a WPC that describes allowed tools, approval requirements, and the minimum proof you need for the job type. Store the WPC in the WPC registry so it can be fetched and verified during runs.
-
Issue a CST for the Slack agent job, with a scope hash that matches the intended tool surface. If you require strict pinning, use optional policy hash pinning so the CST is only valid with that exact WPC hash.
-
Run the agent in OpenClaw with a Slack channel extension (via official API or via MCP server, depending on your Slack app architecture). Configure OpenClaw tool policy and sandboxing so local execution matches the WPC intent and does not silently widen access.
-
Route model calls through clawproxy so each model call emits gateway receipts. If you use OpenRouter via fal, keep it routed through clawproxy so receipts are consistent across providers.
-
Enforce approvals as a first-class step. In Slack, make approvals explicit: the agent posts a proposed action, a human responds with an approval token or a structured “approve” reply, and only then does the agent proceed to tool execution under the same job-scoped CST.
-
At completion, generate a proof bundle that includes gateway receipts and run metadata. Store or publish it to Trust Pulse so auditors can review what was run and what the model was allowed to do.
Threat model
Slack is a high-risk ingress because anyone who can post in a channel can attempt prompt injection, or can socially engineer approvals. Treat the channel as untrusted input and make execution contingent on WPC enforcement plus verifiable artifacts.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection via Slack message | A message tries to override instructions and coerce the agent into calling tools or exfiltrating data. | Policy-as-code in a WPC defines tool availability and required approvals; OpenClaw tool policy and sandboxing reduce blast radius even when the model “wants” to do more. |
| Overbroad tools accidentally enabled | An agent can access shell, filesystem, or network tools because of a loose configuration. | WPC constraints plus OpenClaw tool allow/deny lists; run regular OpenClaw security audits to catch common footguns. |
| Approval spoofing inside Slack | An attacker imitates an approver, or replays an old “approved” message to trigger execution. | Gate execution on a job-scoped CST and explicit approval checks; use marketplace anti-replay binding (job-scoped CST binding) so approvals cannot be reused across jobs. |
| Model call disputes | After an incident, you cannot prove which prompts and outputs drove a tool action. | Route model calls through clawproxy to get gateway receipts; package them into a proof bundle for verification and audit. |
| Data leakage via chat context | The agent posts sensitive content back into Slack or uses it in prompts. | Limit what the agent is allowed to read and post; structure the workflow so sensitive outputs are summarized and redacted before posting, and keep raw artifacts outside Slack when possible (enterprise buildout). |
Policy-as-code example
This sketch shows a Slack-oriented WPC shape: one set of channels for intake, a tighter set for execution, and an approval gate before any irreversible action. The point is operational: Slack messages are not “permissions”, they are inputs that must map to a signed policy artifact.
{
"wpc_version": "1",
"policy_name": "slack-agent-control-plane",
"channels": {
"intake": ["#help-agent", "#triage-agent"],
"execution": ["#agent-ops"]
},
"identity": {
"allowed_slack_workspaces": ["T123..."],
"allowed_requester_groups": ["oncall", "it-ops"],
"approver_groups": ["security-approvers"]
},
"tools": {
"allow": ["ticket.create", "ticket.update", "doc.search"],
"deny": ["shell.exec", "fs.write", "browser.control"]
},
"approvals": [
{
"when": "tool == 'ticket.create' || tool == 'ticket.update'",
"require": "human_approval_in_slack",
"approval_window_minutes": 30
}
],
"model_calls": {
"require_gateway_receipts": true,
"provider_route": "via_clawproxy"
}
}
In practice, the WPC is signed and hash-addressed, then served by clawcontrols. At runtime, the CST can be bound to the scope hash and optionally pinned to the WPC hash so the job cannot “switch policies” midstream.
What proof do you get?
Every routed model call produces gateway receipts emitted by clawproxy. These receipts let you later verify that a specific prompt, model, and response occurred as part of an authorized run, instead of relying on best-effort logs.
Claw EA bundles receipts and run metadata into a proof bundle. You can store the proof bundle and, when needed, publish it as a Trust Pulse artifact for review, including the job-scoped binding context so replays and cross-job reuse are easier to detect.
Rollback posture
In Slack-driven operations, rollback is mostly about stopping further actions, constraining scope, and leaving a clean paper trail. The goal is to fail closed: if policy, token scope, or receipts cannot be produced, the agent should refuse to execute.
| Action | Safe rollback | Evidence |
|---|---|---|
| Policy mistake discovered (tool was allowed) | Update to a tighter WPC and rotate to a new policy hash; require optional policy hash pinning for new runs. | WPC hash history plus proof bundles from prior runs showing which policy hash was used. |
| Slack channel compromised or noisy | Move execution to a restricted channel and treat previous channels as intake-only; run OpenClaw security audit to confirm no widened Gateway exposure. | Proof bundles show which channel context and which tools were invoked; audit outputs show local configuration posture. |
| Suspicious run in progress | Revoke the CST so the job cannot continue; require a fresh CST for any retry under a reviewed WPC. | CST issuance and revocation records; partial proof bundle with gateway receipts up to the stop point. |
| Need to invalidate approval replay patterns | Use job-scoped CST binding and enforce “approval must reference current job id” in the Slack workflow (enterprise buildout). | Marketplace anti-replay binding context plus proof bundles tying approvals and actions to a single job. |
FAQ
Why not rely on a prompt that says “ask for approval”?
Because Slack messages are untrusted input and prompts are not enforcement. Policy-as-code in a WPC defines what is allowed, and the runtime can fail closed when the policy is not satisfied.
How do approvals show up in Slack?
Operationally, the agent posts a proposed action with the exact tool and parameters it intends to use, then waits. A human replies with an approval message, and execution proceeds only if the approval matches the job and the current WPC constraints (enterprise buildout for your preferred UX).
What do gateway receipts prove?
They prove that specific model calls were made through clawproxy and were receipted, instead of being ad hoc calls outside your control plane. Receipts are designed to be bundled and verified later as part of a proof bundle.
Can we run Slack agents without letting them touch the host?
Yes, if your tools can run sandboxed and your OpenClaw configuration keeps execution inside Docker. OpenClaw distinguishes sandboxing, tool policy, and elevated host execution, and you should avoid elevated paths unless you explicitly need them.
Does Claw EA provide egress allowlists and budget caps?
Egress allowlists enforced outside clawproxy and automatic cost budget enforcement are planned or can be implemented, but they are not presented here as shipped features. The shipped core is WPC, CST, gateway receipts, proof bundles, and job-scoped anti-replay binding.