OPA decision logs turn access control into security telemetry

At a glance

What this is: This is a Wazuh blog post showing how Open Policy Agent decision logs and file integrity monitoring can turn access control activity into searchable security telemetry.

Why it matters: It matters because IAM, PAM, and security teams need visibility into policy decisions and policy changes, not just access outcomes, to detect drift, abuse, and unauthorized privilege paths.

👉 Read Wazuh's guide to analysing Open Policy Agent decision logs with Wazuh

Context

Access control is only as trustworthy as the signals around it. When policy engines make allow or deny decisions, those outcomes can reveal misconfigurations, unauthorized access attempts, and policy tampering, especially when the policy layer sits between applications and the systems they protect.

In this post, the identity angle is not about user login flows but about the control plane for authorisation. OPA evaluates structured context such as role, device posture, method, and IP, which means the resulting logs can support IAM and NHI governance when machine-to-machine requests or service-driven access decisions need auditability.

Key questions

Q: How should security teams monitor policy decisions from OPA in production?

A: Security teams should ingest decision logs into central monitoring, then build detections around repeated denials, unexpected allow paths, and unusual input combinations. The goal is to treat policy output as evidence of identity and access behaviour, not just application plumbing. Correlating those logs with authentication and endpoint telemetry improves triage and reduces blind spots in authorisation review.

Q: Why do policy files need integrity monitoring as part of access governance?

A: Because the policy file is the rulebook that defines who can do what. If it is modified, deleted, or replaced without control, the access boundary changes immediately and may never be visible in application logs alone. FIM creates a reviewable record of those changes, which is essential when policy engines enforce administrative, API, device, or network-based access.

Q: What breaks when authorisation logs are not correlated with policy changes?

A: Investigators lose the ability to tell whether a change in access behaviour came from attacker activity, policy drift, or a legitimate rule update. That can delay containment and lead to false confidence in controls that appear to be working. Correlation is what turns isolated events into a meaningful governance picture.

Q: What is the difference between monitoring access requests and monitoring policy decisions?

A: Monitoring access requests shows what users or workloads tried to do, while monitoring policy decisions shows how the authorisation engine evaluated those requests. Both are needed. Requests reveal intent and abuse patterns, but decisions reveal whether the control layer behaved as expected and whether policy changes altered the approval boundary.

Technical breakdown

How OPA decision logging turns authorisation into telemetry

Open Policy Agent evaluates a structured input document against Rego policy and returns a decision object, usually including allow or deny plus supporting metadata such as reason and risk. When decision logging is enabled, each evaluation becomes a structured record that reflects the request context, the policy path, and the outcome. That matters because a deny event is not just an error response. It is a control signal that can be correlated across users, endpoints, and workloads to identify policy misuse or changing attack patterns.

Practical implication: feed policy decision logs into your monitoring stack and treat repeated denials, unexpected allow paths, and unusual input attributes as security events.

Why file integrity monitoring matters for policy engines

Policy engines do not only expose runtime decisions. They also depend on the integrity of the policy files themselves. If a Rego policy is altered, deleted, or added without oversight, the authorisation boundary changes immediately, often without any application code change. File integrity monitoring closes that blind spot by watching the directory where policy files live and alerting on create, modify, and delete events. In governance terms, this is configuration control for access logic, not just for the servers that host it.

Practical implication: place the policy store under monitored integrity controls so changes to authorisation logic are reviewed before they become effective.

Why access telemetry and policy drift belong in the same detection model

Access control telemetry is most useful when the runtime decision and the policy state are analysed together. A deny spike may indicate abuse, but a simultaneous policy change may indicate the cause. Likewise, a sudden allow pattern can be far more concerning if a policy file was just edited. This is the same logic used in broader security operations: behaviour is only meaningful when it is tied to the control that produced it. For identity programmes, that means access governance and configuration governance cannot be separated.

Practical implication: correlate authorisation logs with policy change events so investigations can distinguish attacker behaviour from control-plane drift.

NHI Mgmt Group analysis

Policy decision logs are becoming part of the identity evidence trail. The important shift in this pattern is that authorisation is no longer a silent yes-or-no control. Every denied request, unexpected risk score, or unusual input attribute can become audit evidence for identity, device, and network context. That is especially relevant where service accounts, APIs, and workload identities drive access decisions. Security teams should treat policy logs as a control record, not just application output.

