Azure Service Bus is a durable queue and pub/sub backbone, so it is a natural place to connect enterprise agents to real workflows. It is also a high impact surface: a single mis-scoped sender or receiver can leak data, trigger downstream execution, or wedge production consumers.

Claw EA runs OpenClaw as the baseline agent runtime and treats Service Bus access as permissioned execution. Instead of relying on prompt instructions, you put a Work Policy Contract (WPC) in front of “send”, “receive”, and “admin” actions, issue a CST = scoped token (issued by clawscope) bound to that policy, and capture proof artifacts (gateway receipts and proof bundles) for audit.

Step-by-step runbook

These steps assume an enterprise buildout that connects to Azure Service Bus via official API. This is not a native connector, so treat the “tool” as a controlled wrapper around the SDK operations you approve.

  1. Decide the minimum Service Bus actions the agent needs. Split “send”, “receive”, and “manage” into separate roles, and separate namespaces and entities (queue/topic/subscription) by environment. Prefer Microsoft Entra ID with Azure RBAC over broad Shared Access Signatures (SAS) when feasible.

  2. Define the WPC for the Service Bus tool. The WPC should name exact entities, allowed operations, message size limits, and whether dead-letter operations are permitted. Keep “admin” actions as a separate WPC that requires explicit approval gates.

  3. Issue a CST for a single job and pin it to the WPC. The CST should be short lived and job scoped, and should carry a scope hash with optional policy hash pinning so the execution layer can fail closed if the policy changes mid-run. Use marketplace anti-replay binding (job-scoped CST binding) to reduce token replay risk across jobs.

  4. Run the agent under OpenClaw tool policy and sandboxing. Use OpenClaw tool allowlists so only the Service Bus tool (and required utilities) are callable, and prefer Docker sandboxing for tool execution. Avoid elevated host execution except for tightly reviewed break-glass tasks.

  5. Route model traffic through clawproxy to get Gateway receipts. The goal is verifiable evidence of what the model was asked and what it returned when it decided to send or consume messages. This does not prove Azure accepted a message, but it does prove the model side of the decision and tool call plan under the pinned WPC.

  6. Emit a proof bundle per run and store it. Bundle the Gateway receipts, the CST scope hash, the WPC hash, and run metadata (job id, agent id, tool version hash) into a proof bundle. Store the bundle and optionally publish a Trust Pulse for audit viewing.

Threat model

Service Bus is a control plane for downstream work. When an agent can send or receive messages, it can indirectly create side effects in other services, even if the agent never gets direct credentials for those services.

Threat What happens Control
Over-broad sender permissions Agent can send to any queue or topic in a namespace, including production entities, triggering unexpected consumers. WPC restricts entity paths and operations; CST pinned to the WPC; Azure RBAC role assignments scoped to the minimum set of entities.
Receiver drains or poisons the queue Agent receives and completes messages it should not touch, or repeatedly abandons to force retries and load. Separate WPC for receive; require explicit “peek-lock vs receive-and-delete” choice; rate limits and message count caps in policy; isolate subscriptions for agent consumption.
Dead-letter abuse Agent moves messages to dead-letter to hide work, or drains dead-letter and leaks sensitive payloads. Default deny dead-letter operations in WPC; only allow with an approved WPC for incident workflows; short lived CST per incident job.
SAS key exfiltration If SAS is used, a leaked key grants broad access until rotated, and can be used outside Claw EA. Prefer Microsoft Entra ID with Azure RBAC; if SAS is unavoidable, treat it as a high risk secret and scope it to an entity, not the namespace, and keep rotation tight.
Prompt injection causes covert messaging Agent is convinced to encode sensitive data into messages, turning Service Bus into an exfil channel. WPC constrains destinations and message schema; OpenClaw tool policy limits what tools can read sensitive sources; separate “read secrets” tools from “send message” tools.
Misconfiguration of the agent execution boundary Tool runs on host with broad filesystem and network access, so a malicious plugin can harvest credentials and then use Service Bus. OpenClaw sandboxing on by default for non-main or all sessions; deny elevated tools except reviewed break-glass; run OpenClaw security audit regularly.

Policy-as-code example

This is a simplified, JSON-like sketch of a WPC that gates an “azure_service_bus” tool. In practice the WPC is a signed, hash-addressed policy artifact served by clawcontrols and fetched and verified by the proxy.

