AI Coding Agents
Security
Log redaction for agent-generated changes
September 26, 2026 - 2 minute read
Log redaction fails when a change removes one obvious token but leaves the same value in an error object, URL, trace attribute, or serialized request body. Coding agents can trace those paths and implement a bounded fix. Reviewers still need proof that sensitive data is gone and operational context remains.
The OWASP Logging Cheat Sheet identifies data that should usually be removed, masked, hashed, or encrypted before it reaches logs. Treat that list as a starting point, then apply the organization's own data classification and retention rules.
Build a log redaction inventory
Start with the reported exposure and follow the value from input to every logging sink. Include application logs, exception handlers, audit events, traces, metrics labels, browser telemetry, and CI artifacts. Structured logging can duplicate a value across a message and attached fields.
Give the agent representative test values rather than real credentials or personal data. Name the allowed output for each field. An account identifier might be safe as a stable opaque token, while an authorization header should be removed completely. Do not let the task invent policy from field names alone.
Factory's Droid Exec supports a constrained repository task and structured artifacts. Use it against sanitized fixtures, limit tool access, and keep production log stores outside the execution boundary.
Include third-party SDKs in the inventory. An HTTP client or error reporter may capture headers and payload fragments without an explicit application log statement.
Test redaction at the final sink
Unit-test the redaction function, then capture the final emitted record. A formatter, exporter, or error serializer may add fields after the first filter runs. Exercise success, validation failure, downstream timeout, and unexpected exception paths because sensitive values often appear only in failure logs.
OpenTelemetry's guidance for handling sensitive data recommends controls at instrumentation and collector layers. Test both when the system uses a collector. A collector processor can provide a backstop, but source-level minimization reduces the number of places that ever receive the value.
Use canary strings in fixtures and scan captured logs, traces, and test artifacts for exact and encoded forms. Also assert that the event name, safe identifiers, error class, and correlation fields remain. A redaction change that removes all diagnostic value creates pressure to bypass it during the next incident.
Make log redaction review repeatable
The pull request should identify the sensitive field, every sink checked, the chosen transformation, and tests for direct and nested values. Include a retention or deletion follow-up when earlier records may already contain the data. Code changes cannot remove historical copies by themselves.
Factory's automated security review analyzes pull requests for realistic exploit paths and data exposure. Keep deterministic canary tests alongside that review so future logging refactors fail before the same field returns.
Separate application diagnostics from immutable audit events. Apply the approved policy to each, and involve the security or privacy owner when requirements conflict. The coding agent should implement and verify the decision rather than decide which regulated data the organization may retain.
Further reading
Talk with Factory
Discuss your team’s software development, privacy, or deployment requirements.
