infra-risk-guardian

Inspiration

This project started with a frustration I lived through. While deploying an ML pipeline, I hit the same kind of failure three times, and every one traced back to GitHub OIDC and IAM configuration. The pipeline code was fine each time. The identity and permissions around it were wrong, and nothing flagged that until a deploy failed, or worse, until it succeeded with more access than it should have had.

AI can now write infrastructure code in seconds, but the part after the code is written, where identity, permissions and blast radius get checked, is still manual, easy to get wrong, and often only caught at deploy time.

So I asked what the post-code lifecycle would look like if agents did the heavy lifting but humans kept control where it matters. My principle: let AI explain and fix, but never let it invent the risk number.

What it does

Infra Risk Agent guards infrastructure changes. When a merge request touches Terraform:

1. A pipeline produces a deterministic risk score (0-100) with a blast-radius count and every finding mapped to a control (CIS GCP, SOC 2).
2. A GitLab Duo flow with two agents takes over. The risk analyst explains the change in plain language on the MR and writes a rollback plan. The remediator commits the smallest safe Terraform fix for fixable findings and escalates anything dangerous, such as destroying a database.
3. The pipeline gates the release. LOW-risk changes deploy to staging automatically. HIGH and CRITICAL changes stop and ask a human for one approval.

This is the Supervised level of autonomy: the human approves the outcome, not each step.

It knows where general AI fumbles: GitHub OIDC and IAM

Trust between GitHub Actions and a cloud account spans three systems: the GitHub token claims, the workload identity pool and provider, and IAM bindings. Errors show up in one system while the cause sits in another, and the quick fix is usually an over-broad grant. We encoded the known traps as rules:

Rule	What it catches
OIDC_NO_CONDITION	Provider has no attribute condition, so any repo can attempt to authenticate
OIDC_WEAK_CONDITION	Condition does not pin a repository
OIDC_WILDCARD_TRUST	workloadIdentityUser bound to a wildcard principal set
OIDC_ORG_WIDE_TRUST	Trust not pinned to a single repository
PRIVILEGED_IAM	CI service account holds Owner or Editor

Beyond OIDC it also catches open firewalls, public buckets, public databases, and destroy or replace of stateful resources.

DevSecOps lifecycle stages covered

Stage	What happens
Plan	Agent posts the risk summary and rollback plan
Create	Remediator agent commits safe Terraform fixes
Verify	terraform validate, format check, risk scorer
Package	Plan JSON and risk report kept as pipeline artifacts
Secure	IaC scan plus policy rules
Release	Risk-gated staging deploy and manual production approval
Configure	Terraform is the configuration source the agent edits
Monitor	Scheduled drift check
Govern	Findings mapped to CIS and SOC 2 controls with a recorded gate decision

How we built it

• GitLab Duo Agent Platform: a custom multi-agent flow (analyst then remediator) triggered by mentioning it on a merge request.
• GitLab CI/CD: validate, scan, risk, release and monitor stages, with the release job gated on the risk result.
• Python scorer (scripts/risk_score.py): reads terraform show -json output, applies policy/rules.json, and writes risk.json and risk.md. It has no dependencies and returns an exit code the pipeline acts on.
• Terraform on Google Cloud as the sample infrastructure under protection.
• Demo fixtures for a risky and a safe change, so the whole flow can be shown without cloud credentials.

Challenges

• Keeping the AI out of the score. It is tempting to let a model rate risk, but then the decision can't be reproduced or audited. Separating the deterministic score from the agent's explanation and remediation was the key design choice.
• Cross-system identity bugs. OIDC failures rarely point at their cause. Turning those painful experiences into precise, testable rules took the most iteration.
• Knowing when not to act. The remediator must never "fix" a database replacement by itself. We made it escalate stateful destroy and replace findings to a human.
• Tight deadline. Scoping to one workflow done well, instead of many half-built ones.

Accomplishments we're proud of

• A scorer that separates a dangerous OIDC setup (CRITICAL, three findings) from a properly scoped one (LOW) on the same resources.
• A clear, explainable boundary between what agents do alone and what needs a human.
• Every finding carries the control it violates, so the output is useful for compliance, not just for engineers.

What we learned

• Agents are most trustworthy when they explain and act around a deterministic core instead of replacing it.
• The highest-value automation sits in narrow, error-prone domains where general-purpose AI makes plausible but unsafe suggestions.
• Autonomy is a dial. The same flow can run Assisted, Supervised or Hands-off by changing the approval gates.

What's next

• Extend the rules to AWS and Azure OIDC federation and Kubernetes RBAC.
• Learn from past incidents so the remediator proposes fixes tuned to the team's patterns.
• A Hands-off mode that auto-promotes to production below a configurable risk threshold.
• Track risk scores over time to show whether a team's infrastructure is getting safer.

Try it

• Repository: [your GitLab project URL]
• Demo video: [your YouTube URL]

Built With

• github-iodc
• gitlab
• gitlab-ci-cd
• gitlab-duo-agent
• google-cloud
• json
• python
• terraform
• yaml