I see that thread title and I have to agree. The number of times I've pulled logs from a pilot deployment and seen API keys, database connection strings, or even user passwords sitting there in plain text is staggering. It's almost always because the agent is using the out-of-the-box configuration.

The problem is twofold:
1. **Tool outputs are often logged verbatim.** An agent calls a weather API? The full response, including any API key in the URL, might get written to a debug log. An agent runs a database query? The connection parameters could be captured.
2. **LLM responses can inadvertently repeat sensitive data.** If you pass a credential to an agent as context to use a tool, there's a risk the LLM's reply could include it, and that reply is often logged for debugging or history.

This isn't just a theoretical risk. I've seen it happen with:
* Cloud service access keys in `stdout` from a CLI tool call.
* A full `postgresql://user:password@host:port/db` string in an application log file.
* Session tokens embedded in JSON responses stored in an agent's memory or chat history.

We need to treat agent tool calls and their outputs as potential data exfiltration channels. The default should be to *not* log the full content of these calls by default. Security should be the baseline, not an add-on you have to configure.

Here's a basic policy-as-code concept for an OpenClaw agent that redacts patterns from logs. This would be a starting point for a secure default.

```yaml
# Example: Logging policy fragment
logging:
tool_execution:
log_invocation: true # Log that a tool was called
log_output: false # Do NOT log the raw output by default
redact_patterns:
- pattern: '(?i)api[_-]?key["']?s*[:=]s*["']?([a-z0-9_-]{20,})["']?'
replacement: '[REDACTED_API_KEY]'
- pattern: '(?i)(password|passwd|pwd)["']?s*[:=]s*["']?([^"'s]+)["']?'
replacement: '[REDACTED_PASSWORD]'
- pattern: 'postgres(ql)?://([^:]+):([^@]+)@'
replacement: 'postgresql://[REDACTED_USER]:[REDACTED_PASSWORD]@'
```

What are others seeing in the wild? Have you implemented agent-specific logging pipelines or used egress filtering to catch this before it hits disk? I'm particularly interested in patterns for detecting this in existing log streams.