Policy as Code

How Policy as Code Works

Many technical systems have rules.

They can, for example, state:

Production systems must not be directly administrable from the Internet.

or:

Application components must not access the database directly.

or:

Direct output to stdout is not permitted in this project.

As long as such rules exist only in documentation, meetings, or the minds of the people involved, humans must check compliance with them again for every relevant change.
Policy as Code attempts to formalize suitable rules so that this check can be performed at least partially by machines.

From Statement to Verifiable Rule

Not every understandable rule is already machine-verifiable.

The statement:

Our servers must be securely configured.

is understandable to humans.
For an automated check, however, it is too vague.
First, it would have to be described which observable properties are understood as “securely configured.”

This could result in more concrete rules such as:

SSH password authentication is disabled.

Root login via SSH is disabled.

Service X may listen only on the internal interface.

Only when it is sufficiently clear which state is permitted or not permitted can a machine-readable Policy be created from it.

A Policy Needs Information

A Policy can evaluate only properties for which suitable information is available to it.

Suppose the rule is:

Production data must not be stored on development systems.

The check then requires, among other things, information about:

Which data is production data?
Which systems are development systems?
Where is the relevant data actually stored?

If this information is missing, even a formally perfect Policy cannot reliably check the rule.
Policy as Code therefore consists not only of the Policy itself.
The quality and meaning of its input data also determine what conclusion the evaluation permits.

A Decision Emerges from Rule and State

Simplified, a Policy evaluation can look like this:

Policy
   +
observed state
   ↓
evaluation
   ↓
result

For example:

Policy:
frontend must not use database directly

State:
frontend → database

Result:
rule violated

Or:

Policy:
SSH password authentication must be disabled

State:
PasswordAuthentication no

Result:
rule satisfied

It is crucial that the Policy does not confuse the desired state with the actual state.
It needs information about the system that is actually being checked.

Not Everything Is True or False

A simple Policy can have two results:

satisfied
violated

In real systems, however, another state can be important:

cannot be evaluated

For example, a Policy requires:

Service X may only be reachable internally.

However, the checking tool knows only the local configuration of the service and not the upstream firewall or network rules.

Then the statement:

rule satisfied

may be stronger than the available evidence permits.
A meaningful checking process must therefore be able to distinguish between:

rule satisfied
rule violated
not sufficiently known

The exact technical representation of such states depends on the Policy system used.
The underlying problem, however, remains the same.

Policy and Enforcement Are Not the Same

A Policy can identify a deviation.
What happens afterward is another decision.

Possible responses include:

log

generate warning

request manual review

block deployment

deny access

document exception

This allows two steps to be distinguished:

Evaluation:
Does the state comply with the Policy?

Enforcement:
What consequence does the result have?

Not every Policy has to be enforced automatically.

Automatic Remediation Is Something Else Again

Another level would be:

deviation detected
        ↓
system changes state automatically
        ↓
check Policy again

For example, a system could automatically revert an unauthorized configuration.
This can be useful for certain clearly defined cases.
But it is not a necessary part of Policy as Code.

Between:

We can detect the deviation.

and:

We automatically know how to respond to this deviation.

there is a substantial difference.

Exceptions Belong to the Rule System

Not every deviation has to be permanently prohibited.

An architecture rule could, for example, specify:

Component A must not access database B directly.

For a migration, this access is temporarily necessary.
A possible exception could therefore contain additional conditions:

Exception:
Component A → database B

Reason:
data migration

valid until:
2026-10-31

responsible:
migration team

This does not secretly circumvent the rule.
Instead, the exception itself becomes an explicit part of the rule system and its evaluation.
After the exception expires, it can be checked again whether it is still needed.

Policies Can Be Versioned

Machine-readable Policies can be versioned like other technical artifacts.

This makes it possible to trace:

Which rule applied at which point in time?
When was it changed?
Why was it changed?
Which systems were affected by it?

This is particularly important when requirements change over time.
A system can be compliant today and violate a newly introduced Policy tomorrow even though nothing in the system itself has changed.
The evaluation of a state therefore also depends on the currently valid version of the rules.

A Policy Can Itself Be Faulty

Machine-readable rules can contain errors.

An incorrectly formulated Policy can:

• mark valid states as errors
• overlook actual violations
• make false assumptions about input data
• fail to account for unexpected special cases
• produce incorrect results because of a rule change