{
  "wpc_version": "v1",
  "policy_name": "asb-send-orders-staging",
  "tools": {
    "azure_service_bus": {
      "allow": [
        { "op": "send", "entity": "sb://<namespace>.servicebus.windows.net/orders-staging" }
      ],
      "deny": [
        { "op": "manage", "entity": "*" },
        { "op": "send", "entity": "sb://<namespace>.servicebus.windows.net/orders-prod" }
      ],
      "constraints": {
        "max_message_bytes": 131072,
        "max_messages_per_job": 200,
        "require_application_properties": ["schema_version", "correlation_id"],
        "forbid_properties": ["authorization", "cookie", "set-cookie"]
      }
    }
  },
  "auth": {
    "token": "CST",
    "pin_policy_hash": true,
    "job_scoped_binding": true
  },
  "approvals": {
    "required_for_ops": ["manage", "deadletter_read", "deadletter_purge"]
  }
}

The key difference from “prompt-only safety” is enforcement. A prompt can be ignored; a WPC gate denies the tool call even when the model insists, because execution is permissioned by policy.

What proof do you get?

For model calls, clawproxy emits Gateway receipts that record the request/response envelope for the routed model traffic. This gives you a verifiable trail for what the model was asked, what it returned, and when it decided to attempt a Service Bus action under a specific WPC and CST.

For each job, Claw EA packages receipts and run metadata into a proof bundle. The proof bundle can include the WPC hash reference, the CST scope hash (and optional policy hash pinning), job identifiers, and tool invocation summaries suitable for audit and replay checks.

If you publish externally for auditors or internal review, you can store and view the run’s artifact as a Trust Pulse. Treat this as an audit viewer and storage surface, not as a replacement for your SIEM or Azure-native logs.

Rollback posture

A safe rollback plan assumes the agent or the tool wrapper can be wrong. You want fast ways to stop sends, stop receives, and invalidate credentials without needing to redeploy every agent.

Action Safe rollback Evidence
Stop all agent messaging Revoke or expire the CST for the job; deny the Service Bus tool in OpenClaw tool policy for affected agents. Token revocation events and the last proof bundle showing when the agent attempted the blocked action.
Block a single queue or topic Update the WPC to remove the entity allowance and require policy hash pinning so old policies fail closed on the next tool call. WPC hash change record plus proof bundles showing which jobs ran under which WPC hash.
Reduce blast radius after a near miss Split “send” and “receive” into different principals and policies; move the agent to a dedicated subscription or queue. New WPC and CST scope hash, plus receipts demonstrating the changed tool availability and model routing.
Credential containment Prefer Entra ID and rotate or disable the service principal or managed identity; if SAS is used, rotate keys and reduce scope. Azure audit logs on identity changes, plus internal proof bundles correlating job ids to the window of exposure.

FAQ

Is Azure Service Bus integration available as a native Claw EA connector?

No. Azure Service Bus can be connected via official API with enterprise buildout controls, and the tool wrapper must be gated by WPC approval and CST issuance.

Why is prompt-only control not sufficient for Service Bus access?

Prompts do not enforce anything at execution time, and a model can be manipulated or can drift. With permissioned execution, the WPC defines what the tool can do, and the runtime denies calls that are out of policy even if the agent requests them.

Should we use Microsoft Entra ID or SAS for agents?

Microsoft documentation describes both, but Entra ID with Azure RBAC is usually easier to scope and rotate safely for applications and managed identities. If you must use SAS, keep it narrowly scoped and treat it as a high risk secret.

What do gateway receipts prove in a Service Bus workflow?

Gateway receipts prove the model-call side: the exact model request and response that led to a tool action, routed through clawproxy. They do not replace Azure-side delivery confirmation; pair them with Azure logs if you need end-to-end delivery evidence.

How do we prevent an agent from sending to production queues?

Use separate namespaces or entity naming per environment, enforce WPC entity allowlists, and keep distinct Entra ID principals for staging vs production. If a job does not have the WPC allowance and CST pinned to it, the send should be denied by policy.

Sources

Ready to put this workflow into production?

Get a scoped deployment plan with Work Policy Contracts, approval gates, and cryptographic proof bundles for your team.

Talk to Sales Review Trust Layer