Docs

How audytx works

audytx is a GitHub App that posts one comment per pull request showing cost optimization opportunities and security findings on your AWS Terraform changes. This page covers what it checks, how it stays out of your way, and how to install it.

Install

Click Install on GitHub, pick the repository, and approve. The App needs:

Subscribed events: pull_request. We listen for opened, synchronize, and reopened — other actions (labels, edits, etc.) are ignored to keep noise down.

Use from a coding agent (MCP)

audytx is also an MCP server — the same engine the GitHub App runs, callable by any MCP-capable coding agent (Claude Code, Cursor, and friends) before the PR exists. No CI, no token, no install: 

claude mcp add --transport http audytx https://audytx.com/mcp

Two tools:

Transport: stateless Streamable-HTTP JSON-RPC at POST /mcp. Limits: 400 files / 3 MB per call. File contents are processed in memory and never persisted — same privacy posture as the GitHub App path. scan_terraform also accepts an optional plan argument (your terraform show -json output) for the same enrichment described below — handy when the agent has already run a plan.

Plan-enhanced scans (optional)

Static parsing can't see everything: values behind variables with no default, count/for_each expansion, and resources inside modules. If you run terraform plan in CI, you can hand audytx the resolved plan and it will scan with those final values folded in — surfacing findings the source-only scan can't. Strictly opt-in and additive: the normal scan keeps working exactly as before; this only ever adds signal.

Add this workflow. It authenticates with the run's GitHub OIDC token — nothing to paste, no secret to store; audytx verifies the token and scopes it to your repo automatically: 

# .github/workflows/audytx-plan.yml
on: [pull_request]
permissions:
  contents: read
  id-token: write        # lets the job mint an OIDC token
jobs:
  audytx-plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init -backend=false && terraform plan -out=tf.plan && terraform show -json tf.plan > plan.json
      - name: Upload plan to audytx
        env:
          AUD: https://audytx.com
        run: |
          OIDC=$(curl -sH "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
            "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=$AUD" | jq -r .value)
          PR=$(jq -r .number "$GITHUB_EVENT_PATH")
          SHA=$(jq -r .pull_request.head.sha "$GITHUB_EVENT_PATH")
          jq -n --slurpfile p plan.json \
            --arg repo "$GITHUB_REPOSITORY" --argjson pr "$PR" --arg sha "$SHA" \
            '{repo:$repo, pr_number:$pr, head_sha:$sha, plan:$p[0]}' > body.json
          curl -sf -X POST "$AUD/plan-upload" \
            -H "Authorization: Bearer $OIDC" -H "Content-Type: application/json" \
            --data-binary @body.json

Limits: 5 MB per upload. The plan JSON is processed in memory and never persisted — same posture as your source files. The PR comment notes a 🔬 plan-enhanced scan in its footer when plan data was used. If the upload fails for any reason, your normal scan still stands.

What we check

200+ rules across operations, security, reliability, and cost. The catalog is opinionated and AWS-only — we don't try to cover every cloud at a shallow depth.

IAM
Wildcard policies, role trust, MFA, access-key hygiene.
Encryption
KMS / managed SSE across SQS, S3, RDS, DynamoDB, EBS, Secrets Manager.
Networking
Security-group exposure, VPC endpoints, ALB / NLB config.
Observability
CloudWatch alarms, retention, X-Ray, Lambda DLQ.
Reliability
Multi-AZ, backup retention, DLQ chains, dead-letter routing.
Cost
gp2 → gp3, idle NAT, oversized non-prod, missing cost-allocation tags.
Compliance refs
AWS FSBP, SOC 2 CC6, PCI-DSS, HIPAA annotated per finding.
Architecture smells
Stateful resources without lifecycle protection, hardcoded account/region, etc.

Context-aware reasoning

Most IaC scanners are single-resource pattern matchers — they flag a Lambda for missing DLQ regardless of whether anything async invokes it. audytx pre-computes four cross-resource axes before evaluating each rule:

Rules consult these predicates as a post-filter, so a single-resource scanner's checklist doesn't fire false positives on legitimate patterns.

