Describe the drift
Start with a JSON AWS event or a plain-English issue description.
For AWS platform and cloud security teams
Turn risky AWS drift into validated Terraform PRs.
DriftGuard AI helps teams running Terraform in GitHub move from drift alert to remediation PR preview with risk context, generated HCL, local validation, and built-in safety checks.
Product promise: DriftGuard prepares reviewable PRs. It does not apply infrastructure changes.
The broken workflow
Drift remediation still depends on whoever has time to untangle AWS, Terraform, and review context.
A drift alert lands. Someone opens AWS, checks Terraform, asks whether the change is risky, drafts HCL, runs validation, and writes a PR summary from memory. If the team is busy, the drift sits.
Security context gets lost
Reviewers see a code diff, not why the drift matters.
Manual HCL drafts are slow
Every fix starts with copy, paste, search, and second guessing.
Validation is inconsistent
Teams trust the person, not a repeatable remediation workflow.
Spreadsheets do not close the loop
Tracking drift is not the same as getting a reviewed PR merged.
The DriftGuard workflow
Give engineers a PR, not another drift ticket.
DriftGuard starts with a drift description or event payload and produces the materials a reviewer needs: risk context, Terraform, validation evidence, and a policy-check result.
Generate and validate
The graph triages, writes Terraform, runs terraform validate, and self-corrects failed HCL.
Prepare the PR
Dry-run mode renders a PR preview. Live mode can open a GitHub PR after validation and built-in policy checks pass.
Why teams care
Less remediation drag. More reviewable evidence.
Reduce drift MTTR
Move from alert triage to a concrete Terraform PR preview in one repeatable run.
Make risk visible in the PR
Attach security and cost impact context so reviewers understand the urgency.
Avoid unsafe shortcuts
Terraform validation and built-in guardrails block obvious unsafe remediation before GitHub writes.
Keep humans in control
No infrastructure is applied by the tool. Engineers review, approve, and merge.
How it works
The current product path is intentionally narrow.
DriftGuard is built around one monetizable workflow: AWS drift to validated Terraform remediation PR. It does not try to replace your CI/CD system, policy program, or review process.
- Input: Use a drift event file or issue description. The online demo shows this with S3, security group, and RDS drift examples.
- Checks: The agent redacts common sensitive values, generates HCL, validates it in a Terraform sandbox, and runs built-in policy checks.
- Output: Get a PR preview in dry-run mode, or open a GitHub PR when live configuration is present.
Use cases
Start with drift that creates real review pressure.
S3 public access drift
Turn public-access findings into explicit Terraform public access block remediation.
Security group exposure drift
Turn public SSH ingress drift into a reviewed Terraform change that restores the approved network boundary.
RDS instance class drift
Surface cost impact when a database is resized outside Terraform and prepare the rollback PR evidence.
Why not the usual workaround?
Generic tools do not close the remediation loop.
Why not just use ChatGPT?
ChatGPT can draft HCL. DriftGuard is wired to the actual remediation loop: impact summary, Terraform validation, policy checks, and PR formatting.
Why not spreadsheets?
Spreadsheets track drift. They do not produce reviewed Terraform changes or validation evidence.
Why not Zapier or n8n?
Workflow glue can move alerts around. It does not understand Terraform correction loops or PR-ready remediation evidence.
Why not keep doing it manually?
Manual work is fine once. Repeated drift classes deserve a repeatable path from alert to reviewed fix.
Trust boundary
Built for review-first remediation.
DriftGuard is useful because it narrows the job. It prepares a validated remediation PR for humans to review. It does not bypass your approval process.
No auto-apply pathDriftGuard creates PRs. Engineers still approve and merge.
Local dry-run modeRun the demo without GitHub writes or live infrastructure changes.
Redaction before promptsCommon secrets and AWS account IDs are redacted before LLM calls.
Validation before PRPR creation is blocked when Terraform validation, policy checks, or upstream LLM steps fail.
Pilot access
Start with one drift class and one Terraform repo.
Self-serve signup is not open yet. The right next step is a focused pilot: dry-run first, then supervised PR creation after your team reviews the output.
Pilot scope that makes sense now
- One AWS account or sandbox environment
- One GitHub Terraform repository
- One drift class, such as S3 public access, security group exposure, or RDS instance class drift
- Dry-run first, live PR creation only after review
This page does not pretend signup is live. The brief gives you a concrete request to send to the DriftGuard maintainer or your internal platform lead.
Try the workflow online
Run the demo without installing anything.
The online demo includes three deterministic drift scenarios: S3 public access, security group exposure, and RDS instance class drift. It does not call AWS, GitHub, Terraform, or an LLM.
Browser-based dry run with 3 scenarios
Compare security and cost drift through the same guided flow: input event, triage, impact, Terraform, validation, policy check, and PR preview.
FAQ
Questions a platform buyer will ask.
Who is this for?
AWS teams using Terraform and GitHub that need faster, reviewable remediation for infrastructure drift.
How is this different from generic AI tools?
It is wired to a specific remediation loop: triage, impact summary, Terraform generation, local validation, policy checks, and PR creation.
What setup is required?
Python, Terraform CLI, an LLM provider key for real runs, and GitHub configuration for live PR creation. Dry-run demo mode does not need live keys.
Is my data safe?
The current repo redacts common secrets and account IDs before LLM prompts. Production deployments should add organization-specific DLP rules and durable audit controls.
What happens after I request access?
Today this is a manual pilot request. The right next step is scoping one repo and one drift class before enabling supervised PR creation.
What does this replace?
It reduces manual drift triage, HCL drafting, validation copy-paste, and PR summary writing. It does not replace human code review.
What does this not do yet?
It does not provide billing, hosted ingestion, GitHub App auth, durable run history, full policy scanning, or auto-apply.