Give production log access by role and need, not to everyone on engineering. Restrict read rights, review them on a schedule, and record who searched what. The OWASP Logging Cheat Sheet says all access to logs must be recorded and monitored, and that read privileges should be restricted and periodically reviewed.
Why log access deserves a policy
Logs are copied everywhere: the application, the collector, the search tool, dashboards, exports and backups. Even careful teams end up with some personal data, internal addresses and error details in them. If everyone can query everything, the log store becomes the easiest place to read customer data.
The same cheat sheet adds that logs should not be exposed in web accessible locations, and that data from other trust zones should be treated as untrusted. Access control is one part of a wider set of protections.
OWASP Top 10 A09 also lists, as a failure, logging or alerting details that are visible to users or attackers. Error pages and public dashboards are the usual culprits.
A role table to start from
| Role | Typical need | Suggested access |
|---|---|---|
| On call engineer | Debug live incidents | Read application and error logs, time limited elevation for wider data |
| Developer | Debug features | Staging logs by default, production through a request |
| Security analyst | Investigate events | Read security and audit streams |
| Support agent | Trace a customer issue | A filtered view for one customer, no raw access |
| Auditor | Evidence review | Read only exports of the audit stream |
| Administrator of the log tool | Run the platform | Manage the system, no routine reading of content |
| Contractors and vendors | Specific project | Time boxed access to one source |
Separate duties where you can. The people who administer the log platform should not be the only ones who can delete from it.
Steps to set it up
- Inventory every place logs live, including exports and shared drives.
- Define streams by sensitivity: general application, security, audit and sensitive diagnostic.
- Map each stream to roles and enforce through groups in your identity provider, not named individuals.
- Require single sign on and multi factor authentication for the log tool.
- Turn on search and export auditing in the tool, and send that audit log to a place the same people cannot edit.
- Review membership every quarter and remove leavers and role changers the same day.
- Prefer time limited elevation, with a ticket reference, for broad production queries.
What to alert on
- A user exporting a large volume of logs.
- Queries for terms such as password, token or specific customer identifiers.
- Access from a new location or device.
- New administrators added to the log platform.
- Retention or deletion settings changed.
These are privileged actions, so apply the same thinking as in the admin actions checklist.
Quick check
Should developers read production logs?
Often yes for debugging, but through a controlled path: narrow scope, time limit and recorded searches, with sensitive streams kept for fewer people.
Does redaction remove the need for access control?
No. Redaction reduces what can leak, but redaction is imperfect. Keep both.
Safeguard's agent identity and policy controls follow the same least privilege idea for automated actors. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