The reasoning is visible. Findings the context layer reclassified as false positives don't silently disappear — each appears in the PR comment under a collapsed 🧠 audytx reasoned about N findings and chose not to flag them block, with the rule ID, the resource address, and a one-sentence rationale ("queue is itself a dead-letter queue", "Lambda is not invoked async-push", "table actively expires its own data via TTL"). The same reasoning rides into GitHub's Code Scanning Security tab as a SARIF suppressions[] justification — alerts there show as "closed (dismissed)" with the rationale visible in the alert detail. A security review sees not just what fired, but what audytx considered and dismissed, and why.

Live inventory of axes + the rules that consult each is available at /status under context_reasoning_axes.

GitHub Code Scanning integration (SARIF)

Alongside the PR comment, audytx uploads a SARIF v2.1.0 document to GitHub's Code Scanning API at every scan. Findings appear in the repo's Security tab as alerts — with file:line annotations, severity grouping, framework-tag filter chips (aws-fsbp-s3.1, soc2-cc6.1), and stable per-finding fingerprints so the same alert tracks across PR pushes.

Why this matters for procurement: security teams that have standardised on Code Scanning (Dependabot, CodeQL, etc.) don't need to learn a new dashboard. audytx is just another alert source in the same place.

Requirements. SARIF upload requires either a public repo, or a private repo with GitHub Advanced Security. Private repos without GHAS still get the PR comment — the Security tab integration just no-ops. We log the failure to wrangler tail and continue.

SARIF severity mapping:

Reasoning visible in the Security tab. When the engine reasons a finding away as a false positive (see Context-aware reasoning), the finding still goes into the SARIF payload — but with a suppressions[] array carrying the engine's justification. GitHub's Code Scanning UI shows these as closed (dismissed) alerts and surfaces the justification alongside the alert detail. A security review of the Security tab sees not just what fired, but what audytx considered and dismissed — and why.

Suppressing false positives

Add a .audytx-baseline.yaml file to your repo root: 

ignored_findings:
  - rule_id: AWS_LAMBDA_004
    resource_address: aws_lambda_function.api
    reason: "API GW sync invocation — DLQ is a semantic mismatch"
    expires: 2026-12-31
  - rule_id: AWS_IAM_001
    resource_address: aws_iam_role.legacy_admin
    reason: "Legacy admin role; removal scheduled Q3"
    expires: 2026-09-30

The expires: field is required — suppressions without an expiry rot silently into never-relitigated tech debt. An expired entry stops suppressing and the finding reappears, forcing re-justification.

Suppressed findings still appear in the comment under a "Suppressed" appendix so auditors see what was acknowledged.

Privacy Policy

Effective: 1 June 2026 · Operator: Rexstart Labs Pvt Ltd · Contact: hello@audytx.com

What we collect

What we do not collect

Data retention

Data location

All processing runs on Cloudflare's global edge network. Scan metadata is stored in Cloudflare D1 (SQLite, US region). No data is transferred to third-party analytics, advertising, or data-broker services.

Changes

Material changes to this policy will be announced via the GitHub App release notes at least 14 days before taking effect. The effective date above is updated on each revision.

Terms of Service

Effective: 1 June 2026 · Operator: Rexstart Labs Pvt Ltd · Contact: hello@audytx.com

Acceptance

By installing the audytx GitHub App or sending requests to audytx.com/mcp, you agree to these terms. If you do not agree, uninstall the App and discontinue use.

Permitted use

Prohibited use

The following are strictly prohibited and will result in permanent account termination:

Reporting violations

Report abuse, violations of these terms, or suspected misuse to abuse@audytx.com. Include as much detail as possible: timestamps, GitHub usernames or installation IDs, and a description of the observed behavior. All reports are investigated. Confirmed violators are permanently banned from the GitHub App and the MCP endpoint, with no reinstatement path.

Service availability

Intellectual property

audytx's rule catalog, engine, and all associated software are the property of Rexstart Labs Pvt Ltd. Your Terraform source code remains entirely your property. We claim no rights over the code you submit for analysis.

Disclaimer and limitation of liability

audytx is a static analysis tool. Findings are provided for informational purposes only and do not constitute a security audit, legal advice, or a guarantee that your infrastructure is free of vulnerabilities. Use findings as one input in your security review process, not as a substitute for it. To the maximum extent permitted by applicable law, Rexstart Labs Pvt Ltd is not liable for any damages arising from your use of or reliance on audytx findings.

Governing law

These terms are governed by the laws of India. Disputes shall be subject to the exclusive jurisdiction of the courts of Bangalore, Karnataka, India.

Current limits