Azure Key Vault is the right place to store production secrets, keys, and certificates, but it is a high-impact target for enterprise agents. If an agent can read or mutate vault contents from a prompt, a single prompt-injection or misconfigured plugin can turn into credential theft, key rotation, or outage.
Claw EA runs OpenClaw as the baseline agent runtime and treats Key Vault access as permissioned execution: actions must be authorized by policy-as-code, not by prompt text. In practice that means a WPC (Work Policy Contract) for what is allowed, a CST (scoped token) for how the job is authorized, and proof artifacts (gateway receipts and proof bundles) for audit.
Step-by-step runbook
This integration is not a native connector today. Azure Key Vault can be connected via official API with enterprise buildout controls, using Entra ID authentication and least-privilege Azure RBAC.
-
Define the Key Vault boundary you will permit: vault name(s), secret name prefixes, and whether the agent can only read current versions or also list and manage versions. Decide up front if write, delete, purge, and key operations are disallowed by default.
-
Create a WPC that encodes the allowed Key Vault operations as an explicit allowlist, including any required human approval gates for write and admin actions. Publish the WPC to the WPC registry and treat the policy hash as a release artifact.
-
Issue a CST (from clawscope) bound to the job scope hash, and optionally pin the policy hash so the run cannot silently switch policies. Use short TTLs and separate CSTs for read-only versus write-capable paths.
-
Implement Key Vault tool calls via the official API with enterprise buildout, using Entra ID (application or workload identity) and Azure RBAC roles scoped to the minimum vault scope. If you need interactive access, use Conditional Access and PIM for operators, not for the agent runtime identity.
-
Run the agent in OpenClaw with tool policy tightened: only the Key Vault tool and required supporting utilities are available, and tool execution is sandboxed where possible. Avoid elevated execution except for explicit break-glass runs, because elevated tool execution bypasses the sandbox boundary.
-
Route model traffic through clawproxy so model calls produce gateway receipts. At job completion, package the run output plus receipts into a proof bundle and store it for audit, or publish the audit view as a Trust Pulse when needed.
Threat model
Key Vault is a concentration point: one secret can unlock databases, queues, CI systems, and customer data. Treat every agent run as “assume breach”, and design for the case where the agent or a plugin behaves incorrectly.
| Threat | What happens | Control |
|---|---|---|
| Prompt injection causes unintended secret retrieval | The agent is tricked into calling “get secret” for sensitive names, then exfiltrates values into chat logs, tickets, or model context. | WPC allowlist by vault and secret prefix; deny list operations like list-all; OpenClaw tool policy restricts available tools; keep redaction on in logging settings. |
| Malicious or compromised plugin expands access | A plugin adds a new tool path (or hidden parameters) that can read broader secrets or call admin APIs. | WPC must explicitly enumerate methods and resource patterns; CST scope hash pinning plus optional policy hash pinning; OpenClaw extension allowlist and regular security audit. |
| Write or delete operations cause outage | The agent rotates a credential, overwrites a secret, disables a key, or deletes a certificate, breaking production dependencies. | WPC approval gates for write/admin actions; split identities and CSTs for read vs write; require change ticket metadata in the job scope; default deny for delete/purge. |
| Over-broad Azure RBAC assignment | The runtime identity gets Key Vault Administrator or broad subscription scope, making policy mistakes catastrophic. | Azure RBAC roles scoped to a single vault and needed data-plane permissions only; separate admin identity controlled via PIM; periodic access review. |
| Secrets leak into model calls | Even if the tool call is legitimate, the secret value can appear in prompts, tool outputs, or downstream LLM traffic. | Minimize returned fields; redact tool outputs; do not echo secrets back to the model; prefer “use secret to call service” over “retrieve secret and print”. |
| Replay of prior privileged job | An attacker reuses an old token or job parameters to repeat a previously approved Key Vault action. | Marketplace anti-replay binding using job-scoped CST binding; enforce short CST TTL; require fresh WPC verification each run. |
Policy-as-code example
This is a sketch of the kind of policy you want in a WPC: explicit operations, explicit resources, and explicit gates. Prompt instructions are not an authorization layer because they can be overridden by untrusted input.
{
"policy_version": "wpc.v1",
"name": "keyvault-permissioned-agent",
"resources": {
"azure_key_vault": {
"vaults": ["kv-prod-finance-001"],
"secrets": {
"allow_prefixes": ["agent/app/", "agent/readonly/"],
"deny_prefixes": ["prod/", "breakglass/"]
}
}
},
"operations": {
"secrets.get": { "allowed": true },
"secrets.list": { "allowed": false },
"secrets.set": {
"allowed": true,
"approval": { "required": true, "reason": "Write requires explicit approval" }
},
"secrets.delete": { "allowed": false },
"keys.*": { "allowed": false },
"certificates.*": { "allowed": false }
},
"auth": {
"cst": {
"require_scope_hash": true,
"pin_policy_hash": true
}
},
"logging": {
"redact_tool_outputs": true
}
}
What proof do you get?
For model traffic, clawproxy emits gateway receipts for model calls. Those receipts let you verify what model was called, when, and under which job scope, without trusting an application log line that can be edited.
At the end of a run, Claw EA can package receipts and run metadata into a proof bundle. If you need an auditor-friendly view, you can store and view the run artifact as a Trust Pulse, with replay checks tied to the job-scoped CST binding.
Rollback posture
Key Vault mistakes are usually reversible, but the operational path depends on whether the agent wrote a new value, removed an old one, or changed access. Plan rollback as part of the WPC, not as an incident improvisation.
| Action | Safe rollback | Evidence to collect |
|---|---|---|
| Secret value overwritten | Restore prior secret version if available; rotate dependent services in a controlled window; invalidate any leaked value. | Proof bundle for the job; change ticket reference in job scope; Key Vault version identifiers recorded by the tool output (redacted values). |
| Secret deleted (soft delete enabled) | Recover the secret and re-enable access; verify dependent apps reconnect with expected identity. | WPC that permitted or denied delete; CST issuance record for the job; run logs showing the attempted operation. |
| Key or certificate modified | Revert to previous version where possible; reissue certs through your normal PKI workflow; treat as security incident if private material might be exposed. | Approval gate record (if required by WPC); proof bundle; inventory of affected workloads and timelines. |
| Azure RBAC role assignment changed | Remove role assignment; re-run access review; rotate any credentials that could have been accessed during the exposure window. | WPC and CST used; operator audit trail (outside Claw EA); proof bundle tying the run to the job scope. |
FAQ
Is Azure Key Vault support available as a native Claw EA connector today?
No. It can be connected via official API with enterprise buildout controls, and you should treat the buildout as security-sensitive because it is effectively a privileged tool.
Why is prompt-only control not enough for Key Vault access?
Prompts are instructions, not enforcement. A malicious email, document, or chat message can redirect the agent, so you need policy-as-code enforced by a WPC and job-bounded authorization via CST.
How do Entra ID and Azure RBAC fit with WPC and CST?
Entra ID and Azure RBAC are the cloud authorization layer for the Key Vault identity. WPC and CST are the agent execution authorization layer that constrains when and how that identity is used during a specific job.
Can the agent use Azure MCP Server for Key Vault?
It can be implemented, but this page assumes connection via official APIs and enterprise buildout controls. If you do use an MCP server, still apply the same WPC allowlists and CST job binding, and treat the MCP tool surface as part of the audit scope.
What do I show an auditor after an incident?
Provide the WPC (by hash), the CST scope hash details for the job, and the proof bundle containing gateway receipts and run metadata. This lets an auditor verify what the model calls were and which policy governed the run.