← Back to ArchGuard

Methodology

What ArchGuard checks — and how

Practitioners shouldn't pay for a black-box AI tool. This page explains exactly what ArchGuard reviews, how the analysis works, and what happens to your code.

What we never do

  • We never access your AWS account or credentials
  • We never read or write your Terraform state file
  • We never create pull requests or apply changes to your infrastructure
  • We never store your Terraform code after the review is complete

What we do

  • We read the Terraform files you provide — nothing else
  • We run analysis against those files and a workload brief you write
  • We return a structured findings report. You decide what to act on.

The four review pillars

Security

  • · IAM roles and least-privilege
  • · Security group ingress rules
  • · Public accessibility settings
  • · Secrets and credential handling
  • · Encryption at rest and in transit
  • · VPC network topology
  • · Resource exposure via outputs

Reliability

  • · Single points of failure
  • · Multi-AZ and redundancy coverage
  • · Backup and snapshot configuration
  • · Queue and event-source timeout alignment
  • · Dead-letter queue configuration
  • · Health check coverage
  • · Failover paths

Cost Optimization

  • · Idle and unattached resources
  • · Over-provisioned compute
  • · Missing TTLs causing unbounded growth
  • · Duplicate processing from misconfigured queue settings
  • · Rightsizing opportunities

Operational Excellence

  • · CloudWatch alarm coverage
  • · Log group configuration
  • · Access logging on API surfaces
  • · Mutable image tags and deployment determinism
  • · Observability gaps

AI + deterministic rules — how they combine

Deterministic checks

Some findings are rule-based and have no ambiguity: publicly_accessible = true on an RDS instance with cidr_blocks = ["0.0.0.0/0"] is always a HIGH security finding. These checks run first and produce high-confidence findings regardless of workload context.

AI-assisted reasoning

Other findings require context: is a single-AZ RDS instance a problem? It depends on whether it's dev or prod, what SLA the workload requires, and whether the team has accepted the risk. AI reasoning applies the workload brief to surface findings that a rule-based linter would miss or incorrectly flag.

Every finding in an ArchGuard report includes a Confidence level (High / Medium / Low) and the specific evidence — the Terraform resource name, attribute, and value — that produced it. If you disagree with a finding, you have everything you need to push back.

Data handling

You provide: your Terraform files (.tf) and a short architecture brief (plain text). We process: the Terraform code and brief to generate findings. No AWS credentials, no state file, no live account access is required or accepted.

Retention: your Terraform code is not stored after the review is delivered. The findings report is retained only to allow you to access it.

Processing: analysis runs in an isolated environment. Your code is not used to train models or shared with third parties.

What ArchGuard doesn't cover

  • · Application-layer authentication logic (not visible in Terraform)
  • · Resources managed outside Terraform in the provided files
  • · Runtime behavior and live traffic patterns
  • · Compliance certification (SOC 2, ISO 27001) — findings map to frameworks but are not a formal audit
  • · Non-Terraform infrastructure (CloudFormation support is on the roadmap)

Every ArchGuard report includes an Assumptions section that calls out exactly what was and wasn't visible in the provided inputs.