Cloud Janitor

The design constraint that shaped everything

No agent-generated infrastructure change executes without explicit human approval and a rollback plan generated before execution.

That constraint was set first and everything else followed from it. An agent that can silently mutate production AWS infrastructure is a liability no matter how good its reasoning is, so Cloud Janitor never applies a fix — it proposes one, as reviewable Terraform HCL a human reads and approves.

The eleven agents

Three named agents lead the system — FinOps Auditor, SecOps Guard, and Remediation Architect — supported by eight specialised agents.

The reasoning layer interprets natural-language queries, detects cost and security anomalies and configuration drift, then converts unstructured AWS findings into executable Terraform, passing a dedicated validation check before anything reaches human review.

SecOps Guard catches misconfigurations like security groups open to 0.0.0.0/0 and emits the fix as Terraform rather than silently remediating it.

Two entry points, one engine

The backend is provider-agnostic — AWS fully implemented, GCP and Azure interface-stubbed — with two front doors into the same core:

• a CLI (scan, approve, rollback, dashboard, mcp)
• a 10-tool MCP server built on FastMCP

Build process

Developed spec-first in Kiro IDE across multiple audit-remediation passes: six specs authored and reviewed, 232 tasks tracked to completion. Shipped to PyPI as cloud-janitor v0.3.0 via CI/CD with OIDC trusted publishing — no long-lived secrets — behind 1,300+ tests including Hypothesis property-based tests.