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
→ opens browser to authenticate (OAuth)
→ tool registered: pull_rules
→ tool registered: submit_signals
✓ connected · workspace="acme"

Same command pattern for Cursor (cursor mcp add rulemesh) and Codex (config the MCP entry directly). The MCP server runs locally, surfaces two tools, and authenticates back to RuleMesh over OAuth. Your source never leaves the machine.

1. 01
   Pull the rules

   Tell the agent which bundle to audit. The MCP server returns the requirements, cloud control mappings, and evidence schema.
2. 02
   Scan the codebase

   The agent reads your repo locally — service code, infrastructure config, IAM policies, retention jobs — and matches what it finds against the evidence schema.
3. 03
   Submit findings

   Findings go back via submit_signals: file paths, requirement IDs, met/partial/todo per requirement. No code body, no secrets.

Audit this repository against GDPR Article 32 controls.

1. Call rulemesh.pull_rules("access-control-security") to get the
   requirements and evidence schema.
2. Walk the repo. For each requirement, find the matching code,
   config, or infra and decide: met / partial / todo.
3. For met items, capture the evidence (file path, control ID).
   For partial/todo items, explain what's missing in one sentence.
4. Submit results via rulemesh.submit_signals with bundle_id
   "access-control-security".
5. Print a markdown summary to me 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.

Once the audit run completes, you have a list of gaps. The same agent loop closes them: prompt the agent to implement the missing controls, it pulls the requirement again via pull_rules, writes the code, and resubmits evidence. The bundle moves from partial to met without anyone reading another GDPR PDF.

Implement the missing controls for the data-subject-rights bundle.
Specifically: ensure delete propagates to the search index and the
analytics warehouse. Pull the requirement from rulemesh, write the
code, test it, and submit evidence.

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