Policies must therefore themselves be reviewed and tested.

A test could, for example, contain known states:

Case A:
known valid
→ Policy must allow

Case B:
known invalid
→ Policy must report violation

Case C:
necessary information missing
→ Policy must not produce an unjustified approval

Policy as Code therefore does not move rules outside the quality assurance problem.
It makes the rules themselves part of the technical system.

Policies and Architecture Conformance

Architecture Conformance examines whether an actual system complies with its architecture specifications.
Policy as Code can be one way to formulate certain architecture specifications in machine-readable form.

From:

All output must go through the central output component.

a verifiable rule can, for example, be created.
A tool then examines the source code and provides information about direct output.
The Policy evaluates this information.

This results in:

architecture decision
        ↓
formalized Policy
        ↓
information about actual state
        ↓
Policy evaluation
        ↓
conformance / deviation

Not every architecture rule is suitable for this.
But rules that can be mapped unambiguously to observable properties can be checked repeatedly.

Policies and AI-Generated Results

Policy as Code becomes particularly interesting when results are no longer produced exclusively by humans.

A Language Model can receive a rule as context:

Never use direct stdout output.

This may improve the probability that the rule is followed.
It does not, however, prove compliance with it.

After generation, an independent check can therefore be performed:

AI generates code
      ↓
Policy checks code
      ↓
rule satisfied / violated

The rule thereby becomes more than just an instruction for the probabilistic system.

Compliance with it additionally becomes a verifiable property of its output.

Policy as Code Is Not AI-Specific

The approach exists independently of generative AI.

Typical areas of use include:

• access control
• infrastructure configuration
• cloud resources
• security requirements
• software architecture
• deployment rules
• compliance checks

AI systems merely create additional use cases.
Especially with automatically generated changes, an independent machine-readable check can be useful.
The underlying principle remains the same:

A rule is described so that compliance with it can be evaluated repeatedly based on suitable information.

Rules Have a Scope

A Policy is not automatically universal.

A rule may, for example, apply only:

to production systems

or:

to module A

or:

from version 3 onward

or:

during normal operation

The scope is therefore part of the meaning of the rule.
A formally correct Policy applied to the wrong area of a system can produce a formally correct but substantively useless result.

Even with machine-readable rules, the question therefore remains important:

Where and under what conditions does this rule apply?

Why Policy as Code Has Practical Effects

• Rules become repeatedly verifiable: Suitable requirements do not have to be checked exclusively manually.
• Rules can be versioned: Changes to requirements become traceable.
• Evaluation and enforcement can be separated: A detected deviation does not automatically have to be blocked.
• Exceptions can become explicit: Deviations do not have to exist secretly outside the rule system.
• Automated changes can be checked independently: AI-generated code can also be subject to the same rules.
• Architecture decisions can remain closer to the implementation: Certain specifications can be checked directly against the actual state.
• Unknowns can remain visible: Missing information does not necessarily have to be converted into an apparently unambiguous decision.
• Policies themselves become verifiable: Machine-readable rules can be tested and developed further.

Typical Example

A project has the architecture rule:

Direct command-line output from domain components is not permitted.

The rule is formalized.
An analysis tool reports for a change:

file: order.lua
line: 184
operation: direct_stdout

The Policy evaluates this state:

rule: no_direct_stdout
result: violation

This initially establishes only:

The observed change does not comply with the applicable rule.

The project configuration then specifies:

local development:
warning

Pull Request:
review required

Release:
block

For a special diagnostic case, there is also a documented exception.
The same Policy can therefore have different consequences in different situations without requiring the actual architecture rule to be changed.

Distinction

• Policy as Code refers to the machine-readable formalization of rules and policies so that they can be evaluated automatically.
• Architecture Conformance describes the conformance between the actual system and architecture specifications. Policy as Code can be a tool for such checks.
• Verification and Validation are more general procedures for examining requirements and intended use. Policy checks can be part of verification.
• Monitoring or Observability provide information about states and behavior. A Policy can evaluate such information, but is not the same as collecting it.
• Enforcement refers to enforcing a decision. A Policy can provide the basis for this without automatic enforcement being a necessary part of Policy as Code.

Further Reading

Related Concepts

→ Architecture Conformance
→ System Architecture
→ Verification and Validation
→ Observability
→ Resilience