OPA Record
An opa record is a structured log entry that captures a policy check and its result. You set it up by turning on decision logs in your Open Policy Agent engine. Teams use these records to see which rules allowed or blocked an app request. Still, broad permissions often let users run risky queries after the first check passes. The decision log only shows the initial pass, not what the user ran next. How an opa record works in your setup Open Policy Agent checks incoming requests against rules
Gatekeeper / OPA (K8s): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An opa record is a structured log entry that captures a policy check and its result. You set it up by turning on decision logs in your Open Policy Agent engine. Teams use these records to see which rules allowed or blocked an app request. Still, broad permissions often let users run risky queries after the first check passes. The decision log only shows the initial pass, not what the user ran next.
How an opa record works in your setup
Open Policy Agent checks incoming requests against rules written in its policy language. When an app asks for a ruling, it sends a JSON input payload. The engine reads this input, checks its local data, and returns an answer. If you turn on logging, the engine builds an opa record for that event. This record holds the input data, the rule path, and the final output. It also stamps the entry with a unique ID and the exact time.
The engine does not write each record to a remote server right away. Instead, it holds the records in a local buffer in memory for a short time. A background job then bundles several records into one compressed batch. The engine sends this batch to your central log server over an HTTP call. You can also send these records to standard output for local log collectors. This batch process stops network traffic spikes when your apps make many requests.
How teams manage payload data in decision logs
An opa record captures the entire input payload by default. This behavior creates a risk when apps send user secrets or personal data. For example, a payload might hold phone numbers, emails, card numbers, or national IDs. If the engine logs the raw input, those fields land in your log store. Anyone with read permissions on the log server can then find that sensitive data.
To fix this, teams write policy rules that drop or scrub specific fields. Before the engine saves the opa record, it checks your masking rules. You can tell the engine to delete a secret key from the log entry. You can also replace an email or card number with a fixed mask value. This step keeps your audit trail clean while protecting private fields in your logs. Still, writing and testing these log rules takes ongoing work as payloads change.
Gatekeeper / OPA (K8s): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native decision logs solve and what they miss
Decision logs are great for proving that an app checked a rule before acting. Security teams read these records during audits to verify who got into a system. Engineers also use the recorded input payload to test and fix broken policy rules. When a rule blocks a valid user, the log shows the exact input values.
Yet a decision log only sees the JSON metadata that the app chose to send. It does not watch the live database session or command shell that opens next. Once a user passes the check and logs in, the policy engine steps back. It cannot see individual SQL statements, shell commands, or data rows returned in flight. If an engineer runs a destructive query inside an approved session, the engine misses it. Also, decision logs only mask data inside the policy log itself. They do not rewrite phone numbers or card numbers inside live database query results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What data is inside an opa record?
Each record includes a decision ID, a timestamp, the policy path, and the result. It also stores the full input payload unless you write rules to drop fields.
Can Open Policy Agent redact sensitive fields in logs?
Yes, you can write specific rules that remove or overwrite fields before logging occurs. This prevents emails, phone numbers, or secret keys from reaching your central log server.
Do decision logs capture live database queries?
No, the policy engine only logs the payload sent during the policy check itself. It does not track or record the commands a user runs inside an open session.