sensitive-logging-audit

---
name: sensitive-logging-audit
description: Audit or fix sensitive-data exposure in Python SDK diagnostics, exceptions, logging, and telemetry.
---

# Sensitive Logging Audit

## Objective

Find candidate output sinks, trace their values manually, fix demonstrated leaks at shared runtime boundaries, and prove redaction with adversarial tests.

The collector is only a syntax-based search aid. It does not resolve Python aliases or control flow, certify policy guards, or prove that an absent candidate is safe.

## Workflow

### 1. Establish the review surface

- Work in the current checkout and preserve unrelated changes.
- Read `src/agents/_debug.py`, `src/agents/logger.py`, and the affected callers.
- Treat exception messages, arguments, tracebacks, causes, contexts, notes, names, URLs, and arbitrary values as potentially sensitive.
- Read [the Python redaction validation matrix](references/redaction-validation.md).

Run the collector tests, then collect candidates:

```bash
uv run python .agents/skills/sensitive-logging-audit/scripts/test_inventory.py
uv run python .agents/skills/sensitive-logging-audit/scripts/inventory_logging.py \
  --format json --output /tmp/sensitive-logging-candidates.json
```

The report intentionally contains no `policy`, `safe`, or guard classification.

### 2. Supplement the collector with source search

The collector does not follow assignments such as `emit = logger.error`. Search the source directly and inspect aliases, callbacks, wrappers, and reflective dispatch:

```bash
rg -n '\.(debug|info|warning|warn|error|exception|critical|fatal|log)\b' src/agents
rg -n '\b(print|pprint|pp|warn|warn_explicit|write|writelines|print_exc|print_exception)\b' src/agents
rg -n 'DONT_LOG_(MODEL|TOOL)_DATA|log_(model|tool|model_and_tool)_action' src/agents
```

Do not turn collector coverage or a textual guard into a security conclusion. Trace producers and callers.

### 3. Classify manually

Assign each reviewed path one disposition:

- `model`: model requests, responses, Realtime events, or derived values.
- `tool`: tool arguments, outputs, MCP data, tool events, or derived values.
- `model+tool`: either class may reach the sink.
- `operational`: demonstrated to contain only non-sensitive SDK metadata.
- `intentional-output`: explicitly user-facing output rather than diagnostics.
- `uncertain`: source tracing is incomplete.

Record evidence in the audit report. The script does not validate or inherit dispositions.

### 4. Fix runtime boundaries

Before changing runtime behavior, use `$implementation-strategy`.

- Check the relevant `_debug.DONT_LOG_MODEL_DATA` and `_debug.DONT_LOG_TOOL_DATA` flags before formatting or inspecting sensitive values.
- Redact mixed model/tool values when either flag disables data logging.
- In redacted mode, emit a fixed message and omit sensitive `args`, `extra`, and `exc_info`.
- Build diagnostic-only context lazily so redacted mode never reads it.
- Preserve useful diagnostics when sensitive-data logging is explicitly enabled.
- Keep logging failure from changing fallback, cleanup, event, rejection, or cancellation behavior.
- For MCP URLs, remove credentials, query parameters, and fragments in diagnostic mode; never use sanitized names as a substitute for fixed redacted messages.

### 5. Prove caller behavior

Add tests at every changed caller boundary. Inspect the complete `LogRecord`, not only rendered text. Test both redacted policies, diagnostic mode, hostile objects, exception chains, and the caller's observable fallback or cleanup behavior as applicable.

### 6. Re-run and close out

Re-run the collector, the manual searches, focused tests, and applicable repository gates. Use `$code-change-verification` for runtime or test changes and `$pr-draft-summary` when required.

Report candidate counts as search coverage only. Lead with confirmed leaks fixed, retained intentional output, reviewed uncertainty, and verification results. Never report a clean collector result as proof that no sensitive logging path exists.