Channels like Microsoft Teams and Slack are your agent’s public attack surface and your audit boundary. If you only rely on prompts, you cannot reliably stop a user from steering the agent into unsafe tools, data exposure, or unreviewed actions.

Claw EA treats channels as a permissioned execution plane: OpenClaw is the baseline agent runtime, and every run is tied to a WPC (Work Policy Contract), authenticated with a CST (scoped token), and evidenced with gateway receipts and proof bundles. This gives security teams something operational to approve, verify, and roll back.

Step-by-step runbook

Use this runbook when you are turning a chat surface into an enterprise-controlled agent entry point. Keep the first deployment narrow and expand only after you can verify proofs and roll back quickly.

  1. Define the channel boundary and identity model. For Microsoft Teams, plan around Entra ID app registration and Microsoft Graph permissions/scopes, with Conditional Access and PIM for admin operations. For Slack, plan around workspace-level app install and OAuth scopes per Slack’s official API.

  2. Start with OpenClaw’s local guardrails. Configure channel allowlists and “only respond when mentioned” style behavior where supported, and run the built-in security audit regularly. Treat sandboxing and tool policy as the first blast-radius limiter before you add remote policy.

  3. Write a WPC and publish it. Create a WPC (Work Policy Contract) that specifies which channel contexts are allowed to trigger work and which tools are allowed to execute. Publish the signed, hash-addressed WPC artifact so it can be fetched and verified at runtime.

  4. Issue a CST that is pinned to the policy. Mint a CST (scoped token) from clawscope with a scope hash that matches the permitted actions, and optionally pin the policy hash to the CST. This makes the token unusable for “same token, different policy” drift.

  5. Route model calls through clawproxy. Configure the agent runtime so model traffic is sent through clawproxy, which emits gateway receipts for each model call. If you use OpenRouter via fal, keep it routed through clawproxy so the receipts cover the model call path.

  6. Require proof bundles on completion and store them. For every job triggered from a channel, require a proof bundle that binds together the gateway receipts and run metadata. Store the resulting artifact in Trust Pulse for later review and spot checks.

How to get started checklist: pick one channel, one agent, one tool profile, and one WPC hash. Turn on sandboxing for non-main sessions, require allowlists, route models through clawproxy, and confirm you can retrieve and review the proof bundle for a single test run.

Threat model

Chat control planes fail in repeatable ways: the wrong user triggers the bot, the right user triggers the wrong capability, or the agent cannot prove what it did. The table below maps common channel threats to the control points you can actually operate.

Threat What happens Control
Prompt injection in a shared channel A user message coerces the agent into calling high-impact tools or leaking prior context. OpenClaw tool policy plus sandboxing for tool execution, then enforce a WPC that limits tool profiles and requires proof on completion.
Unauthorized user triggers the agent Any member of a large room can invoke the agent, including external guests. Channel allowlists and mention requirements in OpenClaw; restrict vendor-side access via Entra ID and Conditional Access, or Slack app install scope via official API.
Token reuse or replay across jobs A captured token is reused to run similar work later, outside the intended request context. Marketplace anti-replay binding using job-scoped CST binding, plus optional policy hash pinning on the CST.
Disputed “who said what” in incident response You cannot prove which model calls were made and under which policy. Gateway receipts emitted by clawproxy and bundled into a proof bundle tied to the WPC hash and CST scope hash.
Over-broad vendor permissions The bot app has more rights than the task needs, increasing data access and blast radius. Use least-privilege Graph permissions/scopes for Teams and least-privilege Slack OAuth scopes; gate higher privilege changes through PIM and change control.

Channels are not just a UI; they are a multi-tenant input stream. Treat every message as untrusted input and keep the enforcement in code and policy, not in the prompt.

Policy-as-code example

A prompt can ask the model to “behave,” but it cannot enforce tool availability, token binding, or verifiable evidence. Permissioned execution means the runtime checks a signed WPC and a CST before work starts, and the proxy emits receipts while work is happening.

