First, you need to understand that the agent's log destination isn't defined by the agent itself, but by your container runtime configuration and the logging driver you choose. The agent's stdout/stderr is captured by the Docker daemon, and from there it's a routing problem.

By default, Docker uses the `json-file` logging driver. Those logs are stored in a JSON file on the host, which you can find at:

```
/var/lib/docker/containers//-json.log
```

You can view them with `docker logs `. However, for monitoring exfiltration, this default is useless for any real-time analysis. You need to forward them.

For a security-focused setup, you should configure a different logging driver at the daemon level (`/etc/docker/daemon.json`) or per-container. Common choices for aggregation:

* `syslog` driver to a central syslog server.
* `journald` driver if you're using systemd.
* `splunk`, `loki`, or `fluentd` drivers for specific platforms.

A per-container example for syslog:

```json
docker run
--log-driver=syslog
--log-opt syslog-address=udp://192.168.1.10:514
--log-opt tag="openclaw-agent"
your-openclaw-agent-image
```

Critical point: If your agent process *also* writes to a file inside the container (e.g., `/var/log/agent.log`), you must bind-mount that volume to the host or it will be lost when the container stops. This is a common misconfiguration.

* Bad: Logging only to a container filesystem with no volume/driver.
* Good: Agent outputs to stdout/stderr, captured by Docker and forwarded via a logging driver to your SIEM or log aggregator.

Without this, you have no logs to analyze for anomalous outbound connection patterns. Start here.