Policy-as-Code
Governance and authorization rules expressed as executable, version-controlled, unit-tested code evaluated at runtime per request — the dynamic policy layer above static IAM.
Also known as: policy-as-code, policy as code, OPA, Open Policy Agent, Rego, AWS Cedar, Amazon Verified Permissions, HashiCorp Sentinel, Kyverno, OPA Gatekeeper, admission controller, policy engine
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Governing AI in the Cloud: A Practical Guide for Architects Dave Ward · 2026-06-15 | Policy-as-code | Governance rules expressed as executable, version-controlled, testable code (OPA/Rego, AWS Cedar, HashiCorp Sentinel; Kyverno/OPA-Gatekeeper for admission control) that evaluate contextual conditions IAM cannot express — data age, model-registration status, environment, break-glass — at runtime, per request, and are unit-tested in CI/CD like application code. |
| Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core Willem Berroubache · 2026-07-23 | Policy-as-code (reviewer's safety layer) | Safety constraints expressed as version-controlled, independently testable, deterministic rules (OPA/Rego) evaluated by the reviewer agent against a separately versioned data/thresholds document — explicitly not reasoning an LLM performs at runtime from a prompt. |
Documents (13)
- AI Development Patterns Paul Duvall · 2026-10-08 source ↗ Reader 🖥️
Organizations should adopt this catalog's AI-development patterns selectively and in an order diagnosed from their own team size, project type, and technology stack — not uniformly or in catalog order — because the coordination problems a solo developer needs to solve (rapid iteration, tool-matching) are categorically different from, and the patterns designed for them can actively mismatch, what a two-pizza team or a multi-team organization needs (parallel-agent isolation and conflict resolution, cross-team traceability, automated review of agent output at volume). - Presentation: APIs for Agents: Rethinking API Programs in the MCP Era Jim Gough, Andreea Niculcea · 2026-09-23 Reader 🖥️
As agent protocols (MCP, then A2A, then whatever comes next) reshape how consumers reach enterprise systems, Morgan Stanley argues platforms should keep APIs as the stable, governed foundation and use Architecture-as-Code (CALM) to encode, version, and automatically enforce security/governance controls and deployment gates across every protocol adapter built on top — so the organization can adopt new interaction protocols quickly, and evolve already-deployed services at scale, without sacrificing safety or consistency. - Beyond Zero: Google Publishes Successor to BeyondCorp Renato Losio · 2026-09-05 source ↗ Reader 🖥️
Google's newly published Beyond Zero model proposes extending Zero Trust from static, application-level, human-speed access control to continuous, resource- and action-level authorization combining static policy with dynamic AI-driven decisions for both humans and AI agents — an aspirational architecture that early practitioner and community reaction meets with skepticism about its maturity, complexity, and the wisdom of non-deterministic access controls. - Cloudflare WriteGuard Brings Fine-Grained Security Controls for MCP Servers Sergio De Simone · 2026-08-18 source ↗ Reader 🖥️
A centralized policy, attribution, and auditing layer sitting behind a shared MCP portal can safely upgrade AI agents from read-only to fine-grained, tool-specific write access without requiring per-server code changes or a separate agent-identity system. - Terraform Introduces tfpolicy, an HCL-based Policy-as-Code Framework Sergio De Simone · 2026-07-29 source ↗ Reader 🖥️
HashiCorp's tfpolicy replaces the separate policy-as-code layer (Sentinel, OPA) with an HCL-native framework embedded directly in Terraform's own workflow, enabling relationship-aware, pre- and post-deployment governance without a second policy language or tool. - An Evolutionary Architecture Pattern for Managing AI's Pace of Change Joe Price, Branimir Đurek, Pavlos Migkiros, Trevor Dearham · 2026-07-27 source ↗ Reader 🖥️
Because AI capabilities, protocols, and threats now change faster than enterprise systems can safely absorb — a gap the authors treat as permanent rather than a phase to wait out — organizations should deliberately concentrate the fastest-moving AI concerns (model routing, identity, action policy, segmentation, content guarding, and audit) into one architectural seam, the AI gateway, so the rest of the enterprise can remain stable, and should build that seam proactively rather than at the higher cost of building it after an incident forces the issue. - Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI Jörg Schad · 2026-07-24 source ↗ Reader 🖥️
To make enterprise data safely and scalably consumable by autonomous AI agents, organizations must re-architect their data as domain-owned, containerized "autonomous data products" — self-contained units with a standardized lifecycle, multi-modal output ports, and centrally-enforced but independently-authored policies — rather than continuing to bolt point solutions onto today's fragmented, storage-centric "data hairball." - Achieving Compliance as a Platform Engineering Team by Helping Developers Ben Linders · 2026-07-23 source ↗ Reader 🖥️
A platform team achieves durable compliance not by choosing better technical controls but by sequencing rollout (inform, then softly enforce, then strictly enforce) around transparency, shared purpose, and developer trust, because forced, patronizing enforcement fails even when the underlying tooling is sound. - Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core Willem Berroubache · 2026-07-23 source ↗ Reader 🖥️
In a high-volume, high-stakes security operations center, a multi-agent LLM architecture becomes production-viable and durable only when narrow agents coordinate over open protocols (A2A/MCP), expensive non-deterministic LLM inference is gated behind a cheap classical anomaly detector, and every consequential action is checked by a privileged, deterministic policy-as-code reviewer that treats human escalation as a first-class designed output rather than a monolithic LLM or a GenAI layer bolted onto conventional SIEM/SOAR tooling. - The Meter Was Always Running Bennie Haelen · 2026-07-23 source ↗ Reader 🖥️
Because a control plane can only govern a loop it can independently observe, organizations running tool-using agents must build one below-the-agent, turn-level, fleet-queryable observability substrate -- not per-run trace viewers, billing dashboards, or agent self-reporting -- and that single substrate, not three separate systems, is what answers cost, delegation, and runaway-action governance at once. - Prompt Injection to Data Exfil in 3 Hops Nick Davitashvili · 2026-07-10 Reader 🖥️
Prompt-injection-driven data exfiltration from Kubernetes-hosted AI agents cannot be stopped by probabilistic model-layer guardrails or by L3/L4 Kubernetes NetworkPolicy, and the reliable fix is deterministic, domain-aware, default-deny network egress containment that removes the lethal trifecta's channel leg — contained rather than eliminated, and paired with application-layer controls. - Spec-Driven Production Grade Development In The Age Of Vibe Coding Lee Boonstra · 2026-06-18 Reader 🖥️
Because agentic coding has eliminated the implementation bottleneck and shifted it downstream to the humans who must review, integrate, and govern AI-generated output, production-grade development requires treating specifications as a disposable-code-enabling source of truth, redesigning team review culture (risk-bundled PRs, conditional approval, no-blame norms, tiered continuous reviewers) around that volume, and backing both with defense-in-depth technical guardrails (sandboxing, policy servers, context hygiene) rather than relying on speed of writing or any single control. - Governing AI in the Cloud: A Practical Guide for Architects Dave Ward · 2026-06-15 source ↗ Reader 🖥️
Architects should regain control of ungoverned ('shadow') AI not by trying to police the models themselves but by building a staged, automated control plane in the cloud infrastructure — discover every AI touchpoint, classify data at the moment of creation, and enforce access at the data path through IAM and policy-as-code — while making the compliant path the easiest one so teams adopt governance instead of routing around it.
Propositions touching this concept (8)
By publication month, oldest first (extraction month when no publication date is known).
2026-06
- explicitdevelopedStatic IAM cannot express contextual governance (data age, model-registration status, environment, multi-team approval, break-glass); policy-as-code engines such as OPA/Rego, AWS Cedar and Sentinel evaluate these rules at runtime per request and should be unit-tested in CI/CD like application code.
2026-07
- explicitcorroboratedSafety and compliance policies (e.g. 'no PII exposed to an LLM') should be defined once as declarative, reusable contracts and enforced automatically at deploy-time and run-time — an 'admission controller' for data products — rather than requiring a human governance reviewer to approve each data product individually.
- explicitOrganizations can express engineering standards (security, compliance, networking, observability, operations) in natural language for the agent to enforce, without building a dedicated policy-as-code framework.
- explicitdevelopedRolling out compliance/governance controls in the sequence prevention (policy-as-code validation at creation time) then detection (scanning for existing violations) then notification/communication is a reusable pattern across compliance initiatives, not specific to tagging.
- explicitExisting policy-as-code solutions such as Sentinel and OPA operate as separate validation layers that fail to incorporate contextual information — such as relationships between resources that change over the infrastructure lifecycle.
- explicitA multi-agent LLM system becomes production-viable for a high-stakes SOC only when narrow specialized agents coordinate over an open protocol (A2A), integrate environment access through an open context protocol (MCP), gate expensive LLM inference behind classical anomaly detection, and enforce a privileged, policy-as-code reviewer with human escalation as a first-class output.
- explicit⚡ disputed & corroboratedA reviewer agent's safety logic must be codified as version-controlled, deterministic policy (e.g. OPA/Rego) that the reviewer calls out to, rather than reasoned about by an LLM at runtime from a prompt, because an agent should not be trusted to reason about its own safety on the fly.
- explicitcorroboratedTwo independent policy layers are required and neither is sufficient alone: OPA evaluates operational risk (blast radius, confidence, reversibility, escalation) before an action is approved, while Kyverno independently validates the resulting Kubernetes manifest against platform security invariants (trusted registries, no permissive network policies) at admission time.
Open gaps (18)
- incompleteThe talk describes the mechanics of automated policy enforcement (contracts, admission-controller-style checks) but never addresses the organizational half: who authors and updates the shared contract repository, how conflicts between a domain team's data product and a newly-introduced policy are arbitrated, or how policy correctness/coverage itself is governed once the human reviewer is removed from the loop.Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI — read next: extract-governing-ai-in-the-cloud, which is more developed on exactly this organizational half ('governance should be run as an internal product,' risk-graduated approvals) and would pair well with this talk's technical mechanism.
- incompleteThe claim that lineage 'comes for free' once every data asset is a data product elides that lineage across data products built on heterogeneous underlying engines (Spark, Databricks SQL, an Iceberg lakehouse) still requires each engine's own job/run metadata to be captured and correctly correlated across products — the talk asserts this correlation is trivial rather than demonstrating it, and no failure case or edge case (e.g. a data product whose transform spans two engines) is discussed.Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI — read next: Dedicated data-lineage literature (e.g. OpenLineage) for what cross-engine lineage correlation actually requires.
- incompleteAll evidence for the architecture is either analogy (Kubernetes/Docker/LLVM), an internally-consistent lifecycle description, or one small live demo of the speaker's own vendor product (Nextdata) — no production adoption numbers, latency/overhead measurements of the four-stage lifecycle versus a raw pipeline, or independent case studies are presented, and the speaker's commercial stake as the vendor's VP Engineering is never disclosed as a limitation on the evidence (though he does gesture that 'this is one implementation' of a supposedly vendor-neutral pattern).Presentation: Autonomous Data Products for the Autonomous Era: Rethinking Data Architecture for GenAI — read next: extract-mcp-api-sprawl for hard adoption/security statistics in the adjacent MCP-governance space, as a model of what evidence-backed claims in this domain look like.
- incompleteThe paper is written entirely from a Google/Antigravity-and-Gemini-CLI vantage point — every tool, product reference, and worked example (Antigravity, Gemini CLI, ADK, Spanner Graph, Vertex AI Agent Engine) is a Google product — so every claim about what 'coding agents' or 'AI' can or should do is implicitly a claim about this specific toolchain's current behavior, never flagged as distinct from more general, vendor-neutral claims about agentic coding.
- incompleteThe three-tier continuous-review spectrum and the 'Where to start' closing section both frame tier adoption as a single team's own choice, but never address who decides and pays for a Tier 3 investment (knowledge-graph infrastructure, dedicated evaluation/observability, on-call ownership) when the triggering codebase or compliance requirement crosses several teams' boundaries — the same single-team vantage point as the first gap, applied specifically to the review-tooling investment decision.
- uninformedThe approval-fatigue/burnout claim ('frequent AI users are 45% more likely to experience high burnout') is sourced to a single press report of industry survey data (CNBC citing Quantum Workplace) rather than a peer-reviewed study or the author's own organization's data, and the proposed remedies (Digital Quiet Hours, Agent Insight Sessions) are asserted without any evidence that they specifically reduce AI-approval-driven burnout, as distinct from general workplace wellness practices.
- uninformedThe 'inform first, softly enforce next, then stricter enforcement' cadence has no time-boxing: the article never says how long each phase lasted, what triggered graduation to the next phase, or what happens to non-compliant resources that persist through all three phases.Achieving Compliance as a Platform Engineering Team by Helping Developers — read next: Compare against policy-as-code and compliance-automation literature that specifies staged rollout with explicit graduation criteria (coverage thresholds, grace periods) to see whether 'gradual enforcement' claims elsewhere fill in what this piece leaves vague.
- uninformedEvery pattern in the catalog is presented with the author's own prescriptive worked example as its sole evidence; the catalog never cites an external case study, a controlled comparison, or independent practitioner validation for any individual pattern, despite the patterns ranging from simple (constraint-based prompting) to organizationally significant (atomic task decomposition coordinating parallel work across multiple teams).
- incompleteThe team-size framework (Solo / Two-Pizza / Multi Two-Pizza) treats team size as the organizing variable for pattern adoption but never addresses the transition itself — there is no migration path described from, say, a two-pizza team's Human-AI Handoff Protocol to a multi-team organization's Atomic Task Decomposition, only separate, static recommendations for each size category.
- incompleteThe 'ledger' is asserted from convergence but its mechanism, cost, and governance are unspecified — what a complete, verifiable record of agent actions actually records, how rollback is guaranteed, and how it is enforced across infrastructure, software, and network layers.Finding Comfort in the Uncertainty — read next: Read on agent audit trails, decision provenance, and policy-as-code approaches to enforcing verifiable agent action logs.
- incompleteThe article never explains the internal mechanics of the 'dynamic AI-driven decisions' component — what kind of model performs the risk evaluation, what its false-positive/false-negative rate is, or how it would interact with existing IAM/policy-as-code engines (OPA, Cedar) already used for agent governance elsewhere in the corpus.Beyond Zero: Google Publishes Successor to BeyondCorp — read next: Google's forthcoming implementation papers, and a direct comparison against policy-as-code frameworks (OPA/Cedar) already covered in the corpus's agent-governance material (e.g. the AWS Loom and privilege-drift extractions).
- incompleteThe article reports no independent benchmarking, security audit, or production case study of tfpolicy; every functional claim traces back to HashiCorp's own announcement and quotes, with no outside verification that relationship-aware or post-deployment evaluation performs as described.Terraform Introduces tfpolicy, an HCL-based Policy-as-Code Framework — read next: Look for independent write-ups, HashiCorp's own tfpolicy documentation/examples, or user reports once tfpolicy exits public beta.
- incompleteNo detail is given on migration cost or fidelity for organizations with substantial existing Sentinel policy libraries, beyond noting that HashiCorp is introducing an AI agent that can 'convert' Sentinel policies — with no discussion of what such conversion misses or gets wrong.Terraform Introduces tfpolicy, an HCL-based Policy-as-Code Framework — read next: HashiCorp's tfpolicy/Sentinel migration guide and the linked agent-skills repository (github.com/hashicorp/agent-skills) for what the conversion agent actually handles.
- incompleteThe OPA reviewer's decision depends on blast_radius_pct and confidence fields self-reported by the very agent proposing the action (only config_validated and reversible are set independently); the article never addresses how these self-estimates are validated, calibrated, or protected against being wrong or adversarially manipulated (e.g. via prompt-injected telemetry) — the deterministic policy layer is only as trustworthy as an untrusted agent's self-report on two of its four inputs.Article: Multi-Agent AI for Production Security Operations: An A2A and MCP Architecture in a 5G Core — read next: Look for calibration/validation work on agent-self-reported risk estimates, and adversarial-robustness literature on prompt injection through telemetry data feeding proposal generation.
- uninformedThe article names feature flags (LaunchDarkly), RBAC, and tenancy metadata as adjacent-but-distinct patterns, and cites ITIL/ISO change and incident frameworks, but never engages existing runtime policy-engine literature (OPA/Rego, AWS Cedar) — which the corpus's own privilege-drift piece names as the concrete tooling category for 'enforce at runtime, at the point of invocation.' Operating mode as proposed here is architecturally a policy-as-code problem (a context attribute gating an authorization decision), and the piece doesn't connect it to that existing ecosystem.Operating Mode as Runtime State: A Contract for Enterprise — read next: Policy-as-code literature (OPA, Cedar) for how a 'mode' attribute would actually be evaluated as part of an authorization decision at tool-invocation time; read against extract-privilege-drift-multi-agent-systems#g4.
- incomplete"Enforce least privilege at runtime, at the point of tool invocation" is stated as a principle without naming the tooling category that actually implements it — runtime policy engines (e.g. OPA/Rego, AWS Cedar) that evaluate authorization as executable, version-controlled code per request. The article names the destination but not the mechanism.How to Manage Privilege Drift in Multi-Agent Systems — read next: Policy-as-code literature: Open Policy Agent, AWS Cedar/Amazon Verified Permissions, and how they're being adapted specifically for agent tool-invocation gating.
- incompleteThe operational cost of authoring and maintaining accurate per-pod FQDN allowlists across many MCP servers is unaddressed. The 'list your egress paths' exercise presumes the legitimate destination set is knowable and stable, but tool surfaces, models, and third-party endpoints churn; a stale or over-broad allowlist re-creates the CIDR-allowlist failure the article warns against.Prompt Injection to Data Exfil in 3 Hops — read next: Read on policy-as-code lifecycle for egress policies — observe-then-enforce ('learn mode') workflows, drift management, and testing — and practitioner accounts of operating Cilium FQDN or service-mesh egress policy at scale.
- incompleteThe article urges operators to 'compare honestly' the footprints of the three enforcement options (service-mesh sidecar per pod, eBPF/Cilium agent per node, gateway firewall plus in-cluster controller) but supplies no actual comparison — no latency, cost, blast-radius, or operational-complexity data — so the load-bearing decision it says is 'the whole failure mode' is left to the reader.Prompt Injection to Data Exfil in 3 Hops — read next: Read benchmarks and postmortems comparing service-mesh sidecar overhead, Cilium eBPF dataplane cost, and gateway-firewall latency/attribution trade-offs; evaluate how per-pod identity survives to the gateway in the gateway-based option.