Azure Storage is a high-impact tool for enterprise agents because it can read and write business data at scale, and small mistakes turn into large data exposure or data loss. Claw EA treats Azure Storage access as permissioned execution: actions are allowed only when a Work Policy Contract (WPC) is satisfied, and the run is bound to scoped tokens (CST) plus verifiable gateway receipts and proof bundles.
This is not a native connector today. Azure Storage can be connected via official API with enterprise buildout controls, with write and admin actions gated by WPC approval, CST scope hash, and explicit least-privilege auth scopes.
Step-by-step runbook
Use this runbook when you want an OpenClaw-based agent to interact with blobs, containers, or queues without turning “agent can access storage” into “agent can exfiltrate everything.” The goal is deterministic permissions, traceable runs, and fast rollback.
-
Define the storage blast radius (accounts, containers, prefixes, and operations). Treat “list containers” and “enumerate blobs” as sensitive because it reveals names, tenancy structure, and data layout.
Write down the minimum set of operations for the job, for example: read a single prefix, write to a staging prefix, delete only temporary outputs.
-
Choose the enterprise auth pattern for Azure Storage via official API. For enterprise builds, this is typically Microsoft Entra ID with a service principal or managed identity, then Azure RBAC roles on the storage account or container.
Use least privilege and separate identities for read-only versus write paths; avoid reusing human identities for agent runs.
-
Create a WPC that encodes allowed operations for the Azure Storage tool. The WPC should include the allowed account, container, and prefix constraints, plus whether “list” is permitted.
Store the signed, hash-addressed WPC in the WPC registry (served by clawcontrols) and treat the hash as the policy identifier used in runs.
-
Issue job-scoped CST (from clawscope) that pins to the WPC hash when you need strict change control. This keeps an agent from silently switching to a broader policy mid-run, and supports anti-replay binding for job-scoped CST usage.
Set short TTLs and rotate between jobs. Do not reuse CST across unrelated tasks.
-
Route model calls through clawproxy so you get gateway receipts for every model call used to plan or justify storage actions. This matters when an incident review needs to connect “why was delete called” to the model outputs that caused it.
At the end of the run, collect the proof bundle that ties together the receipts and metadata required for verification and audit.
-
Run in OpenClaw with sandbox and tool policy enabled as the baseline runtime control. Use OpenClaw’s tool policy and sandboxing to limit local file and process access, then use the WPC for remote action constraints.
Run OpenClaw’s security audit regularly after config or policy changes to catch common “open gateway” and permission footguns.
Threat model
Azure Storage is attractive to attackers because it is both data and delivery: it can store sensitive documents and also serve as a staging area for malicious payloads. Agents add risk because they can be driven by prompt injection, mis-scoped credentials, or unsafe tooling defaults.
| Threat | What happens | Control (operational) |
|---|---|---|
| Overbroad read access | Agent lists containers or reads large prefixes, leaking regulated data into prompts, logs, or downstream tools. | WPC restricts account, container, and prefix; CST scope hash enforces the bound policy; separate read identities; disable list operations unless required. |
| Unsafe write or overwrite | Agent overwrites canonical blobs, corrupts datasets, or writes unreviewed content into production paths. | WPC requires explicit allowlist of write prefixes and disallows overwrite unless named; require a review gate for “write to prod” actions; use separate storage location for drafts. |
| Destructive delete | Agent deletes containers or critical blobs due to a misread instruction or malicious prompt. | WPC blocks delete by default; allow delete only on temporary prefixes with narrow patterns; use time-limited CST and require re-authorization for any delete expansion. |
| Credential misuse and replay | Tokens are copied from one job to another, or from a lower-trust environment into prod, then used to access storage. | Job-scoped CST binding to prevent replay across jobs; short TTL; separate Entra ID applications per environment; rotate secrets and revoke on incident. |
| Prompt injection leading to exfiltration | Agent is tricked into uploading local files or secrets to a blob, or into copying blobs to attacker-controlled locations. | OpenClaw sandbox and tool policy limit local file reads; WPC denies unknown destinations and restricts uploads to approved prefixes; human approval gate for cross-account copy. |
| Audit gaps | You cannot prove what the model said, what policy was in force, or which runs touched which data. | Route model calls through clawproxy for gateway receipts; produce a proof bundle per run; store the bundle for later verification and attach it to change tickets. |
Policy-as-code example
This example shows the shape of a WPC that constrains Azure Storage actions. Treat it as a sketch: your enterprise buildout can map these fields to the specific Azure Storage operations you allow via official API.
{
"wpc_version": "1",
"policy_name": "azure-storage-ingest-staging-only",
"constraints": {
"azure": {
"tenant_id": "00000000-0000-0000-0000-000000000000",
"subscription_id": "11111111-1111-1111-1111-111111111111"
},
"storage": {
"accounts": ["stgacct01"],
"containers": ["ingest"],
"prefix_allowlist": ["incoming/", "work/"],
"operations": {
"allow": ["blob.read", "blob.write", "blob.list"],
"deny": ["container.delete", "blob.delete", "account.list"]
},
"write_rules": {
"no_overwrite": true,
"max_object_bytes": 104857600
}
}
},
"approvals": {
"required_for": ["any_delete", "write_outside_prefix_allowlist"]
},
"attestation": {
"require_cst_policy_hash_pinning": true
}
}
Prompt-only controls fail here because the model can be induced to ignore text instructions under pressure. A permissioned execution layer enforces the policy even when the prompt is adversarial, and it fails closed when a requested action is outside the WPC.
What proof do you get?
For model reasoning and planning, clawproxy emits gateway receipts for model calls. These receipts are signed and can be used to verify what model traffic occurred during the run, which matters when a storage action needs post-incident justification.
Claw EA packages receipts and run metadata into a proof bundle. In practice, you attach the proof bundle to your incident ticket or change record, and optionally store a Trust Pulse artifact for audit viewing.
For Azure Storage actions themselves, the enterprise buildout can log and correlate tool invocations to the same job identifier and CST used for the run. This gives you one thread from “who authorized” to “what policy was in force” to “what the agent attempted.”
Rollback posture
Rollback for agents touching storage is about constraining what can change, then making reversal cheap. You want a safe stop that works even when the agent is confused or the prompt is hostile.
| Action | Safe rollback | Evidence to collect |
|---|---|---|
| Agent begins unexpected enumeration | Revoke the CST and end the job; tighten WPC to remove list permissions and reissue a new CST for a corrected run. | Proof bundle plus the WPC hash referenced by the CST; list of attempted operations and affected prefixes. |
| Unexpected writes to a prefix | Move writes behind a staging prefix; block additional writes by updating policy and rotating credentials; clean up staging content with a scripted, human-reviewed job. | Proof bundle; inventory of written blob names and hashes; job-scoped CST identifier used for the run. |
| Suspected credential leakage | Revoke CST immediately; rotate Entra ID secrets or credential material; reduce RBAC role scope; require re-approval to resume. | Proof bundle; CST issuance and revocation records; affected storage account and identity. |
| Need to pause all agent storage access | Fail closed by removing WPC approval for any storage actions and blocking CST issuance for that policy until review completes. | WPC change record, policy hash history, and proof bundles from recent runs for sampling. |
Some controls such as egress allowlists enforced outside clawproxy can be implemented as part of an enterprise buildout if you need additional containment. Treat that as a separate layer from permissioning the storage tool itself.
FAQ
Is Azure Storage supported as a native Claw EA connector today?
No. Azure Storage can be connected via official API with enterprise buildout controls, and you should plan for a scoped, audited tool implementation rather than assuming out-of-the-box connectivity.
Why is prompt-only guidance not enough for storage access?
Because prompts are not enforcement. A WPC is enforced by the execution layer, so disallowed reads, writes, and deletes fail closed even if the model is manipulated or simply mistaken.
How do WPC and CST work together for least privilege?
The WPC defines the allowed operations and scope, and the CST is issued to match that scope for a specific job. With CST scope hash and optional policy hash pinning, the run stays bound to the intended policy.
What Microsoft controls should we pair with Claw EA?
Use Microsoft Entra ID identities (managed identity or app registrations), Azure RBAC roles scoped to the smallest resource set, and Conditional Access and PIM for human administrators. Keep admin actions separate from agent identities and require explicit approvals for privilege increases.
What do we hand to audit or incident response?
Provide the WPC hash, CST identifiers used for the run, gateway receipts, and the proof bundle. If you use Trust Pulse, store the audit artifact there for consistent review access.