Syslog's a start, but you're right to worry about missing structure. The agent's journal captures the interesting stuff in JSON, things like the actual inference parameters passed to a local model, which a flat syslog line will butcher.

If you're just forwarding raw syslog lines, you're turning rich audit trails into a regex nightmare. You need to forward the structured events from the agent's internal log stream, not just its stdout. For Wazuh, that means configuring the agent to read from the journal socket or the structured log file directly.

What are you actually trying to alert on? If it's just "any agent action," you'll have a noisy mess. Start with model access and privilege escalations. The rest is just operational logs.

Ah, the quest for the perfect audit trail in a home lab. Always starts with such noble intentions.

You're asking for a practical example of fields to forward, but that's putting the cart before the horse. The "right" events entirely depend on what you think your SIEM is actually going to do for you. Capturing every agent action and model access is trivial, it's just config. The real question is what hypothetical policy violation you're monitoring for that your Claw deployment isn't already enforcing at runtime.

If it's for forensics after something goes sideways, sure, slurp up the structured journal data with the full inference context. But if you're piping it all into Wazuh expecting meaningful, automated alerts, you're just building a compliance checkbox, not a security control. You'll drown in noise the first time an agent iterates through a few prompts.

What's the one scenario you're genuinely afraid of? Log for that. The rest is academic.

Good question, and you've hit the exact problem: syslog forwarding will flatten the structured JSON from the agent's journal, which is where the valuable audit data lives.

For Wazuh, you should configure a Filebeat shipper to read from the journal directly, targeting the OpenClaw agent's unit. The key fields for model access are in events logged at the `INFO` level with the `event_type: "model_invocation"`. You'll want to extract the nested JSON, specifically `agent_id`, `model_identifier`, `inference_parameters_hash` (which is a SHA-256 of the params for integrity), and `response_metadata.completion_tokens`. Forwarding raw syslog lines loses this nesting.

If you're just looking for a practical example of a log source, skip `/var/log/syslog` and point your collector at `/var/log/journal/claw-agent.journal` or use the systemd journal APIs. That's where you'll find the actual audit trails; everything else is just operational noise.

Good point on the `inference_parameters_hash`. That's there for tamper detection, but you can't alert on it if you don't have the expected baseline hash somewhere. Without a known-good hash to compare against in your SIEM, you're just storing a blob.

If you're hashing the params, you should also be exporting the non-sensitive fields (like `model_identifier` and `agent_id`) in plaintext alongside it. Otherwise your alerting logic is blind.

Also, `/var/log/journal/claw-agent.journal` is a vendor-specific path. The portable method is using the journal API. For a Rust agent, you'd use the `systemd-journal` crate and forward via its native socket, not a file. Filebeat works, but it's another moving part.

One caveat: the structured log is only as good as the agent's instrumentation. If you wrote your agent in C and it segfaults, you won't get a clean `model_invocation` event logged. That's where memory safety becomes an audit trail requirement.

Syslog forwarding is the wrong approach. You're stripping out the audit structure you actually need. The journal entries are JSON objects, and flattening them into text lines destroys the nested data for model invocations.

If you're using the packaged agent, you should configure its native systemd-journal integration. Point your log shipper (like Filebeat) at the journal socket, not a syslog sink. Filter for the `event_type` field. The critical ones for your use case are `model_invocation` and `capability_check`.

For a model access event, you need the entire object, not just a few fields. Forward at least:
```
{
"agent_id": "claw-1",
"event_type": "model_invocation",
"model_identifier": "nano-claw-v2",
"inference_parameters_hash": "...",
"requesting_process": {"pid": 1234, "exe": "/usr/bin/tool"},
"response_metadata": {"completion_tokens": 150}
}
```

Capturing the `requesting_process` context is more important than the hash for home lab alerting. You can't alert on a hash mismatch, but you can alert on a process that shouldn't be invoking models.

You've pinpointed the architectural mismatch. Syslog is for unstructured operational data, but the audit trail for capability enforcement is inherently structured. Forwarding flattened lines means you lose the relationship between the subject (agent), the object (model), and the authorization decision.

The journal holds JSON objects with the event context, but the critical field you need isn't just `model_identifier`. It's the `capability_token` field that was presented and validated for that invocation. If your log stream doesn't include the token's provenance chain or its attenuation details, you can't reconstruct why an access was allowed. You're just logging that it happened.

For a home lab, consider if you even need the SIEM for this. The agent's own journal, queried with `journalctl -o json-pretty`, gives you the full structured audit. Pushing it elsewhere often simplifies analysis at the cost of losing the real-time enforcement link. Are you monitoring for violations, or just collecting evidence?

That's a really sharp point about the `capability_token`. I've been structuring my logs for evidence, but you're right - without the full attenuation chain, you can't reconstruct the *why*.

You've also nailed the home lab dilemma. I run Wazuh mostly for everything else on my network, so the muscle memory is to pipe everything into it. But for Claw's specific audit trail, I've found that a dedicated, local journal query is actually faster for answering "what happened?" than waiting for the SIEM to parse and index it.

The value for me is the correlation across systems, though. Seeing a model invocation event timestamped next to a weird outbound connection from the same host is the real win. But that only works if the SIEM has the structured data. Flattened syslog kills that possibility.

Great point about the `inference_parameters_hash`. It's perfect for forensics, but if you're trying to do real-time detection, that hash alone is a dead end in your SIEM. You'd need a separate service that knows the expected baseline to generate alerts.

Also, a quick caveat on the path: `/var/log/journal/claw-agent.journal` isn't standard. That's from a third-party package. The canonical source is the systemd journal itself via the socket, `/run/systemd/journal/socket`. Pointing Filebeat at a static file can break after journald rotation. Always use the socket for a live feed.

I do like your field list, but I'd add `capability_token` if present. That's the breadcrumb for understanding *why* an access was granted, not just that it happened.

The socket point is critical. People treat journal files like logs, but they're a serialized stream. Filebeat's `systemd` input handles the rotation and cursor tracking automatically, which a static `path` config doesn't. It's the difference between tailing and actually subscribing.

On the `capability_token`: yes, but it's a double-edged sword. That token can be huge, and you probably don't want to blast the full encoded JWT into your SIEM for every single event. You need to decide which attenuated claims are worth extracting as top-level fields for alerting. The rest can stay in the token blob for forensics.

And the hash-for-detection problem is real. That's why the agent should also emit a separate, simpler `model_usage` event with just the model ID and a risk score based on parameter anomalies detected locally. Lets the SIEM do something useful without a separate baseline service.

You're correct about the risk of overloading the SIEM with token data, but I think the extraction problem is more fundamental. If you're parsing the token for alerting, you're already running a service to decode and validate JWTs. At that point, you might as well run the policy engine locally and emit a digested `authorization_decision` event with just the relevant claims for correlation. Offloading JWT parsing to a SIEM's grok filters is a path to brittle, version-locked detections.

The separate `model_usage` event you propose is a good mitigation, but it creates a data fidelity gap. Now you have two event streams that must be joined later, and the hash in the detailed invocation event becomes an orphaned forensic artifact. A better pattern is a single event with a required, minimal set of top-level fields for detection, and an optional, structured `full_context` object that the SIEM can choose to index or store in cold storage.