Secrets in Logs Alerts: An Issue When a Key or Personal Data Is Logged

Last verified on Nov 10, 2026.

The leak nobody reviews

Logs are written by code that nobody expects to be sensitive. A debug line prints the whole request. An error handler includes the connection string. A retry log echoes the Authorization header. The line sits in storage, gets copied to other tools and is readable by everyone with log access.

The Sazabi agent sets up sensors for your project and maintains them over time, and secrets or personal data showing up in logs is one of the problems they watch for. You set nothing up, with no rule to write and no field list to maintain.

What counts

The question the sensor asks is plain: has anything in these logs that looks like a credential or personal data been written out? In practice that covers:

• API keys and signing secrets printed in a message or an exception.
• Tokens, such as a bearer token copied into a log line from a request dump.
• Email addresses inside a request or user object that was logged whole.
• ID numbers that ended up in a message or a field.

One occurrence is already a problem, so this is not a question about trends. A line like this should never appear at all.

Example: a token inside an error message

This is an example, not output from a real project. A service named webhook-relay logs failures from a partner callback. After a refactor, the error handler includes the outgoing request headers:

2026-11-08T16:41:09Z ERROR webhook-relay delivery failed status=502 url=https://partner.example/hook headers={"Authorization":"Bearer sk_live_REDACTED_EXAMPLE","Content-Type":"application/json"}
2026-11-08T16:41:39Z ERROR webhook-relay delivery failed status=502 url=https://partner.example/hook headers={"Authorization":"Bearer sk_live_REDACTED_EXAMPLE","Content-Type":"application/json"}

The key in these lines is a placeholder. A real one would be a working credential. The first line is enough to fire. Sazabi investigates and opens an issue. An example of what it could say:

• Name: Live API key written to webhook-relay error logs
• Description: Since the 16
  deploy, failed deliveries print the Authorization header in full. The header holds a live key, and the line is repeating on every retry.
• Severity: critical

The agent analysis points at the changed error handler and gives the first and latest affected lines. The evidence is the log lines themselves, so you can see what was exposed without a separate search. What the issue cannot do is take the secret back. The next step is on your side: rotate the key, ship a fix that stops logging headers, and decide what to do with the stored lines.

How you get told

An issue triggers an Issue triggered notification. You can send it to in-app, email, Slack DM or SMS, and to shared Slack or Microsoft Teams channels with delivery rules. A security team can have a rule that routes critical issues to its own channel regardless of which service logged the line, since rules match severity, component or owning team.

In the issue you can ask the agent follow-up questions, such as which services logged lines of the same kind. You can also run sazabi issues agent-prompt and give the output to a coding agent so it patches the logging call. Recurrences fold into an open or ignored issue, so a leaking line that fires thousands of times produces one issue, not thousands.

What it needs

Logs have to reach Sazabi for it to see them. That is the only requirement. They can come from a cloud platform such as AWS, an OpenTelemetry exporter, or any source on the integrations list. It reads what you send, so what you drop or scrub before shipping is not questioned. Check scrubbing at the source, since structured logging with explicit fields makes it easy to leave sensitive ones out.

What it does not cover

• Secrets and personal data that never reach your logs, such as ones sitting in a database or a repository.
• Sensitive values in a format nothing in the logs resembles, such as an internal customer number with no recognizable shape.
• Cleanup. Sazabi reports the exposure; it does not delete, mask or rotate anything.
• A compliance verdict. An issue is evidence of a leak, not an audit of your data handling.

Sazabi also does not scan source code. A hard-coded key in a repository is outside this detection.

Related

Issues Sazabi detects are metered, so check pricing. How long exposed lines stay readable depends on your log retention. A brand-new kind of error that appears after a deploy is a separate detection: see new error detection.

Hostile input aimed at your endpoints is attack payloads.