Event-native agents are agents that run because an external system emitted an event: a webhook, a changefeed item, or a subscription notification. Claw EA makes these runs permissioned and auditable using OpenClaw as the baseline agent runtime, plus policy artifacts and receipts that survive incident review.
Prompt-only controls fail in event pipelines because the attacker controls inputs and timing. You need policy-as-code that binds who can trigger a run, what tools can execute, and what model calls are allowed, enforced under a Work Policy Contract (WPC) and verified via gateway receipts and proof bundles.
Step-by-step runbook
Use this runbook when you are wiring webhooks or change notifications into an agent and you need idempotency, replay resistance, and audit evidence. The goal is a fail-closed path from inbound event to tool execution.
-
Define the trigger boundary and idempotency key. Pick a stable key per event (for example: vendor event id, change sequence, or a hash of canonicalized payload plus source). Store the key in your job state so retries do not re-run side effects.
-
Write a WPC for this trigger class. In the WPC, constrain allowed tools, allowed model/provider routing, and required input fields you will validate before any tool runs. Keep the WPC small and hash-addressed so it can be pinned and reviewed.
-
Issue a CST for the trigger runner. The runner that receives events should get a CST (issued by clawscope) that is job-scoped and optionally pins a specific WPC hash. If the CST is stolen, the scope and job binding limit replay usefulness.
-
Verify the event signature and normalize payloads before the agent sees them. Validate vendor signatures, timestamps, and required headers at the perimeter, then canonicalize the payload into a minimal “event context” object. Pass only the normalized context into OpenClaw, not raw headers and not arbitrary JSON.
-
Run the agent through clawproxy for model calls. Route model traffic through clawproxy so each model call yields gateway receipts. Keep tool execution inside OpenClaw’s tool policy and sandboxing settings so “what ran where” is inspectable.
-
Emit a proof bundle and retain it with the job record. After completion, bundle the gateway receipts plus run metadata into a proof bundle. Use the proof bundle as your audit handle for later verification and escalation.
Getting started checklist: pick an idempotency key, write one WPC per trigger type, scope one CST per job, route model calls via clawproxy, and require a proof bundle for every completion.
Threat model
Event inputs are untrusted even when they originate from a trusted vendor. The main risk is that “a valid event” becomes “arbitrary remote control” when prompt content flows into tools without policy enforcement.
| Threat | What happens | Control in Claw EA |
|---|---|---|
| Webhook replay and duplicate delivery | Vendor retries or attacker replays a captured request; you re-run side effects (emails, tickets, transfers). | Idempotency key stored per job plus marketplace anti-replay binding using job-scoped CST binding. |
| Signature bypass or weak validation | Attacker sends forged events to trigger privileged actions. | Perimeter verification plus WPC-required fields and fail-closed execution if validation artifacts are missing. |
| Prompt injection via event payload | Event text tricks the agent into calling tools outside intended workflow. | Permissioned execution under a WPC, not prompt-only, plus OpenClaw tool policy and sandboxing to limit blast radius. |
| Overbroad tokens shared across trigger types | A token intended for “read-only triage” gets reused for “write to production,” enabling lateral movement. | CST scope hash and optional policy hash pinning so each trigger runner is constrained to an explicit WPC. |
| Model-call repudiation | You cannot prove which model was called, what inputs were sent, or whether the agent used an unapproved route. | Gateway receipts emitted by clawproxy for model calls, included in a proof bundle for verification. |
| Subscription drift (changefeed gaps) | Your change notification subscription expires or loses state; you miss events and silently stop enforcing controls. | Operational runbook: subscription lifecycle checks plus job records that require proof bundles for completion and alert on missing runs. |
Microsoft Graph change notifications (specific pitfall): treat each notification as a trigger to fetch the authoritative resource via official API, then decide actions based on that fetched state. Keep Graph permissions/scopes minimal (for example, read scopes for triage paths) and use Entra ID Conditional Access and PIM for operator access to the app registration and secrets.
Policy-as-code example
This is a sketch of what you want the policy to express for an event-native run. The important part is that the policy is machine-checked and pinned (WPC), rather than buried in prompts or tribal knowledge.
{
"wpc_ref": "wpc:sha256:",
"trigger": {
"type": "webhook|changefeed|graph_change_notification",
"required_headers": ["signature", "timestamp"],
"idempotency": { "key": "event_id", "ttl_seconds": 86400 }
},
"execution": {
"tools_profile": "event-triage",
"tools_allow": ["read", "search", "http_fetch_via_official_api"],
"tools_deny": ["shell", "write_files", "payments", "admin_actions"],
"sandbox": { "mode": "all", "workspace_access": "ro" }
},
"model_routing": {
"via": "clawproxy",
"provider": "openrouter_via_fal",
"require_gateway_receipts": true
},
"token": {
"cst": {
"scope_hash": "",
"pin_wpc_hash": "",
"job_bound": true
}
}
}
If you later need to widen access, do it by issuing a new WPC and updating the pinned hash. That creates an explicit change record rather than a silent behavior change.
What proof do you get?
For every agent run, you can retain verifiable artifacts instead of screenshots and best-effort logs. This is how you answer “what executed” and “under which constraints” when a webhook run creates an incident.
-
Gateway receipts: signed receipts emitted by clawproxy for model calls. They let you audit which model calls occurred during the run and tie those calls to a specific job context.
-
Proof bundle: a harness artifact bundling receipts and related metadata for audit/verification. Store it alongside the job record and use it for later review or verification workflows.
-
WPC reference: the Work Policy Contract (WPC) hash that governed the run, fetched and verified from the WPC registry. This matters because the same event payload under a different WPC can be allowed or denied.
-
Trust Pulse (optional): a marketplace-stored artifact for audit/viewing. Use it when you need to share a run’s evidence with a separate review group without giving them runtime access.
Rollback posture
Event systems retry, reorder, and duplicate. Your rollback posture should assume a run can partially succeed, then be retried later with the same event id.
| Action | Safe rollback | Evidence |
|---|---|---|
| Stop new triggers immediately | Rotate or revoke the CST for the trigger runner; runs fail closed while you investigate. | Token issuance and revocation records (operational), plus absence of new proof bundles for blocked jobs. |
| Freeze tool side effects | Update to a tighter WPC that denies write tools; pin the new WPC hash for subsequent jobs. | WPC hash change plus proof bundles showing denied tool attempts or altered tool availability. |
| Re-run deterministically | Reprocess from a stored event context using the same idempotency key; only missing steps execute. | Job record keyed by idempotency plus proof bundles per attempt (each with gateway receipts). |
| Post-incident verification | Verify proof bundles and compare to expected WPC and CST scope hash. | Proof bundle contents: gateway receipts, WPC reference, CST binding metadata. |
Egress allowlists enforced outside clawproxy and automatic cost budget enforcement are optional and can be implemented as an enterprise buildout if you need stronger containment during rollback windows.
FAQ
How do you handle idempotency for webhooks and changefeeds?
Pick an idempotency key that is stable across retries, then persist it per job before any side effect. Treat “already processed” as success, and store enough state to continue partial workflows without repeating writes.
Why is policy-as-code required instead of prompt instructions?
Event payloads are attacker-controlled inputs, so prompt-only guardrails can be overwritten by injected content. A WPC makes the execution layer permissioned: tools, routing, and token scopes are enforced even when the prompt is hostile.
What is the minimum Claw Bureau setup for trigger security?
Use a WPC to define what the run is allowed to do, a CST (issued by clawscope) to bind the runner to that policy, and route model calls via clawproxy to get gateway receipts. Then store the proof bundle per run so you can audit and verify after the fact.
How do Microsoft Graph change notifications fit into this model?
Use the notification only as a trigger to fetch the authoritative object via official API, then apply your WPC-governed workflow. Keep Graph permissions/scopes minimal, and manage the app and credentials under Entra ID controls like Conditional Access and PIM.
Can we prove which model the agent actually called?
You can prove the model call path that went through clawproxy using gateway receipts, then package them into a proof bundle. If a run bypasses the proxy, you will not have those receipts, which is why proxy routing should be required for event-native workloads.