logging-security

Logging Security

Rules (for AI agents)

ALWAYS

• Decide what is safe to log at the call site, and log a reference rather than a value: an id, a hash, a type, a count. A redactor is the last net, not the design — it matches field names and known patterns, so it cannot see personal data sitting inside an assembled string. A formatted notification body, a templated message, an exception with interpolated arguments: the name and the address are in the prose, in no named field, matching no pattern. Nothing downstream will catch that.
• Run a redactor at the sink anyway, for the cases the call site missed: credential-shaped values, Authorization and Cookie headers, query strings carrying tokens, and the personal-data patterns in rules/redaction_patterns.json. secret-detection owns which literals count as a credential; this rule is that the redactor exists and runs before anything leaves the process.
• Log in a structured format (JSON or logfmt) with stable field names — timestamp, service, version, level, trace_id, span_id, request_id, event, and user_id when there is an authenticated one. Structure is what makes redaction, retention, and access control expressible per field instead of per line.
• Neutralize user-controlled strings before they enter a log record. Line injection (CWE-117) is the classic case — a \n or \r lets an attacker forge a whole record — but structured logging moves the problem: a value that parses as JSON can inject fields into the ingested document, and ANSI escape sequences (\x1b[) are interpreted by the terminal of whoever reads the log. Encode the value; do not concatenate it into the line.
• Record security-relevant events as immutable audit records: authentication success and failure, MFA challenges, password and role changes, permission grants and revocations, data export, administrative action. These carry longer retention and stricter access than operational logs, and they are the reason failed logins must keep being written even when someone calls them noise.
• Treat read access to the log store as access to the data inside it. A centralized store aggregates every tenant's records, so grant it like production data access — named principals, reviewed, audited — not like an observability convenience handed to everyone who might want to debug something.
• Set retention per data category — short for debug, long for audit — and make it executed, not declared. A retention or deletion policy that no job enforces looks identical to one that works, right up to the point someone asks for evidence.
• Alert on the log pipeline itself: a service that stops logging, and volume that departs sharply from its own baseline in either direction. Calibrate the threshold against that service's normal traffic rather than a fixed multiple — a job that runs hourly and a request path have nothing in common.