Example WPC-shaped policy artifact (JSON-like) that you would sign and publish as a WPC:

{
  "wpc_version": "v1",
  "purpose": "Channel-triggered triage agent",
  "channels": {
    "teams": { "allowed_tenants": ["<tenant-guid>"], "allowed_teams": ["<team-id>"] },
    "slack": { "allowed_workspaces": ["<workspace-id>"], "allowed_channels": ["#helpdesk-ai"] }
  },
  "tools": {
    "profile": "triage_readonly",
    "deny": ["exec", "write", "browser_remote_control"]
  },
  "model_calls": {
    "route_via": "clawproxy",
    "require_gateway_receipts": true,
    "provider": "openrouter_via_fal"
  },
  "auth": {
    "require_cst": true,
    "cst_scope_hash": "<hash>",
    "optional_policy_hash_pinning": true
  },
  "audit": {
    "require_proof_bundle": true,
    "store_in_trust_pulse": true
  }
}

If you need network egress allowlists or automatic cost budget enforcement, those are optional and can be implemented, but they should not be your first line of defense. Start with enforceable tool policy, sandboxing, token binding, and receipts.

What proof do you get?

Each model call routed through clawproxy produces gateway receipts. Those receipts are signed, and they are designed to be checked later to confirm that a specific call happened under a specific proxy and policy context.

For a channel-triggered job, Claw EA collects the gateway receipts and the run metadata into a proof bundle. The proof bundle ties together the WPC hash, the CST scope hash, and the relevant execution details so an auditor can verify the run without relying on screenshots or chat logs alone.

When you need a review surface, you can store and view the artifact in Trust Pulse. Use it for spot checks, compliance sampling, and incident response timelines.

Rollback posture

Channel incidents tend to be fast and public. Your rollback plan should prefer “fail closed” switches that do not require redeploying the agent runtime.

Action Safe rollback Evidence
Stop new work from a channel Switch OpenClaw channel policy to allowlist-only or disable the channel entry for the agent. OpenClaw security audit output plus the last proof bundle timestamp before the change.
Block privileged execution paths Update tool policy to remove elevated tools and tighten sandbox mode (for example, sandbox all non-main sessions). Configuration diff plus proof bundles showing reduced tool calls after the change.
Invalidate authorization in-flight Revoke or rotate the CST (scoped token) issuance policy and re-issue a narrower CST pinned to a new WPC hash. CST issuance and revocation records, and subsequent runs showing the new CST scope hash.
Prove what happened during an incident window Freeze the relevant proof bundles and review gateway receipts for model calls that touched sensitive prompts or tool decisions. Gateway receipts and proof bundles stored in Trust Pulse for the affected job IDs.

FAQ

Why can’t we secure an agent with prompts alone?

Prompts are advisory text, not an enforcement layer. Policy-as-code, via a WPC plus CST checks and tool policy, is what prevents the runtime from executing forbidden actions even when the model is manipulated.

What is the minimum we should lock down for Microsoft Teams?

Start with Entra ID app registration hygiene, least-privilege Microsoft Graph permissions/scopes, and Conditional Access for who can administer the app. Then enforce channel allowlists and sandboxed tools in OpenClaw, and require a WPC plus CST for any execution.

How do Slack and Teams differ operationally as agent channels?

The security shape is similar: both are high-volume input streams with mixed-trust participants. The operational difference is the identity and permission model, which you should manage via each vendor’s official API and admin controls, while keeping execution limits in OpenClaw and WPCs.

What do we show auditors after a channel-triggered run?

Provide the WPC hash that governed the run, the CST scope hash used to authorize it, and the proof bundle containing gateway receipts. This is stronger than chat transcripts because it is tied to actual model call traffic and the enforced policy artifact.

Can we add more controls like egress allowlists or spend caps?

Yes, those controls can be implemented as optional or planned layers, depending on your environment. Do not use them as a substitute for tool policy, sandboxing, WPC enforcement, CST binding, and receipts.

Sources