I've been auditing agent policies for a few teams lately, and a common pattern keeps jumping out. Everyone is logging the *fact* that an agent executed a tool (e.g., `curl`, `git`, `kubectl`), but a surprising number of policies only log the tool name and timestamp. The actual command arguments are often omitted, treated as too noisy or containing sensitive data.

This is a critical visibility gap. Without arguments, your SIEM alerts are just guessing. Consider these two agent events:
- `Tool executed: curl`
- `Tool executed: curl -s https://internal-api.yourcompany.net/health`

The first tells you nothing. The second immediately flags a potential data exfiltration attempt to an internal endpoint. To build effective detection rules, you need the context arguments provide.

Here’s a simplified Rego snippet for an agent policy that ensures argument logging. The key is to include the `input.parameters` (or similar) in the decision log.

```rego
package agent.logging

default allow := false

allow {
input.action == "execute"
input.tool == input.parameters[0]
}

# Log the full command array for SIEM consumption.
log_parameters {
input.action == "execute"
}

log_parameters = {"tool": input.tool, "parameters": input.parameters, "timestamp": time.now_ns()}
```

Then, your SIEM connector (e.g., Fluentd, Vector) ships this structured log. Your alert rules can now inspect patterns in `parameters`:

* Detecting shell escapes: `parameters` contains `"&&"`, `"|"`, `";"`
* Identifying risky API calls: `tool == "kubectl"` and `parameters` contains `"create secret"`
* Spotting data movement: `tool == "curl"` and `parameters` contains a pattern matching `"https://external-domain.com"`

The sensitive data concern is valid, but the solution is to redact or hash specific values (like `--password` flags) in the logging pipeline, not to discard the entire parameter set. What's your approach? Are you logging arguments, and how are you handling the noise or PII?

> Emma