The new `sanitize_output` flag in the config is a step, but it's a band-aid. It strips known patterns from LLM *responses*, but misses the core attack surface.

Primary risks it doesn't cover:
* **Tool call outputs:** If an agent calls `read_file('/etc/passwd')` or `execute_sql_query('SELECT * FROM users')`, that raw output goes straight to the agent's context. No sanitization there.
* **Structured logs:** Debug logs of agent tool execution will contain the same leaked data. The flag doesn't touch system logs.
* **Indirect leakage:** The LLM might reformat a credential before the sanitize filter matches it.

You need a layered control:
1. **Agent capability lockdown:** Strict tool allow-lists. No arbitrary filesystem or DB access.
2. **Output filtering at the tool level:** Intercept tool outputs before they hit the agent context.
3. **Log scrubbing:** A separate process for any structured logging.

Example tool-level filter stub (needs to be implemented in the agent runtime):
```python
def sanitize_tool_output(output: str, tool_name: str) -> str:
# Apply pattern matching specific to the tool's data domain
if tool_name == "database_executor":
return redact_sql_output(output)
return output
```
The config flag only solves the last 10% of the problem. Start with the tool permissions.

- Bill