💡 Policy-as-Code Planning Extension for Sam

[github-actions[bot]]

Summary

Extend Sam's security plan workflow (CS) to bridge the gap between security controls documentation and executable policy enforcement. Guide teams through mapping their security controls to specific policy-as-code patterns (OPA/Rego, Cedar, Checkov), identifying which controls should be automated as CI/CD policy gates, and producing a policy implementation plan with starter templates. Keeps BGreat's content-only identity while accelerating the path from plan to enforcement.

Market Signal

Red Hat published work on LLM-powered automatic Rego policy generation from live cluster state, eliminating the "Rego tax." OPA-as-sidecar is the most-cited pattern for agentic AI system governance in 2026. Spacelift, Styra, and Conftest are the dominant policy-as-code tools. The industry is converging on policy-as-code as the standard for automated governance, but teams struggle with initial policy authoring — translating prose security requirements into executable rules. Sources: Red Hat AI Orchestrators for K8s Compliance (March 2026), Spacelift policy-as-code tools roundup, TianPan.co OPA/Rego for agent permissions guide.

User Signal

Riley's infrastructure workflow already references "OPA/Rego, Checkov, or tfsec for pre-apply validation" and "policy as code" in the expertise section. Sam's security plan generates comprehensive controls documentation across authentication, authorization, data protection, and network security — but there is no bridge from "these are our controls" to "these are the automated policies that enforce them." The gap between documentation and enforcement is where compliance drift occurs.

Technical Opportunity

Sam's security plan workflow (bgr-3-create-security-plan) step-03-security-controls.md defines security controls across authentication, authorization, data protection, and network security. A new section can guide Sam to:

1. Categorize controls — Label each control as "enforceable via policy" vs. "requires manual review"
2. Map to policy patterns — Map enforceable controls to specific policy-as-code patterns per the team's cloud_preference and container_orchestration config variables
3. Identify enforcement points — Determine where each policy should run: CI pipeline gate, Kubernetes admission controller, runtime guardrail, or infrastructure drift detection
4. Produce implementation plan — Generate a control-to-policy mapping table and prioritized policy implementation roadmap

Output remains Markdown (content-only, consistent with BGreat's identity) with policy pattern references that teams can use as starter templates.

Assessment

Dimension	Score	Rationale
Feasibility	med	Requires a policy pattern library mapped to common cloud/container configurations; the framework exists (step-03 security controls) but the policy mapping is new content
Impact	high	Bridges the most common failure mode in security planning — controls documented but never enforced. Directly reduces compliance drift
Urgency	med	Policy-as-code adoption is accelerating but not deadline-driven like regulatory compliance

Adversarial Review

Strongest objection: Generated policy patterns may be too generic to be useful without significant customization. OPA/Rego is just one policy engine — not all teams use it. There's a risk of "policy theater" where teams think they have enforcement but the generated patterns don't match their actual infrastructure.

Rebuttal: The workflow positions output as a "policy implementation plan" — a planning artifact that maps controls to policy patterns, not production-ready policies. This is consistent with BGreat's identity as a planning tool: the observability workflow doesn't generate Grafana dashboards, and the infrastructure workflow doesn't generate Terraform modules — they produce planning documents that accelerate implementation. The existing architecture already uses config variables for tool choices (cloud_preference, container_orchestration), so the workflow can adapt policy pattern recommendations to the team's actual stack. The control-to-policy mapping table is immediately useful even without auto-generated code, because it tells teams which controls to prioritize for automation and where to enforce them.

Suggested Next Step

Add a "Policy-as-Code Mapping" section to Sam's step-03-security-controls.md that guides categorization of controls as enforceable-via-policy vs. manual-review, maps controls to policy patterns per the team's configuration, and produces a prioritized policy implementation plan.

[github-actions[bot]]

Weekly Update

What Changed

• Industry shift from "shift-left everything" to "context-driven security" — enterprises are finding that blanket shift-left pushes too much security burden onto developers. The emerging model uses AI to surface only threats that matter based on deployment context, data sensitivity, and actual risk profiles (WebProNews, Checkmarx 2026 reports).
• Agentic AI built into policy enforcement — Spacelift and other PaC tools now include developer, policy, and insights agents that provide AI-driven support from inner to outer loops. This validates the approach of embedding policy-as-code guidance into Sam's planning workflows.
• Open Policy Agent (OPA) remains the dominant PaC engine, but AI-augmented policy generation and context-aware enforcement are becoming table stakes for 2026 tooling.
• DORA 2025 research validates that AI's positive impact on engineering performance depends on organizational system quality — policy-as-code is one mechanism that ensures consistent, auditable enforcement across environments.

Updated Assessment

Dimension	Previous	Current	Delta
Feasibility	high	high	→
Impact	high	high	→
Urgency	med	med	→ Market evolution is steady but not creating new deadline pressure

Recommendation

Keep watching — the context-driven security evolution is significant but the core policy-as-code planning workflow design remains sound as proposed. Consider incorporating a "policy placement strategy" section in Sam's PaC workflow that helps teams decide WHERE to enforce each policy (CI pipeline, deployment gate, runtime, or audit-only) based on risk context rather than defaulting to shift-left-everything.