Microsoft Teams can be a practical control plane for enterprise AI agents because it already has identity, chat-based approvals, and administrative controls that security teams understand. Claw EA runs the agent itself in OpenClaw as the baseline agent runtime, then enforces permissioned execution with policy-as-code instead of relying on prompt instructions.
In this setup, Teams is the operator surface, while Claw Bureau primitives (WPC, CST, gateway receipts, proof bundles) provide machine-checkable authorization and audit artifacts for every run.
Step-by-step runbook
-
Install and configure the OpenClaw Microsoft Teams plugin, then stand up a Teams bot (App ID, secret, tenant) and expose the bot webhook. Keep group and channel behavior locked down first (allowlist and mention gating where applicable), then expand access intentionally.
-
Decide how the agent will call Microsoft systems. Use Microsoft Graph via official API where needed, and scope permissions to the minimum set for the workflow, with admin consent controlled through your normal Entra ID process.
-
Create a WPC in clawcontrols that describes what the agent is allowed to do in Teams-triggered runs: which tools are callable, what data can be read or written, and which operations require human approval. Treat this as the source of truth, not the prompt.
-
Issue a CST from clawscope for the job or session, and pin it to the WPC hash when you want strict coupling between the run and the policy. Use job-scoped CST binding to reduce replay risk when an approval is involved.
-
Route model calls through clawproxy so every model request emits gateway receipts. If you use OpenRouter via fal, route it through clawproxy to keep receipts consistent across model providers.
-
Implement chat approvals as a first-class step in the run: the agent posts an approval request to Teams that includes the WPC hash and a summary of the intended action. When the approver responds, the agent continues with a fresh, job-scoped CST so “approve” messages cannot be replayed against a different action.
-
At completion, export the proof bundle for audit and optionally publish it to Trust Pulse for viewing. Keep the proof bundle tied to the Teams message context (conversation and message ids) so an auditor can trace what the agent claimed back to what happened.
Threat model
Teams makes it easy to operationalize approvals, but it also makes it easy to accidentally grant broad reach. The goal is to assume that prompts and chat messages can be malicious, and enforce safety in the execution layer with WPC and CST, then verify what happened with gateway receipts and proof bundles.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection via Teams message or forwarded content | The agent is socially engineered to call tools or exfiltrate content, even if the system prompt says “do not”. | Use a WPC to restrict tool access and data movement; rely on sandbox and tool policy in OpenClaw, not instructions. Require approvals for high-risk operations and bind approvals to job-scoped CST. |
| Over-permissioned Microsoft Graph access | A single compromised run can read mail, files, or directory data well outside the intended workflow. | Minimize Graph permissions/scopes and separate identities for bots vs back-end services; use Entra ID controls like Conditional Access and PIM for administrative changes. |
| Token replay and “approve” message reuse | An attacker reuses an old approval or captured token to authorize a new action. | Use marketplace anti-replay binding (job-scoped CST binding) and keep CST TTLs short. Pin CST to the WPC hash so a token cannot be reused under a different policy. |
| Undetectable model behavior changes | Different model parameters or providers produce different outcomes, and you cannot explain which calls were made. | Route model calls through clawproxy to emit gateway receipts, then package them into a proof bundle for verification. Keep run metadata (job id, policy hash, scope hash) in the bundle. |
| Local execution blast radius | If tools run on a host with secrets or broad filesystem access, a bad tool call becomes a host incident. | Use OpenClaw sandboxing for tool execution where possible and keep elevated execution rare and explicit. Run OpenClaw security audit regularly to catch common footguns. |
Policy-as-code example
Prompt-only constraints fail because they are not enforceable at the moment a tool is invoked or a model call is made. A WPC makes the rules explicit and hash-addressed, so the agent run can prove which policy was in force and the platform can fail closed when the policy does not allow an action.
Example WPC shape for a Teams-triggered run (JSON-like, illustrative):
{
"wpc_version": "1",
"policy_name": "teams-ops-assistant",
"channel": "msteams",
"inputs": {
"allowed_tenants": ["<YOUR_TENANT_ID>"],
"allowed_conversations": ["allowlist:team:ops", "allowlist:chat:oncall"]
},
"tool_policy": {
"allow": [
"read",
"write",
"http.fetch:graph.microsoft.com",
"msteams.reply",
"msteams.adaptive_card"
],
"deny": [
"exec",
"tools.elevated",
"http.fetch:*"
]
},
"approvals": [
{
"action": "graph.write",
"require_human": true,
"approval_surface": "msteams",
"approval_binding": ["job_id", "wpc_hash", "cst_scope_hash"]
}
],
"model_routing": {
"provider": "openrouter_via_fal",
"must_go_through": "clawproxy",
"receipts_required": true
}
}
In practice, the WPC is signed and served by clawcontrols, and the run uses a CST from clawscope that can be pinned to the WPC hash. If the agent attempts a tool call outside policy, execution should fail closed and report the denied action back into the Teams thread.
What proof do you get?
For each model call routed through clawproxy, you get gateway receipts that are signed and can be verified later. Receipts let you answer basic incident questions: which model endpoint was called, when it was called, and which run and policy it was associated with.
At the end of a run, Claw EA packages receipts and related metadata into a proof bundle. The proof bundle is what you hand to audit or incident response, and it can be stored and viewed as a Trust Pulse artifact when you need a durable viewing surface.
For approvals in Teams, include the WPC hash, the CST scope hash, and a job id in the approval card text so the approval is anchored to a specific run. That gives reviewers a way to confirm they approved the same action that later appears in the proof bundle.
Rollback posture
Rollback has to be operational and fast because chat channels are high-volume and attackers move quickly. The safest rollback posture is to cut authorization first (CST and WPC), then isolate execution (OpenClaw tool policy and sandbox), and only then expand again after review.
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop new high-risk actions immediately | Update the WPC to deny the sensitive tool paths, then require the new WPC hash for new CST issuance. | New runs show the updated WPC hash; denied actions appear as policy failures rather than silent behavior changes. |
| Contain a suspected token leak | Revoke the CST (and rotate issuer keys per your process), then re-issue short TTL CST with tighter scopes. | Token introspection and revocation events, plus job-scoped CST binding preventing reuse across jobs. |
| Contain a Teams bot credential exposure | Rotate the bot secret in Entra ID, restrict app access, and temporarily disable the Teams channel in the OpenClaw config. | Teams bot sign-in and config change records in Microsoft, plus a clear break in inbound message processing. |
| Contain tool execution risk | Force OpenClaw sandbox mode to “all” for the agent and remove elevated tool escape hatches until reviewed. | OpenClaw sandbox explain output and security audit results showing effective sandbox and tool policy state. |
FAQ
Why not just put safety rules in the system prompt?
Because prompt rules do not stop tool calls when the model is manipulated by a message, attachment, or multi-turn context. Policy-as-code in a WPC is evaluated at execution time, so the platform can deny a specific tool call even if the model tries to proceed.
How do Teams approvals map to actual authorization?
The Teams approval message is an operator signal, not a permission boundary by itself. The permission boundary is the CST plus WPC pinning, with job-scoped CST binding so an approval applies only to the intended job and policy.
What Microsoft controls should we use alongside this?
Use Entra ID to manage the bot and any service principals, keep Microsoft Graph permissions minimal, and gate admin changes with Conditional Access and PIM. Claw EA does not replace these controls; it uses them as the identity and change-management layer around the channel.
Can we prove what model calls happened for an incident review?
Yes, when model traffic is routed through clawproxy you get gateway receipts for those calls. Receipts and run metadata are collected into a proof bundle, which you can hand to audit or store as a Trust Pulse artifact for viewing.
Is Microsoft Teams a good place to run high-risk workflows?
Teams is a good operator surface, but it is still an untrusted input channel. Treat every message as hostile, keep tool access tight in the WPC, and require approvals plus job-scoped CST binding for workflows that write data or trigger external actions.