Data Exposure Alerts: Issues When Secrets or Personal Data Reach Your Logs

Last verified on Nov 10, 2026.

A secret in your logs is a copy of a secret that lives wherever your logs go: a vendor, a backup, a chat paste from last week. You set nothing up. The Sazabi agent sets up sensors for your project and maintains them over time. Sensors are standing questions about your logs, and one asks whether secrets or personal data are being written to them.

The live signal

Secrets or personal data in logs asks: "Is a secret or personal data being written to a log line?" It watches for:

• Tokens and API keys, such as a credential printed inside an error message.
• Email addresses.
• ID numbers.

This is the whole of what feeds the data exposure category today. Scanning code for risky changes, matching new advisories to your dependencies and watching for compromised packages are not covered. Everything on this page concerns data that has already reached a log line.

Example: a key in an error message

This is an example, not output from a real project. The service name and credential are made up. After a release, your billing-sync service starts logging the full request when a vendor call fails:

2026-11-08T16:22:09Z ERROR billing-sync vendor call failed status=401 request="GET /v2/invoices" headers={"Authorization": "Bearer live_k3y_not_a_real_value_8f2a"}
2026-11-08T16:22:41Z ERROR billing-sync vendor call failed status=401 request="GET /v2/invoices" headers={"Authorization": "Bearer live_k3y_not_a_real_value_8f2a"}

The sensor flags the first appearance. The agent investigates: which service wrote it, which release began doing so, how many lines carry it and whether the value matches a credential that is also used elsewhere.

The issue might be named "Bearer token written to billing-sync error logs" with high severity. Its analysis tells you the first occurrence and the likely cause, a new error handler that logs request headers. The next step is your own: rotate the key.

Nothing for you to define

Every system can leak a secret into a log, whatever it does. That is why there is no list of services, fields or secret formats for you to write. The agent sets it up, and the issue names the service and the release.

How you find out

An issue opens in the inbox, and the Issue triggered notification follows your delivery rules. Because a leak can sit in the logs for weeks while nobody looks, many teams send these to a security channel in Slack or Microsoft Teams, matched by severity or by the owning team of the component.

From the issue you can ask the agent follow-up questions in the thread, hand the code fix to a coding agent with sazabi issues agent-prompt, then mark it resolved. If the same value appears again while the issue is open, the new lines fold into it. If you resolved the issue and the leak resumes, a new issue opens, which is a useful check that your fix actually landed.

What you need

Logs from the services you want checked, flowing into Sazabi through any supported integration. The sensor can only flag what arrives, so confirm your sources on the Intake page.

What it does not cover

• Secrets that sit in code, config files or a container image and never reach a log.
• Redaction. Sazabi tells you the data is there; it does not rewrite your past logs.
• A vulnerable dependency or a dangerous code path. The guide on exposure management covers those by hand, and neither has a live signal here today.
• Data leaving by another route. For large exports to one actor, see suspicious access.

Related reading: the glossary entries for structured logging and log retention explain why a logged secret lingers. For billing, see pricing.