OPA ships with eval, test, check, fmt, inspect, and build commands for policy workflows. Use this 2026 access-control cheat sheet. Read now.
Why Datalog Underpins OPA Access Control
Open Policy Agent expresses authorization rules in a Datalog-derived policy language, which lets you describe who can do what as a set of logical statements rather than tangled conditionals scattered across services. Instead of hardcoding permission checks into each application, you send the request context to OPA and get back a decision. That separation means access rules become data you can version, test, and reason about on their own.
The practical payoff is that the same policy can guard an API gateway, a Kubernetes admission step, or a microservice call, because the input is just structured data and the output is a decision. The command-line tooling exists to make that policy code behave like any other software artifact: something you lint, test, and package before it ever evaluates a real request.
The Core Commands and What Each Does
OPA ships a small set of subcommands that cover the full policy lifecycle. Learning what each one is for keeps you from reaching for the wrong tool or wiring an ad hoc script where a built-in already exists.
- eval — run a policy against sample input and inspect the decision; your primary tool for exploring behavior and debugging why a request was allowed or denied.
- test — execute rules written as test cases so you can assert expected allow/deny outcomes and catch regressions.
- check — statically validate that policy files parse and type-check, surfacing errors before evaluation.
- fmt — apply canonical formatting so diffs stay readable and style debates disappear.
- inspect — examine the contents and metadata of a policy bundle without loading it into a running agent.
- build — compile policies and their data into a distributable bundle for deployment.
A Practical Workflow for Policy Changes
Treat a policy change like a code change. Start by writing or editing the rule, then run fmt to normalize it and check to confirm it parses and type-checks. Both are fast and catch mistakes before you spend time on logic. From there, use eval with representative inputs to confirm the decision matches your intent for the cases you care about, including the denials that matter most.
Once the behavior looks right, encode those expectations as tests and run test so they stay verified as the policy grows. When everything passes, use build to produce a bundle and inspect to confirm the bundle holds the files and data you expect. Wiring check and test into continuous integration means a broken or overly permissive rule fails the pipeline rather than reaching production.
Habits That Keep Access Control Trustworthy
The commands only help if you build habits around them. Test the negative cases deliberately: it is easy to prove that an authorized user is allowed and forget to prove that an unauthorized one is denied. Keep policies and their test data close together in version control so a rule change and its expected outcomes move as one unit.
Because policy is decoupled from application code, a small mistake can silently widen access across everything the policy guards. Running check, test, and a bundle inspect before every deploy turns that risk into a caught error. Used together, these commands make authorization something you can change with confidence instead of something you are afraid to touch.