Compliance evidence collection to SIEM (Permissioned Execution)
Use OpenClaw as the baseline agent runtime, but treat evidence export as a controlled workflow: policy decides what the agent can read, what it can send out, and what proof it must emit. In Claw EA, you attach a WPC (Work Policy Contract) to the job, issue a CST (scoped token), route model calls through clawproxy for gateway receipts, and emit a proof bundle that your SIEM can ingest via official API.
This works better than prompt-only controls because prompts do not bind execution. A signed WPC plus scoped credentials is machine-checkable, so the system can fail closed when the job deviates from allowed tools, destinations, or evidence handling rules.
Step-by-step runbook
-
Define the evidence boundary and treat two actions as high risk: exporting logs and sharing evidence artifacts. Decide what the agent is allowed to read (log sources), what transformations it may run (parsing, normalization), and what it may emit (OCSF-like events, summaries, or hashes only).
-
Create and register a WPC (Work Policy Contract) that encodes tool allowlists, evidence redaction requirements, and export constraints. Pin the policy hash in the run so operators can prove exactly which policy governed the job.
-
Issue a CST (scoped token) from clawscope for this specific job, with scope hash and optional WPC hash pinning. Use job-scoped binding to reduce replay risk, so a token stolen from one run does not remain useful for another run.
-
Run the agent in OpenClaw with sandboxing enabled for the sessions that touch data and produce exports. Use OpenClaw tool policy to allow only the minimum tools required for log reading, parsing, and packaging.
-
Route model calls through clawproxy so each call produces gateway receipts. If you use OpenRouter via fal, keep it behind clawproxy so receipts and policy checks remain consistent across models.
-
Transform agent activity and outputs into SIEM-ready events, ideally in an OCSF-aligned structure for correlation with existing security telemetry. Send events to your SIEM via official API (for example, an HTTP event collector endpoint) and keep the raw evidence in controlled storage rather than pushing everything into the SIEM.
-
Emit a proof bundle at the end of the run that includes gateway receipts and metadata required for verification. Store the proof bundle (and optionally publish a Trust Pulse artifact for audit viewing) so compliance teams can validate what ran, under which WPC, and which model calls occurred.
Threat model
| Threat | What happens | Control |
|---|---|---|
| Prompt injection causes unauthorized evidence export | The agent is tricked into sending raw logs or sensitive fields to an external destination, or into “helpfully” attaching extra context. | Permissioned execution: WPC restricts export tools and destinations; DLP and redaction rules are enforced as a required pipeline step before any “export logs” or “share evidence artifacts” action. |
| Token replay across runs | A CST is copied and reused to push evidence outside approved timing or scope, or to call models and regenerate artifacts. | Marketplace anti-replay binding with job-scoped CST binding, plus optional policy hash pinning so a token is valid only for the intended WPC context. |
| Disputed model-generated conclusion | An auditor asks: “Which model saw which inputs and produced which output?” and the team cannot show a verifiable trail. | Gateway receipts from clawproxy for model calls, bundled into a proof bundle that can be re-verified later. |
| Over-collection into SIEM | Raw logs with secrets or regulated fields are pushed into the SIEM, multiplying access paths and retention risk. | WPC mandates minimal exports (structured events, hashes, and references), plus DLP/redaction prior to export. Keep raw evidence in controlled storage and export only what detection and audit require. |
| Network exfiltration outside intended domains | The agent uses a generic HTTP tool to send data to a lookalike host or an unexpected IP. | Egress allowlists can be implemented outside clawproxy (optional) and paired with WPC-declared destination allowlists so violations are detected and the job can be stopped. |
Policy-as-code example
This is a compact JSON-like sketch of a WPC payload focusing on evidence export safety. It makes export actions explicit, forces redaction, and limits where evidence can go.
{
"wpc_version": "1",
"policy_name": "siem-evidence-collection",
"policy_hash_pin": "b64u:...",
"runtime": {
"baseline": "OpenClaw",
"sandbox": { "mode": "all", "workspaceAccess": "ro" },
"tools": {
"allow": ["read_logs", "parse", "hash", "package_evidence", "http_export"],
"deny": ["shell", "write_filesystem", "browser_control"]
}
},
"egress": {
"allowlist": {
"domains": ["siem.example.com", "logs.example.com"],
"ips": ["203.0.113.10/32"]
},
"enforcement": "can be implemented outside clawproxy"
},
"dlp": {
"redaction_required": true,
"rules": [
{ "type": "regex", "match": "(?i)api[_-]?key\\s*[:=]\\s*\\S+", "replace": "[REDACTED]" },
{ "type": "field", "fields": ["password", "secret", "token", "ssn"], "action": "drop_or_mask" }
],
"export_block_if_unredacted": true
},
"irreversible_actions": {
"export_logs": { "require_approval": true, "max_records": 5000 },
"share_evidence_artifacts": { "require_approval": true }
},
"auth": {
"cst": { "issuer": "clawscope", "job_scoped_binding": true }
},
"budgets": {
"token_budget": "planned_or_enterprise_buildout",
"cost_budget": "planned_or_enterprise_buildout"
},
"proof": {
"require_gateway_receipts": true,
"emit_proof_bundle": true
}
}
The key difference versus a “be careful” prompt is that this contract is signed and hash-addressed. Your runtime and proxy can verify the WPC and refuse to export if redaction is missing or a destination is outside the allowlist.
What proof do you get?
Every model call routed through clawproxy produces gateway receipts, which give you a tamper-evident record of the calls made under the job’s CST and policy context. These receipts are assembled into a proof bundle with the job metadata needed for later verification, including policy hash references and run identifiers.
For compliance evidence collection, the proof bundle is the artifact you hand to audit and incident review teams. If you use Trust Pulse, you can store and view the audit artifact there without relying on ad hoc screenshots or manual exports.
Rollback posture
| Action | Safe rollback | Evidence |
|---|---|---|
| Wrong destination configured for SIEM export | Rotate or revoke the CST, and re-run the job with a corrected WPC allowlist. Treat previously exported payloads as leaked and follow your IR process. | Proof bundle shows which destination was used, plus gateway receipts for the model calls that prepared the payload. |
| Redaction rule missed a sensitive pattern | Stop exports, update WPC DLP rules, and re-run only on the minimum necessary subset to regenerate sanitized events. If needed, delete impacted SIEM events via official API according to your retention controls. | Proof bundle ties the run to the WPC hash, so you can show which redaction rules were in force for the impacted export. |
| Unexpected tool usage during collection | Tighten OpenClaw tool policy and update the WPC tool allowlist, then re-run in sandboxed mode. Keep the previous proof bundle for postmortem and auditing. | OpenClaw configuration plus the job’s proof bundle provide a concrete record of allowed versus observed behavior, and whether model calls were made under policy. |
| Suspected token replay attempt | Revoke CSTs and require a new job-scoped CST binding for subsequent runs. Re-verify the affected proof bundles and isolate any exports performed outside the expected job window. | Job-scoped CST binding metadata in the proof bundle supports replay investigation, alongside gateway receipts for attempted activity. |
Rollback is not only about stopping an agent. It is about proving what happened, then re-running with a tighter WPC so your evidence trail stays consistent and reviewable.
FAQ
Why is prompt-only governance not enough for SIEM evidence collection?
Prompts do not provide a verifiable boundary around tools, destinations, or redaction. A WPC plus CST makes those constraints machine-checkable, so exports can be blocked when rules are not satisfied.
What should we send to the SIEM versus keep in evidence storage?
Send structured, minimal events that support detection and audit, plus stable references like hashes and run IDs. Keep raw logs and bulky artifacts in controlled storage and export only what you can justify and retain safely.
How do we normalize agent activity into a SIEM-friendly schema?
Map actions into an OCSF-aligned structure where possible, and include job identifiers that link back to the proof bundle. This lets SOC teams correlate agent activity with other telemetry without inventing a new event taxonomy.
Can we enforce egress allowlists and budgets?
Egress allowlists can be implemented outside clawproxy (optional) and driven by the destinations declared in the WPC. Token and cost budgets are planned features; in the meantime, implement them as enterprise buildout controls around CST TTLs, run limits, and upstream provider budgets.
What is the minimum evidence an auditor will ask for?
They usually want to know what ran, under which policy, who authorized exports, and what external calls were made. Gateway receipts and a proof bundle address the “what happened” question without relying on manual operator notes.