We talk about "Security-as-Code," but most teams are still just "Security-by-Manual-Checklist." Here is how a 72-hour audit panic led me to build a better way.
There is a specific kind of dread that only security engineers know.
It isn't the dread of a massive, headline-grabbing breach. It's quieter. It's the realization on a Tuesday afternoon that your "temporary" Kubernetes cluster has been wide open to the internet for six months, or that your production S3 buckets are missing the encryption tags you swore you'd implement "next sprint."
We call it Security Debt. And most of us are underwater.
┌──────────────────────────────────────────────────────────┐
│ THE SECURITY DEBT CYCLE │
├──────────────────────────────────────────────────────────┤
│ │
│ Sprint Planning ──→ "We'll fix it next sprint" │
│ │ ↑ │
│ ▼ │ │
│ Feature Work ──────────→ Security Backlog Grows │
│ │ │ │
│ ▼ ▼ │
│ Ship to Prod ──────────→ Audit / Incident │
│ │ │
│ ▼ │
│ ⚠ 72-Hour Panic Mode ⚠ │
│ │ │
│ ▼ │
│ Scramble to patch, document, │
│ and pray the auditors don't ask │
│ about *that* one Kubernetes cluster │
└──────────────────────────────────────────────────────────┘
The Gap Between "Knowing" and "Doing"
The problem with modern cloud security isn't a lack of knowledge. We know we shouldn't have open SSH ports. We know we should use IMDSv2. We know we should follow the Principle of Least Privilege.
The problem is translation. To move from a "Security Best Practice" to "Automated Enforcement," you usually have to learn a specialized language like Rego (for Open Policy Agent).
I learned this the hard way three days before a major audit. Our team was sharp, but exactly zero of us were "Rego experts." We spent 12-hour days squinting at documentation, trying to figure out how to tell OPA to look at a Terraform plan and reject any resource that didn't have a specific security tag.
It felt like trying to write a legal contract in a language I'd only heard spoken once in a movie.
┌────────────────────────┐ ┌────────────────────────┐
│ SECURITY INTENT │ │ SECURITY ENFORCEMENT │
│ (Plain English) │ ??? │ (Rego / OPA) │
├────────────────────────┤ ────────▶ ├────────────────────────┤
│ │ │ │
│ "Encrypt all S3 │ │ deny[msg] { │
│ buckets and tag │ │ resource := ... │
│ them with an │ │ encryption := │
│ Owner email" │ │ object.get(...) │
│ │ │ not encryption │
│ │ │ msg := sprintf(...) │
└────────────────────────┘ └────────────────────────┘
↑ ↑
Anyone can say this Requires months of practice
on day one + framework-specific nuance
The gap between these two things — intent and implementation — is where most teams quietly give up on Policy-as-Code.
Security is Not Just Compliance
A lot of people think Policy-as-Code is just for passing audits like PCI-DSS or SOC2. That's a mistake.
Compliance is just the floor. Security is the ceiling.
Automated policies (guardrails) do more than just check boxes. They prevent:
- The "Fat Finger" Error — Preventing an intern from accidentally making a database public.
- Configuration Drift — Ensuring that "temporary" fixes don't become permanent vulnerabilities.
- Shadow IT — Making sure every new cloud resource follows your company's security DNA from the moment it's created.
WHAT AUTOMATED POLICIES ACTUALLY PROTECT YOU FROM
COMPLIANCE REAL SECURITY
(What auditors see) (What attackers exploit)
┌────────────────────┐ ┌───────────────────────────┐
│ │ │ │
│ ✓ PCI-DSS 4.0 │ │ ✓ The accidental public │
│ ✓ SOC 2 Type II │ + much → │ S3 bucket │
│ ✓ NIST 800-53 │ more │ ✓ The temp IAM key that │
│ ✓ CIS Benchmarks │ │ never got rotated │
│ ✓ HIPAA │ │ ✓ The EC2 with IMDSv1 │
│ │ │ still enabled │
└────────────────────┘ │ ✓ The "open for debug" │
↑ │ security group rule │
Periodic evidence └───────────────────────────┘
collection ↑
Continuous enforcement
(every deploy, every PR)
Introducing OPA Policy Agent: The Security Translator
I built OPA Policy Agent because I realized that the barrier to entry for robust security was too high. You shouldn't need a PhD in logic programming to ensure your buckets are encrypted.
I wanted a tool that could bridge the gap between Security Intent (English) and Security Enforcement (Rego).
┌─────────────────────────────────────────────────────────────────────┐
│ OPA POLICY AGENT │
│ "The Security Translator" │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ YOU TYPE: │
│ "Ensure all EC2 instances use encrypted EBS volumes │
│ and are tagged with an Owner email" │
│ │ │
│ ▼ │
│ ┌────────────────────────────────┐ │
│ │ AI Engine │ │
│ │ OpenAI · Anthropic · Bedrock │ │
│ │ Vertex AI · Ollama │ │
│ └────────────────────────────────┘ │
│ │ │
│ ▼ │
│ YOU GET: │
│ ✓ Production-ready .rego file │
│ ✓ Compliance metadata auto-embedded (NIST, CIS, PCI-DSS) │
│ ✓ Tuned to your engine (Terraform / CloudFormation / Gatekeeper) │
│ ✓ Deployable in minutes, not days │
│ │
└─────────────────────────────────────────────────────────────────────┘
1. Security Intent to Production-Ready Code
Instead of hunting through StackOverflow, you describe what you need.
"Write a rule that ensures all EC2 instances use encrypted EBS volumes and are tagged with an Owner email."
The agent doesn't just give you a snippet; it gives you a production-ready .rego file with all the context needed for your specific environment — Terraform, CloudFormation, or Kubernetes.
2. Multi-Cloud, Multi-Engine Intelligence
Security isn't one-size-fits-all. A security check for storage encryption looks fundamentally different if you're evaluating a Terraform Plan JSON versus a live Kubernetes Admission Review.
YOUR SECURITY INTENT
"Ensure storage is always encrypted"
│
┌─────────────┼──────────────┐
▼ ▼ ▼
┌────────────┐ ┌───────────┐ ┌────────────┐
│ Terraform │ │ Cloud- │ │ Kubernetes │
│ Plan JSON │ │ Formation │ │ Gatekeeper │
└─────┬──────┘ └─────┬─────┘ └─────┬──────┘
│ │ │
▼ ▼ ▼
resource.change input.Resources input.review
.after.server_ [id].Properties .object.spec
side_encryption .BucketEncryption .volumes[_]
_configuration .encrypted
─────────────────────────────────────────────────
Each engine speaks a different dialect.
OPA Policy Agent knows all three.
The agent understands these "dialects." It knows how to find the same security flaw across three different clouds and four different infrastructure tools.
3. Built-in "Evidence" for the Auditor
Even if you're focusing on general security, the audit will eventually come. OPA Policy Agent automatically embeds compliance metadata into your security rules.
When the auditor asks, "How do you know you're following NIST 800-53?" — you don't show them a spreadsheet. You show them the code.
# METADATA
# title: ENFORCE_ENCRYPTION_AT_REST
# description: Ensures all storage resources have encryption enabled.
# custom:
# severity: CRITICAL
# compliance:
# - "NIST SP 800-53: SC-28"
# - "CIS AWS Foundations: 2.1.1"
# - "PCI DSS 4.0: Requirement 3.5.1"
# - "HIPAA Security Rule: 45 CFR §164.312(a)(2)(iv)"
WITHOUT OPA POLICY AGENT WITH OPA POLICY AGENT
┌─────────────────────────┐ ┌──────────────────────────┐
│ │ │ │
│ Auditor: "Show me │ │ Auditor: "Show me │
│ your NIST SC-28 │ │ your NIST SC-28 │
│ compliance." │ │ compliance." │
│ │ │ │
│ You: *opens 47-tab │ │ You: *opens terminal* │
│ spreadsheet* │ │ $ grep -r "SC-28" │
│ │ │ ./policies/ │
│ "Uhh... give me a │ │ │
│ minute..." │ │ "Here are the 12 rules │
│ │ │ enforcing it, live, │
│ 😰 │ │ in CI." │
│ │ │ │
└─────────────────────────┘ │ 😎 │
└──────────────────────────┘
The "Air-Gapped" Security Reality
One thing I learned from talking to other security leads is that Privacy Matters. You can't always send your infrastructure code to a public AI.
That's why I built the agent to be backend-agnostic.
┌──────────────────────────────────────────────────────────────────┐
│ CHOOSE YOUR AI BACKEND — SWITCHABLE LIVE │
├─────────────────┬────────────────────────────────────────────────┤
│ Standard Cloud │ OpenAI (GPT-4) · Anthropic (Claude) │
│ │ Google Vertex AI (Gemini) │
├─────────────────┼────────────────────────────────────────────────┤
│ Regulated / │ AWS Bedrock — stays within your AWS account │
│ Private Cloud │ Full AWS IAM control, no data egress │
├─────────────────┼────────────────────────────────────────────────┤
│ Air-Gapped / │ Ollama — runs entirely on local hardware │
│ On-Premises │ No API call ever leaves your building │
└─────────────────┴────────────────────────────────────────────────┘
Your security policies should stay within your
security perimeter.
The Honest Reflection
Looking back at that audit panic, I realize we weren't "bad" at our jobs. We were just using the wrong tools for the scale of the problem.
"SECURITY BY HOPE" "SECURITY BY DESIGN"
(What most teams do today) (What you could have)
┌───────────────────────┐ ┌───────────────────────┐
│ Rules live in a │ │ Rules live in Git. │
│ spreadsheet or │ │ Reviewed like code. │
│ someone's memory │ │ Versioned. Tested. │
└───────────────────────┘ └───────────────────────┘
┌───────────────────────┐ ┌───────────────────────┐
│ Enforcement relies │ │ Enforcement is │
│ on humans remembering│ │ automated in CI/CD. │
│ to check things │ │ Every PR. Every push.│
└───────────────────────┘ └───────────────────────┘
┌───────────────────────┐ ┌───────────────────────┐
│ Audit prep = 72 hours│ │ Audit prep = point │
│ of spreadsheets and │ │ auditors at the repo.│
│ existential panic │ │ Done in an hour. │
└───────────────────────┘ └───────────────────────┘
Manual security doesn't scale. Checklists don't scale. Policies scale.
If you're still relying on humans to remember every security rule for every pull request, you're just waiting for a Tuesday afternoon you'll never forget.
It's time to move from "Security by Hope" to "Security by Design."
I'd love to hear from you: What's the "temporary" security fix in your environment that's been there for way too long? Let's automate it.
Connect with me on LinkedIn to talk DevSecOps and AI.
Top comments (0)