Home / Knowledge hub / Policy as code
Knowledge hub
Policy as code
Writing access rules as versioned, testable code instead of settings clicked by hand.
What it means
Policy as code means writing rules about who may do what as code, kept in version control, reviewed and tested like any other code. Instead of settings that someone clicked in a console, a policy file says which roles can read which resources, and software enforces it.
Tools such as Open Policy Agent use a dedicated policy language and are called by your app or platform to make each decision. The same idea applies to infrastructure rules, deployment checks and application permissions, so long as the rules are written down and run by a machine.
Why it matters
Hand-set permissions drift. No one remembers why a rule exists, changes are not reviewed, and two environments disagree. Written as code, a change has an author, a review and a history, which is what auditors ask for in an access control review.
It also lets you test rules before they ship. A policy can have unit tests for cases such as "a member cannot read another organisation's invoice". Keeping decisions in one place means a fix applies to every service that asks, rather than to one copy of the logic.
How it shows up
You meet it in authorisation services, API gateways, Kubernetes admission control and CI checks that block a deployment. Teams move scattered if statements into a policy and call it from each service. That helps the next change, and the next audit.
It does not make the rules correct, only visible. Mistakes remain: a service that never calls the policy, a policy that is too broad, data fed to the policy that a user can change, and tests that cover only the allowed cases. Test the running app against the policy's intent, and try the denied cases too.
Questions people ask
Policy as code, answered
Is policy as code the same as infrastructure as code?
They are related. Infrastructure as code describes resources. Policy as code describes rules about them, or about who may use them. Many teams use both.
Does it replace role-based access control?
No. It is a way of expressing and enforcing rules, including role-based ones. You can write a role model, or an attribute-based one, as a policy.
Does it remove the risk of broken access control?
No. It makes the rules clear and testable, but the app must call the policy on each request, and give it trustworthy inputs. Missed calls still cause broken access control.
What should we test in a policy?
Both allowed and denied cases, including edge cases such as users with no role, users in two groups, and requests with missing fields.
How do we check the app actually follows the policy?
Send requests as accounts of different levels and compare the results with what the policy says. A mismatch means a route skips the policy or feeds it wrong data.
Related
Terms that sit next to this one
Access control
The rules deciding which person can see or do which thing in your app.
RBAC
Permissions attach to roles, and people are given roles.
ABAC
Permissions decided by attributes like department, location or data label, not just role.
Infrastructure as code
Describing servers and networks in files so they can be reviewed and repeated.
Deny by default
Refusing every request unless a rule explicitly allows it.
Does the app follow the policy you wrote?
We test the running app against the rules you intend, checking what each signed-in account can reach that it should not, and show it with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.