Business objective

Your rules written as software, so the guardrails enforce themselves instead of living in a PDF nobody reads. Policy-as-code expresses governance rules — who may deploy what, which configurations are allowed, what an agent may call, which infrastructure is compliant — as version-controlled, testable, automatically-enforced code evaluated at decision points (CI/CD pipelines, Kubernetes admission, infrastructure provisioning, API/agent calls). Instead of a human checking a checklist, an engine returns allow/deny against a declarative policy. It is the automation substrate beneath promotion-gates, trust-zone-segmentation, and increasingly agent authorization.

When you need it

Day-2 — automate after manual policy. You write the policy in English first (acceptable-use-policies, risk-tiers) and enforce it manually via review; you adopt policy-as-code when manual enforcement does not scale or when you need provable, consistent gating. For a hedge-fund CTO, the typical entry points are cloud/Kubernetes governance (a platform team already running OPA or Sentinel) and, newer, agent/tool authorization — deciding in code whether an agent may invoke a given tool or reach a given zone. It is plumbing: valuable, but adopted by platform/security engineering once the manual process exists and the scale justifies codifying it.

Security role

Enforcement substrate, not a control in itself. Policy-as-code is the mechanism by which other controls are enforced — preventive and inline at its decision points. Used for trust-zone admission and agent authorization it can deny outbound flows, block access to sensitive data, or refuse an untrusted action — but only as configured. It lives in the green (governed) zone as the engine that turns zone and promotion rules into enforced decisions. Closely related to the authorization-engine category (same engines — OPA, Cerbos — applied to fine-grained agent/tool authz rather than infra policy).

Vendors

OSS projects and the general-purpose policy engines:

• open-policy-agent — CNCF general-purpose policy engine (Rego); the de facto standard for cloud/K8s and externalized authz.
• styra — commercial OPA: management, distribution, and control plane (DAS) for OPA at scale.
• hashicorp-sentinel — policy-as-code embedded in the HashiCorp stack (Terraform/Vault), governing infrastructure provisioning.
• kyverno — Kubernetes-native policy engine using YAML/CRDs instead of a dedicated policy language.
• terraform-cloud — cross-listed: enforces Sentinel/OPA policy on infrastructure changes at provisioning time.

For policy-as-code applied specifically to agent and tool authorization, see the authorization-engine vendors (cerbos, permit-io, authzed, oso) — the same idea pointed at runtime agent decisions.

Consolidation / M&A dynamics

A largely open-source-anchored space: OPA (CNCF) commercialized by Styra; Kyverno (CNCF); Sentinel proprietary to HashiCorp — and HashiCorp itself flagged as acquired by IBM (per seed; unverified — to confirm in research), which would place Sentinel and Terraform Cloud under IBM stewardship. No heavy roll-up otherwise; the live trend is these engines being repurposed from infra governance toward agent/MCP authorization.

Adjacent categories

• authorization-engine — the same policy engines applied to fine-grained agent/tool authz (the runtime cousin of infra policy-as-code).
• promotion-gates — the CI/CD sign-off practice that policy-as-code automates.
• trust-zone-segmentation — zone admission rules are a natural policy-as-code use case.
• ephemeral-environments — Terraform Cloud / Sentinel govern what zone-scoped environments may be provisioned.
• mcp-gateway — increasingly enforces policy-as-code on agent tool calls.

Survey

Question. Which policy-as-code engines does your firm use to enforce version-controlled policy (infrastructure, Kubernetes, or agent/tool authorization)?

Answer options. Open Policy Agent (OPA); Styra; HashiCorp Sentinel; Kyverno; Terraform Cloud (Sentinel/OPA); Other (Please Specify).

Response scale. multi-select; Interested; Considering/evaluating; Pilot/implementing; In production; Would recommend; Would not recommend.

Notes for survey design. OPA is table-stakes / de facto standard; Styra is the commercial wrapper around it, so respondents may legitimately select both — not a contradiction. Sentinel selection usually tracks Terraform adoption; Kyverno tracks Kubernetes adoption. Heavy conceptual overlap with the authorization-engine survey (OPA, Cerbos appear in both) — clarify whether you are asking about infra policy vs agent/tool authz, or respondents will conflate them. HashiCorp’s ownership (IBM, per seed) may date the Sentinel/Terraform options.

Open taxonomy questions

• Strong overlap with authorization-engine: OPA and Styra appear in both. The cut here is infra/CI/CD policy vs runtime agent/tool authorization — worth a comparison page rather than merging.
• Is this a “governance” category or a “policy/process” enabler? Kept under governance because it has real products and a survey, unlike the pure-process rows.