Run a GDPR audit with
Claude Code, Cursor, or Codex.

A GDPR audit by a consultant is a multi-week, mid-five-figure exercise that ends with a PDF nobody reads. A GDPR audit by your own coding agent is an afternoon, returns concrete file paths and code references, and produces a list your team can actually act on.

The trick is that the agent doesn't know GDPR. It needs the rule context — which articles apply, what evidence proves them, what cloud control satisfies them. That's what the RuleMesh MCP server provides.

~/your-repo $ claude mcp add rulemesh https://api.rulemesh.com/mcp
→ browser opens · log in with your RuleMesh email + password
✓ connected

For Cursor, add an entry to .cursor/mcp.json in the project root pointing at the same URL; for Windsurf, VS Code Copilot, JetBrains, or any Streamable-HTTP-capable client, see the MCP user guide for the exact config block. The server is hosted at https://api.rulemesh.com/mcp; your client runs locally and the agent reads your repo locally. The only things that travel across the wire are file paths, evidence signals, and bundle/requirement IDs — never source.

The canonical one-shot is the scan_and_report_bundle MCP Prompt — it threads start_scan → pull_rules → grep your code → submit_signals_batch → end_scan automatically. Claude Code supports MCP Prompts; some Cursor / VS Code builds don't yet. If yours does, this is one line:

/scan_and_report_bundle bundle_id="access-control-security"
                       concern="encryption"

If your client doesn't expose Prompts, do the same loop manually with the underlying tools. The agent walks the repo locally and emits findings — including gaps as evidence_type="manual" with low confidence.

1. 01
   Pull the rules

   Agent calls pull_rules with the bundle_id (slug or anchor_hash). The server returns each task with a compliance_checklist, scope_hints, search_hints (grep-friendly keywords), and an evidence_template.
2. 02
   Scan the codebase

   Agent walks the repo — service code, IaC, IAM policies, retention jobs — and matches against each task's checklist. No source crosses the wire.
3. 03
   Submit findings

   Agent batches results via submit_signals_batch: one item per file, with bundle_id, requirement_id, signal name, evidence_type, confidence, and source_file path. Coverage and gaps both go back as evidence.

Audit this repository against the access-control-security bundle.

1. Call start_scan(regulation="GDPR") and remember the
   scan_session_id.
2. Call pull_rules(bundle_id="access-control-security",
   limit=5) and read the compliance_checklist + search_hints on
   each task. (Use limit=5 if your context is tight — tasks are
   pre-sorted HIGH → MEDIUM → LOW.)
3. For each task, walk the repo and decide: met / partial / todo.
4. Call submit_signals_batch with one item per file,
   threading the same scan_session_id through the batch. Submit gaps
   as evidence_type="manual" with confidence < 0.5.
5. Call end_scan(scan_session_id=...).
6. Print a markdown summary grouped by requirement.

A real audit run produces output of this shape — file path, requirement match, evidence fragment, status:

• check_circle
  apps/auth-svc/jwt.ts

  TLS in-transit confirmed, JWT signing key stored in KMS. REQ art-32(1)(a) · 5/5.
• check_circle
  services/users/delete.ts

  Delete propagates to primary + replicas; search index NOT cleared on delete. REQ art-17(1) · 2/3.
• check_circle
  infra/terraform/s3-buckets.tf

  4 of 7 buckets enforce default encryption; 3 do not. REQ art-32(1)(a) · 4/7.
• check_circle
  lib/analytics/segment-config.ts

  Sub-processor (Segment) not listed in /sub-processors. REQ art-28(3)(d) · 0/1.

The cases where the audit finds gaps are the actionable parts. The search-index leak on delete and the missing sub-processor entry above are concrete bugs you can ticket.

A real product surface is service-repo + frontend-repo + iac-repo, often with a shared-libs repo and a data-pipeline repo on the side. Personal data crosses all of them, so the audit has to as well. There are two patterns that work — pick by how your team actually checks out code.

1. 01
   Pattern A — per-repo runs, threaded by scan_session_id

   Call start_scan once, capture the scan_session_id, then run the agent inside each repo passing that same ID through every submit_signals_batch. End with one end_scan. Evidence aggregates under a single scan even though the agent ran in three working directories. This is the right shape when each repo has its own owner and CI.
2. 02
   Pattern B — meta-repo mount

   Point the agent at a parent directory containing each repo as a sibling (services/, frontend/, infra/). One scan, one walk, agent crosses the boundaries on its own. Easier to drive but requires the agent to have read access across all of them — usually fine for a sole engineer or a platform team running the audit.

# repo 1 — kick off the scan
/scan_and_report_bundle bundle_id="access-control-security"
→ note the scan_session_id printed in the agent output

# repo 2 + repo 3 — manual loop, reuse the session
Call pull_rules(bundle_id="access-control-security").
Walk this repo and call submit_signals_batch with the same
scan_session_id="<id-from-repo-1>" on each batch submission.
Do NOT call end_scan.

# back in repo 1 (or anywhere)
Call end_scan(scan_session_id="<id-from-repo-1>").

The two patterns produce identical evidence shape on the server side. The choice is operational: who runs the audit, and whether your agent has read access to a parent directory.

Article 32(1)(a) is mostly about infra — bucket encryption, KMS rotation, IAM role boundaries, retention on logs. Whether the agent can audit any of it depends on what it can read. Three honest cases:

• check_circle
  Infrastructure-as-Code (happy path)

  Terraform, Pulumi, CDK, Helm, Kustomize — IaC repos are just code. The agent greps infra/terraform/*.tf for aws_kms_key, server_side_encryption_configuration, retention_in_days, lifecycle_rule. This is the case the sample findings above show — s3-buckets.tf with 4 of 7 buckets enforcing default encryption is exactly this shape.
• check_circle
  Click-ops infra with read-only cloud creds

  No IaC. Give the agent a read-only cloud profile (AWS ReadOnlyAccess, gcloud viewer, az reader) and let it call aws s3api get-bucket-encryption, aws kms describe-key, gcloud logging buckets list, etc. The agent submits live config as evidence the same way it submits a grep hit.
• check_circle
  Click-ops with no cloud access

  Export the live config to a snapshot the agent can read — Steampipe, AWS Config snapshot, gcloud asset export, or a hand-run aws ... > evidence/buckets.json. The agent treats the snapshot as a repo file. Slower, but keeps the audit honest.

What stays constant across all three: the rules and evidence schema RuleMesh ships. The agent gets the cloud control IDs (DP-3, DP-4, DP-5, DP-6 for encryption), the search hints (kms_master_key_id, server_side_encryption, tls_min_version), and the per-task checklist that defines what counts as met. Without that, the agent is guessing at what a 32(1)(a) audit even means.

Once the audit run completes, you have a list of gaps. The canonical one-shot for closing them is the implement_bundle Prompt — it pulls the rules, implements each task, and submits evidence per file. Use the same bundle_id you audited.

/implement_bundle bundle_id="data-subject-rights"
                  requirement_ids="itreq-gdpr-art-17-..."

If your client doesn't support Prompts, the manual equivalent: pull_rules the bundle, implement each task, then call submit_signals once per file (implementation, test, optionally documentation/config — sensitivity-scaled). The bundle moves from partial to met without anyone reading another GDPR PDF.

• How RuleMesh works — full runbook →
• GDPR Article 32 for engineering teams — controls, evidence, prompts →
• MCP server documentation →