Azure Event Grid is a push-based changefeed that delivers events to HTTPS webhooks, and it will retry deliveries, so duplicates and replays are normal operating conditions. For permissioned agents running in OpenClaw, you should treat every Event Grid delivery as untrusted input and require policy-as-code gates before the agent can write back to Azure or mutate downstream systems.
Claw EA can connect to Azure Event Grid via official API with enterprise buildout controls, using Work Policy Contracts (WPC), CST (scoped token) issuance, and model traffic routed through clawproxy for gateway receipts. The goal is operational: idempotent event processing, least-privilege auth scopes, and auditable runs with proof bundles.
Step-by-step runbook
1) Define your event contract and idempotency rule. Pick the unique key you will dedupe on (for example, CloudEvents id or Event Grid id plus eventType plus subject). Write down the retention window for dedupe state (hours or days) and what “exactly once” means for your system.
2) Secure inbound delivery to the agent-facing webhook. Prefer Microsoft Entra ID protected endpoints for Event Grid webhook delivery, and validate tokens (issuer, audience, signature, and expected app identity). Keep the endpoint HTTPS-only and implement the Event Grid endpoint validation handshake.
3) Add a permissioned execution layer, not prompt-only controls. Prompts can be overwritten by injected content inside event payloads, so the runtime needs machine-enforced constraints. Put the agent behind a WPC that explicitly defines allowed tools, allowed write actions, required human approvals (if any), and required policy hash pinning for CST.
4) Scope Azure access to the smallest surface that works. Use Entra ID app registrations and restrict permissions (and where applicable, Microsoft Graph permissions/scopes) to only what the event handler needs. For privileged operations, use Conditional Access and Privileged Identity Management (PIM) patterns in your organization, and avoid long-lived secrets.
5) Build an idempotent handler with a two-phase flow. Phase A validates and records the event key as “in progress” before any side effects; Phase B performs the allowed action and then marks “done” with a result hash. If Phase B fails, return an error so Event Grid can retry, but your handler must detect duplicates and safely short-circuit.
6) Run the agent with receipts and an audit trail. Route model calls through clawproxy so every model interaction emits gateway receipts, then package the run into a proof bundle. Store the proof bundle and the run summary where your auditors can retrieve it, and optionally publish a Trust Pulse for viewing.
Threat model
Event Grid is a changefeed, not a trusted command channel. Your agent must assume event bodies can be malformed, duplicated, reordered, or crafted to trigger unsafe tool use.
| Threat | What happens | Control |
|---|---|---|
| Duplicate delivery and replay | Event Grid retries on timeouts and failures; the same event can be delivered multiple times, causing repeated side effects (double ticket creation, repeated configuration changes). | Idempotency key store keyed by CloudEvents id or Event Grid id; job-scoped CST binding to reduce replay across jobs; require WPC-defined “no side effects before dedupe commit”. |
| Prompt injection inside event payload | An event includes text that attempts to override the agent’s instructions, leading to unintended tool calls or credential exfiltration. | Permissioned execution via WPC tool allowlists and explicit action schemas; sandbox tool execution in OpenClaw where applicable; treat event fields as data, not instructions. |
| Webhook endpoint spoofing or weak auth | An attacker posts synthetic events to your webhook and triggers agent workflows without going through Event Grid. | Microsoft Entra ID protected webhook delivery and strict token validation; reject requests that fail validation; log request metadata and event ids for incident response. |
| Over-broad Azure permissions | The agent’s credential can perform admin writes (topic management, subscription updates, broad resource writes) if compromised or misused. | Least-privilege Entra ID app scopes; split roles for read vs write; WPC approval gates for admin actions; short TTL CST and explicit policy hash pinning. |
| Poisoned changefeed causes cascading writes | A misconfigured rule forwards high-volume events; the agent performs expensive or destructive work, saturating queues and producing inconsistent state. | WPC-defined rate and concurrency limits at the worker layer; fail closed on schema mismatches; optional cost budget enforcement can be implemented, but do not rely on it as shipped behavior. |
Policy-as-code example
This example shows the shape of a WPC that makes Event Grid handling safe: it pins what the agent can do, and forces idempotency and explicit approval for write paths. Treat it as a starting point and adjust the action list to your Azure footprint.
{
"wpc_version": "1",
"policy_name": "azure-event-grid-permissioned-handler",
"inputs": {
"event_grid": {
"require_azure_entra_protected_webhook": true,
"required_event_types": ["Microsoft.Storage.BlobCreated", "Custom.ChangefeedItem"],
"idempotency_key": "cloudevents.id",
"dedupe_ttl_seconds": 86400
}
},
"auth": {
"cst": {
"require_scope_hash": true,
"pin_wpc_hash": true,
"max_ttl_seconds": 1800,
"job_scoped_binding": true
}
},
"execution": {
"runtime": "OpenClaw",
"sandbox": { "mode": "all", "workspace_access": "ro" },
"tools": {
"allow": [
"http.fetch",
"json.parse",
"azure.eventgrid.publish.via_official_api"
],
"deny": ["shell.exec", "filesystem.write", "browser.remote_control"]
}
},
"approvals": [
{
"action": "azure.eventgrid.admin_write",
"required": true,
"reason": "subscription/topic changes require explicit approval"
}
],
"logging": {
"record_event_id": true,
"redact_secrets": true
}
}
What proof do you get?
When the agent uses an LLM during event handling, you can route those model calls through clawproxy and receive gateway receipts for each call. Those receipts are designed for verification: they tie a specific model interaction to a specific run context, rather than relying on application logs.
Claw EA then packages receipts and related run metadata into a proof bundle. In an enterprise buildout, you typically include the Event Grid delivery identifiers you processed (event id, subject, eventType, timestamp) and the dedupe decision (first-seen vs duplicate) so auditors can verify idempotency behavior alongside the model receipts.
If you need a marketplace-visible artifact, you can store the proof bundle and expose it via Trust Pulse for audit viewing. Separately, CST job-scoped binding helps reduce cross-job replay, so the same token cannot be reused to “legitimize” an unrelated run.
Rollback posture
Rollback for Event Grid handlers is mostly about stopping writes, draining retries safely, and proving what happened. Plan for duplicates and partial failures, and make rollbacks a policy change, not a prompt edit.
| Action | Safe rollback | Evidence |
|---|---|---|
| Disable side effects while still acknowledging events | Update WPC to deny write tools and allow only classification and logging; keep idempotency store active so retries do not accumulate work. | WPC hash used for the run; proof bundle shows denied tool attempts (if any) and the model gateway receipts for the decision path. |
| Quarantine a suspicious event type | Update WPC required_event_types allowlist to remove the eventType, and fail closed on unexpected schemas. | Run metadata shows rejected eventType and event id; proof bundle ties the rejection behavior to the pinned WPC. |
| Reprocess with a corrected handler | Replay from your own stored event log, not from Event Grid retries; reset dedupe entries only for a targeted subset of keys. | New proof bundles reference the reprocess job context; gateway receipts show the model inputs used for the corrected decision. |
| Credential compromise response | Revoke CST issuance for the scope, rotate Entra ID credentials, and tighten app permissions; require approvals for any admin writes. | Token issuance and revocation events from clawscope; proof bundles identify which job-scoped CST was used for each run. |
FAQ
How do I make Azure Event Grid deliveries idempotent for an agent?
Assume duplicates and implement a dedupe store keyed by the CloudEvents id or Event Grid id, recorded before any side effects. Treat “already processed” as a successful no-op, and store a result hash so you can prove consistent outcomes.
Why is policy-as-code required instead of a carefully written prompt?
Because event payloads are untrusted and can contain instructions that conflict with your intent. A WPC enforces the allowed tools and write paths even if the model output is manipulated, which a prompt alone cannot guarantee.
Is this a native Claw EA connector for Azure Event Grid?
No. Azure Event Grid can be connected via official API with enterprise buildout controls, and the integration should be treated as implementable rather than shipped as a native connector.
What should I use for authentication on the webhook endpoint?
Use Microsoft Entra ID protected webhook delivery where possible and validate the token on every request. Also implement the Event Grid endpoint validation flow and reject any request that does not match expected issuer, audience, and client identity.
What do I get that helps with audit and replay checks?
Model-assisted runs can produce gateway receipts (from clawproxy) and proof bundles that package those receipts with run metadata, including event ids and dedupe decisions. This makes it practical to verify what the model saw and what policy was in force for the run.