Signal can work as a lightweight human control plane for enterprise AI agents when you treat it as an approvals and notification surface, not as the execution boundary. In Claw EA, the execution boundary is permissioned by policy-as-code using a WPC and a CST, with model calls routed through clawproxy to produce gateway receipts and a proof bundle.
This matters because prompt-only rules are not enforceable under adversarial input. A signed WPC plus scoped runtime authorization is enforceable even when the chat content is malicious or confusing.
Step-by-step runbook
-
Decide what Signal is for. Use Signal for human approvals, incident pings, and status summaries. Keep system-of-record actions and credentials outside the chat surface.
-
Run agents on OpenClaw. OpenClaw is the baseline agent runtime, so you start by configuring a channel extension that can read and post messages. For Signal, this is typically an enterprise buildout using a self-hosted bridge or a dedicated MCP server, since there is no guaranteed official enterprise API.
-
Write a WPC that matches the Signal workflow. Put concrete constraints in the WPC: which tools can run, which model routing is allowed, and what approval phrase is required. Store the WPC in the WPC registry so it is signed and hash-addressed.
-
Issue a CST per job. When an operator asks for work, your orchestrator requests a CST from clawscope that is job-scoped and optionally pinned to the WPC hash. This makes replay harder because the CST is bound to the job context.
-
Route model traffic through clawproxy. Configure the OpenClaw provider so model calls go through clawproxy (for example OpenRouter via fal routed through clawproxy). clawproxy emits gateway receipts for each model call.
-
Return proof to the chat and to audit storage. At the end of the run, produce a proof bundle that includes gateway receipts and metadata, then post a short summary in Signal including the WPC hash and the proof bundle identifier. If you need a viewer artifact for audit stakeholders, store it as a Trust Pulse.
Threat model
Signal is a high-signal operator surface, but it is not an enterprise administrative plane. You should assume screenshots leak, group membership changes without notice, and attackers will attempt prompt injection directly in the chat.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection in chat | A message tries to override instructions and trigger unsafe tools or data access. | Fail closed at execution: OpenClaw tool allow/deny plus sandboxing, and a WPC that restricts tools and model routing. Do not rely on “do not do X” prompts. |
| Unauthorized participant in a group | An untrusted user joins and requests actions that look legitimate. | Policy-as-code gating: WPC restricts allowed sender identifiers, and the job CST is issued only after a verified approval step. Treat group membership as untrusted input, not authorization. |
| Replay of an old approval message | Someone copies “approved” text from a prior run to trigger another run. | Use job-scoped CST binding and require a per-job nonce in the approval phrase. The CST scope hash and optional policy hash pinning make the authorization specific to that job and WPC. |
| Model output disputes after an incident | You cannot prove what the model was asked and what it returned during execution. | Route calls through clawproxy to generate gateway receipts, then package them into a proof bundle. Use the proof bundle for verification and post-incident review. |
| Sandbox escape via tool configuration | A tool runs on the host unintentionally, expanding blast radius. | Prefer sandboxed tool execution in OpenClaw, minimize bind mounts, and avoid elevated execution except for explicitly approved break-glass runs. Run OpenClaw security audit after config changes. |
Policy-as-code example
This is an illustrative WPC-style policy for a Signal approvals channel. The key idea is that the runtime is permissioned by a signed WPC (fetched and verified via clawcontrols) and enforced by scoped authorization (CST) rather than chat text.
{
"policy_name": "signal-approvals-control-plane",
"channel": {
"type": "signal",
"allowed_recipients": ["+15551234567", "+15557654321"],
"allowed_senders": ["+15559876543"],
"approval": {
"required": true,
"format": "APPROVE {job_nonce}",
"deny_format": "DENY {job_nonce}"
}
},
"runtime": {
"baseline": "OpenClaw",
"sandbox_mode": "all",
"tools": {
"allow": ["read", "write", "http", "mcp:*"],
"deny": ["exec", "elevated:*"]
}
},
"model_routing": {
"via": "clawproxy",
"provider": "openrouter_via_fal"
},
"auth": {
"cst": {
"job_scoped": true,
"pin_wpc_hash": true
}
}
}
Operationally, the agent posts the job nonce and the WPC hash into Signal before it starts work. The human reply is only a trigger to mint or release the job CST; it is not treated as the authorization itself.
What proof do you get?
You get gateway receipts for model calls emitted by clawproxy. These receipts can be checked later to confirm which model calls were made under which scoped authorization.
You also get a proof bundle that packages the gateway receipts and related metadata for audit and verification. If you need a durable artifact for reviewers, store the run as a Trust Pulse so audit stakeholders can view what was produced without joining the operator chat.
In the Signal UI, the practical pattern is a short “control card” message: WPC hash, job nonce, requested tools, and a single approve or deny instruction. After completion, post the proof bundle identifier and a concise outcome summary, and keep detailed logs outside Signal.
Rollback posture
Signal-driven operations need a clear rollback plan because the chat channel can go noisy quickly. Treat rollback as a set of concrete operator actions, each tied to evidence you can later verify.
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop new work immediately | Stop issuing new CSTs for the job class, and rotate or revoke active CSTs if needed. | CST issuance and revocation records, plus the absence of new gateway receipts after the cutoff. |
| Freeze a specific workflow | Pin agents to a known-good WPC hash and refuse jobs that reference other policies. | WPC hash shown in Signal control messages and embedded in the run metadata within the proof bundle. |
| Contain tool blast radius | Reduce tool allowlists and ensure OpenClaw sandbox mode is set to restrict host access. | OpenClaw audit output and effective sandbox and tool policy inspection, plus proof bundles showing tool usage boundaries. |
| Dispute a run result | Re-verify the proof bundle and compare gateway receipts to the claimed outcome. | Proof bundle contents and gateway receipts for the model calls involved. |
FAQ
Is Signal a good enterprise control plane?
It is good for small, explicit approvals and incident communication. It is not a replacement for identity governance, admin policy, or enterprise retention, so keep authorization and audit in Claw EA artifacts, not in the chat transcript.
Why not just put the rules in the system prompt?
Prompt rules are advisory and can be bypassed by adversarial input or model error. A WPC plus CST permissioning is enforced by the execution layer, so the agent cannot “talk itself into” extra tools or access.
How do approvals show up in the Signal chat?
Post a structured message that includes the job nonce, the WPC hash, and exactly what is being requested. The operator replies with a single approval phrase that matches the policy, and the job CST is minted or released only after that check passes.
What do I show auditors after a Signal-approved run?
Provide the proof bundle for the run, which includes gateway receipts and metadata suitable for verification. If you need a stable viewing artifact outside the operator chat, store it as a Trust Pulse.
Can I restrict what the agent can do on the machine running OpenClaw?
Yes, using OpenClaw sandboxing and tool policy controls, and by avoiding elevated execution unless you have an explicit break-glass procedure. Re-run the OpenClaw security audit after any config or extension changes.