What Is Sensitive Logging?

What Is Sensitive Logging?

Sensitive logging is a security failure where an AI application records secrets, personal data, prompts, retrieved context, tool payloads, or model outputs in logs, traces, debug streams, or audit stores. It belongs to the security family because the data may be stored longer, viewed by broader teams, or exported to third-party observability systems. The issue shows up in eval pipelines and production traces. FutureAGI anchors it to eval:SensitiveLoggingDetector, so engineers can catch CWE-532-style logging before sensitive records spread.

Why sensitive logging matters in production LLM and agent systems

The concrete failure is durable disclosure. A support agent logs raw CRM records while composing an answer. A RAG pipeline writes retrieved chunks containing medical notes into a debug trace. A coding agent stores tool arguments with API keys after a failed deployment step. The user may never see the secret in the chat UI, but the secret now exists in a log index, trace warehouse, alert payload, or customer support export.

Developers see this as noisy local debug statements, verbose request dumps, or helper functions that log entire prompt objects. SREs inherit it when log sinks become regulated data stores with retention, deletion, and access-control requirements. Compliance teams need to prove that HIPAA, SOC 2, GDPR, and internal security policies are not violated by observability data. End users feel it through account resets, breach notices, and loss of trust.

Symptoms include redaction spikes after a new tool connector, repeated account IDs in trace attributes, tokenized prompt blobs in error logs, and audit records that include full request bodies. Agentic systems make the failure harder because each step can introduce fresh data: memory lookup, retrieval, browser action, API tool, model retry, or agent handoff. A single safe input does not make the whole trajectory safe.

How FutureAGI handles sensitive logging

FutureAGI handles sensitive logging as eval:SensitiveLoggingDetector, with the exact evaluator class SensitiveLoggingDetector from the fi.evals inventory. In a release workflow, an engineer scans application code and eval fixtures for logging statements that include secrets, raw prompt payloads, tool arguments, retrieved documents, or model responses. The metric to watch is SensitiveLoggingDetector fail rate by service, repo path, route, and release candidate.

A real example is a LangChain support agent instrumented through traceAI-langchain. The route support-claims-agent calls a billing tool, retrieves policy context, and writes a structured trace. The risky field is not only the final answer. It can be the tool argument, retrieved chunk, exception message, or trace attribute attached to the span. If SensitiveLoggingDetector flags a code path that logs customer_record or tool_result, the engineer removes the raw object from the log, keeps the trace_id, and stores only a hashed customer identifier plus an error code.

FutureAGI’s approach is to connect static security detection with production trace review. Unlike a Semgrep-only scan, which can find unsafe logging patterns but may not know which LLM route or trace store receives them, the FutureAGI workflow ties the finding to the eval run, trace sample, route owner, and guard action. If findings spike after a connector launch, the next action is specific: fail the release gate, tighten the logging helper, add a regression fixture, or require a post-guardrail redaction check before trace export.

How to measure or detect sensitive logging

Measure sensitive logging as both a code risk and an observability-data risk:

• SensitiveLoggingDetector fail rate - percentage of scanned files, eval fixtures, or release candidates with CWE-532-style findings.
• Raw payload presence - sampled traces should not contain full prompts, secrets, API keys, customer records, or unmasked tool results.
• Trace field review - inspect trace_id, route, span name, gen_ai.request.model, and llm.token_count.prompt without storing sensitive prompt text.
• Redaction effectiveness - compare sensitive strings found before and after masking in logs, trace exports, and audit records.
• Incident proxy - count secrets rotated, privacy tickets, access reviews, and log-deletion requests per release.

from fi.evals import SensitiveLoggingDetector

detector = SensitiveLoggingDetector()
result = detector.evaluate(code=source_code)
print(result.score, result.reason)

For runtime monitoring, sample high-risk routes first: healthcare, finance, identity, support exports, admin tools, and agent workflows with external API calls. Alert when raw secrets appear in shared logs, when trace payload size jumps after a prompt or tool change, or when a service logs full request bodies on exception paths.

Common mistakes

These mistakes usually appear when teams treat observability data as harmless because it is internal. The risky pattern is convenience logging: a developer keeps the fastest context for debugging, then forgets that logs outlive the request.

• Logging whole prompt objects. System prompts, user inputs, retrieved chunks, and tool results often travel together inside one serialized object.
• Masking responses but not traces. The user-facing answer can be clean while the trace store still contains the sensitive payload.
• Keeping verbose debug logs in production. Temporary exception logging often becomes the long-lived path that stores raw credentials or customer records.
• Relying only on log sink filters. Once sensitive data reaches Datadog, CloudWatch, or a warehouse, access control and deletion become harder.
• Dropping all context. Replace raw values with stable hashes, field names, error codes, and trace_id so incidents remain debuggable.