Policy-as-Code (PaC)

Policies are written as declarative statements of desired state, not procedural scripts. Using languages like Rego (Open Policy Agent) or Sentinel, engineers define what is permitted, not how to enforce it. The policy engine evaluates logical rules against input data (e.g., API requests, resource configurations) and returns an allow/deny decision.

• Separates policy logic from application code
• Enables formal verification of policy correctness
• Example: allow { input.purpose == "model_training" } denies any request where the purpose field deviates

PaC policies are stored in Git repositories alongside application code, treated with the same rigor as software artifacts. This enables:

• Pull request workflows for policy changes with mandatory peer review
• Immutable audit trails showing who changed which policy, when, and why
• Rollback capabilities to instantly revert to a known-good policy state
• Branching strategies for testing policy changes in staging environments before production enforcement

The Policy Decision Point (PDP) is a stateless service that evaluates incoming requests against loaded policies in real time. It receives structured input (typically JSON) from a Policy Enforcement Point (PEP) and returns a binary decision with optional context.

• Latency is typically sub-millisecond for pre-compiled Rego policies
• Decisions are deterministic: identical inputs always produce identical outputs
• The PDP can be embedded as a library, deployed as a sidecar, or run as an external service

PaC cleanly separates policy decision from policy enforcement. The PEP intercepts requests at the infrastructure layer (API gateway, service mesh, database proxy) and offloads the authorization decision to the PDP. This decoupling means:

• Enforcement points can be added without modifying application code
• A single policy can govern multiple heterogeneous systems (Kubernetes, SQL databases, REST APIs)
• Policy changes propagate instantly across all enforcement points without redeployment

PaC enables shift-left compliance by integrating policy evaluation into CI/CD pipelines. Every infrastructure-as-code change, configuration update, or deployment is automatically validated against the current policy set before reaching production.

• Pre-deployment gates block non-compliant changes at the pull request stage
• Drift detection continuously scans running systems and flags deviations from policy-defined state
• Remediation-as-code can automatically correct drift by reapplying the desired state

Every policy decision generates a structured, immutable log entry containing the full input context, the evaluated policy version, and the resulting decision. This provides:

• Non-repudiation: cryptographic proof that a specific policy version produced a specific outcome
• Forensic replay: auditors can reconstruct historical decisions by replaying logged inputs against historical policy versions
• Purpose limitation evidence: logs prove that data access was gated by explicit purpose checks, satisfying regulatory requirements under the EU AI Act and GDPR

The brain of a policy enforcement architecture. The PDP evaluates incoming authorization requests against the machine-readable rules written in languages like Rego or Sentinel. It ingests attributes about the user, resource, and environment, then computes an allow or deny decision. In a PaC pipeline, the PDP is the engine that executes the policy logic, separating decision-making from enforcement.

The gatekeeper that intercepts every data access request or API call. The PEP is the architectural component that sits in the data path, queries the PDP for a decision, and then physically allows or blocks the operation. In a PaC context, the PEP is often implemented as a sidecar proxy, API gateway, or database driver that cannot be bypassed, ensuring policy is not just defined but mechanically enforced.

The logical paradigm that powers dynamic PaC. Unlike static Role-Based Access Control (RBAC), ABAC evaluates real-time attributes:

• User attributes: clearance level, department, current location
• Resource attributes: data classification, purpose tag, retention period
• Action attributes: read, train, export
• Environmental attributes: time of day, network zone, device posture This granularity allows PaC to enforce rules like 'data tagged purpose=marketing cannot be accessed by department=engineering.'

The audit backbone required to verify PaC effectiveness. Data lineage tracks the complete journey of a dataset—from ingestion through every transformation and access event—creating an immutable map of provenance. When a PaC rule restricts data to a specific purpose, lineage provides the forensic evidence that the restriction held. It answers the auditor's question: 'Did this data ever leave its authorized processing boundary?'

A structural control that PaC automates. Information barriers prevent the flow of data between departments with conflicting interests (e.g., trading desk vs. advisory). PaC codifies these barriers as executable rules:

• deny access if user.department == 'trading' and resource.origin == 'advisory'
• deny training if dataset.purpose != model.approved_purpose This replaces manual, error-prone Chinese walls with deterministic, auditable enforcement.