Access governance now depends on monitoring the policy layer itself. Access control can fail even when the request is correctly evaluated if the policy definition has been altered, weakened, or replaced. This is a governance problem as much as a detection problem, because the boundary of approved access lives in the policy store. Teams need to recognise that file integrity for Rego policies is part of IAM assurance, not a separate operational concern.

Runtime authorisation telemetry helps expose the gap between intended and actual access behaviour. Many identity programmes review entitlements but do not continuously observe authorisation outcomes. That leaves a blind spot when excessive privilege, policy drift, or automated access patterns emerge outside scheduled review cycles. The named concept here is authorisation evidence drift: the distance between what access policy says should happen and what runtime logs prove is happening. Practitioners should use that gap to prioritise monitoring and remediation.

OPA-style policy engines fit best when identity context is explicit. Role, device posture, method, and source IP are all policy inputs, but they only improve governance when the organisation can trust the underlying identity assertions. In practice, that means authorisation telemetry should be paired with strong authentication, well-scoped service identities, and reliable policy ownership. Teams should not confuse structured policy evaluation with complete identity governance.

What this signals

Authorisation telemetry is becoming a governance control, not just an observability stream. As more applications delegate decisions to policy engines, teams need to prove that policy evaluation is both working and changing only through approved processes. That shifts monitoring from the application edge to the authorisation layer itself, which is where policy drift becomes visible.

Authorisation evidence drift is the operational problem this pattern exposes. The further runtime decisions move from what policy owners expect, the harder it becomes to trust access reviews, exception handling, and compliance assertions. For identity programmes, that means access governance must include policy integrity and decision logging, not only entitlement review.

Where workloads, APIs, and service accounts depend on policy engines, teams should treat policy changes as privileged events. That creates a direct bridge to identity governance, because the actor being controlled may be human, machine, or an automated service that only looks benign until the policy boundary shifts.

For practitioners

• Monitor policy decisions as security events Ingest OPA allow and deny decisions into the SIEM or equivalent monitoring platform and create detections for repeated denials, unusual risk values, and access from unexpected roles or paths.
• Protect the policy store with file integrity monitoring Apply FIM to the directory that contains Rego policies so create, modify, and delete activity is alerted and reviewed before the new logic is trusted in production.
• Correlate policy changes with access anomalies Investigate denied or newly allowed requests in the same window as policy edits, because a change in access behaviour can reflect policy tampering rather than user behaviour.
• Tie policy ownership to access governance Assign clear owners for each policy file, require change control for policy updates, and document which identity attributes the policy is allowed to trust.

Key takeaways

• OPA decision logs turn authorisation outcomes into security telemetry that can expose misuse, drift, and policy tampering.
• Monitoring the policy files is as important as monitoring the requests, because the rule set defines the access boundary.
• Identity teams should correlate access decisions with policy changes so governance reflects what the control layer actually did.

Key terms

• Open Policy Agent: Open Policy Agent is a general-purpose policy engine that evaluates structured input against policy rules and returns an allow or deny decision. In practice, it separates authorisation logic from application code, which makes the policy layer easier to manage but also something that must be monitored and protected.
• Decision Logging: Decision logging is the recording of allow and deny outcomes together with the policy context that produced them. It gives security teams evidence for audits, investigations, and recertification, and it helps detect when authorization behaviour changes unexpectedly.
• File Integrity Monitoring: File integrity monitoring is the practice of tracking critical files for unexpected changes in content, permissions, ownership, or metadata. It helps teams spot tampering, drift, and persistence attempts that can undermine identity and security controls. In mature programmes, it is tied to approved baselines and actionable change workflows.
• Authorisation Evidence Drift: Authorisation evidence drift is the gap between the access behaviour policy owners expect and the behaviour runtime logs actually show. It grows when teams review entitlements without continuously observing policy decisions, policy changes, and the context used to make each access judgment.

What's in the full article

Wazuh's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step OPA and Wazuh configuration for logging and ingestion on Ubuntu 24.04
• Sample Rego policy files for admin, API, device, and IP-based access rules
• Custom Wazuh rule examples for OPA decision logs and policy file integrity events
• Dashboard filter steps for reviewing OPA and FIM alerts in the Wazuh console

👉 Wazuh's full post shows the OPA policy examples, agent configuration, and alert rules used in the lab

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader access decisions and telemetry their programmes depend on.