Secure the Terraform Cursor writes

Fix it in the session that wrote it

The appeal of scanning inside Cursor rather than in CI is that the fix is one turn away: the agent generates the Terraform, reads the findings, and corrects them before a reviewer ever opens the diff. It cuts both ways, though. Hand the agent a report full of false positives and it will happily "fix" code that was never broken. The findings audytx returns have already been checked against the resource graph, so the ones Cursor sees are worth acting on.

Two steps

1. Add audytx to .cursor/mcp.json

   Get a free Client ID, then add a project-level .cursor/mcp.json (or ~/.cursor/mcp.json to make it global). Cursor interpolates ${env:…}, so the ID can live in your environment instead of the committed file:

   .cursor/mcp.json

   {
     "mcpServers": {
       "audytx": {
         "url": "https://audytx.com/mcp",
         "headers": { "X-Client-ID": "${env:AUDYTX_CLIENT_ID}" }
       }
     }
   }

   This is a remote HTTP MCP server — no local process to run. Cursor picks up scan_terraform, autofix_terraform, scan_cloudformation, and the rest on the next reload.

2. Add an always-on project rule

   Cursor reads .cursor/rules/*.mdc files, which carry frontmatter that controls when they apply. An alwaysApply rule makes the scan standing policy, not something you re-ask each time:

   .cursor/rules/audytx-terraform.mdc

   ---
   description: Scan Terraform with audytx before a PR
   alwaysApply: true
   ---
   When a change touches Terraform, call the audytx scan_terraform tool on
   the full set of .tf files in the repo — not just the diff, because
   cross-resource reasoning needs the unchanged files too. Fix every High
   and Critical finding and re-scan. Use autofix_terraform for the
   mechanical ones: it applies the sound fixes and re-scans in one pass.

   Prefer a single plain file? Cursor also reads an AGENTS.md at the project root — put the same instruction there.

The gaps a single-file review can't see

What you can expect it to catch — the patterns our study found models ship by default:

• Secrets Manager rotation. A secret gets created for a database password, but never the companion aws_secretsmanager_secret_rotation. audytx finds the missing resource across the plan, not just a missing attribute on one.
• IAM privilege-escalation paths. iam:PassRole into a compute service the same principal controls is an escalation even when each statement reads scoped. audytx walks the documented paths across the trust graph.
• Invented security arguments. Models reach for a knob that doesn't exist — require_tls, require_ssl, a fused RDS argument — and the config fails terraform validate. Scanning surfaces the real attribute to set.

And the suppressions that keep the agent from chasing ghosts — a DLQ not asked to have its own DLQ, a role that reads privileged but can't escalate — each printed with its reasoning so the call is visible, not silent.

Same engine on every other surface

The MCP loop covers pre-PR. For the review itself, install the GitHub App — one comment per pull request, inline annotations, SARIF to GitHub Code Scanning — so anything the agent misses is still caught on the PR. Writing CloudFormation? The same loop works with scan_cloudformation, same rule ids and context.

Common questions