Compliance requirements your engineers and AI agents can actually implement.

RuleMesh defines what every regulation requires across your cloud infrastructure, how to execute it with framework-specific controls, and what evidence proves it was done — ready for engineers, AI agents, and the auditors who’ll verify it.

Free to start. Account required for an API key. RuleMesh never accesses or uploads your source.

// article_32.rm
SHALL encryption_at_rest AND in_transit
IN cloud_infrastructure USING provider_KMS
Evidence kms_key_policy.json
GDPR·EU AI Act·engineered requirements·cloud & security controls
What RuleMesh does

The technical layer between the law and the work.

A regulation tells you the obligation. Security frameworks tell you the control. Auditors ask for proof later. RuleMesh connects those three parts in a form engineers and AI agents can act on.

gavel
Law

Requirement

The cited regulatory obligation.

engineering
Engineering

Control

The engineering action or framework-specific control that satisfies it.

fact_check
Audit

Evidence

The artefact or signal that proves it ran.

How it works

Four steps from
article to
evidence.

01
Connect your agent
Works with Codex, Claude Code, Gemini CLI, Cursor, and other Streamable HTTP MCP clients.
arrow_forward
02
Evaluate your repository
Your coding agent reads the repository in its own environment and compares the relevant files with RuleMesh requirements and evidence criteria.
arrow_forward
03
Review the evidence signals
Review what the agent found, what is partial, and what appears missing against the evidence criteria. Humans make the final determination.
arrow_forward
04
Track the work in your issue tracker
Findings route into Jira today; GitHub Issues, GitLab, and Linear are next.
arrow_forward
Built for engineers
Your coding agent reads your source. RuleMesh does not. The agent reports evidence signals and the file names where signals were detected.
PD
Privacy by design
Source access boundary
Inside your workflow

From engineered rules
to verified
engineering work.

Engineered rules01
article_32.rm
Art. 32(1)(a) — Security of Processing
Implement encryption as a measure appropriate to the risk.
SHALL implement encryption_at_rest
AND encryption_in_transit
IN cloud_infrastructure
USING provider_KMS
Cloud implementation
AWS: KMS · S3 SSE · RDS
Azure: Key Vault · SSE
GCP: Cloud KMS
Evidence
· kms_key_policy.json
· tls_config.terraform
· rotation_schedule.yaml
Engineer-ready regulatory rules
Every article becomes a SHALL statement your engineers and AI agents can execute.
Issue tracker02
Compliance in your tracker
Compliance in your tracker
Live in Jira now, with GitHub Issues, GitLab, and Linear next — posture across your modules, inside the tool your team already uses.
Risk matrix03
Prioritize by risk
Prioritize by risk
See which modules need attention before the next release. High, moderate, low — mapped to Articles.
Checklists04
Verification checklists
Verification checklists
Human review plus agent-scanned evidence signals on every requirement.
By the numbers
2regulations
GDPR and the EU AI Act, both engineered into structured requirements rather than prose.
7GDPR modules
Engineering modules mapped to the business-critical flows your team actually ships. The EU AI Act adds 6 of its own.
191GDPR requirements
Structured IT requirements across Articles 5–44, versioned, diffable, reviewable. The EU AI Act catalog adds 248.
3GDPR frameworks
Requirements mapped to the controls that satisfy them: Cloud Security (AWS, Azure, GCP), NIST CSF, and OWASP Top 10. The EU AI Act maps to 8, including AI-specific families.
Frameworks

Mapped across
every cloud
and framework.

policy
GDPR
99 articles · 191 IT requirements
191
smart_toy
EU AI Act
248 IT requirements · 8 frameworks
248
cloud
Cloud Controls
AWS · Azure · GCP
86
shield_lock
NIST CSF
Cyber security framework mappings
185
key
OWASP Top 10
Application security risks
10
Agent consistency

Change the agent. Keep the cited rule.

RuleMesh gives each connected agent the same requirement, control mapping, and evidence criterion. The model can change without asking every team to reinterpret the regulation from scratch.

Read the methodologyarrow_forward
Open standards work

An open protocol for machine-verifiable compliance exchange.

RuleMesh structures the work inside an organisation. HCAP is our open protocol proposal for exchanging compliance information across system and organisational boundaries.

Read the HCAP draftarrow_forwardIETF draft
Design partner fit

A fit if you are implementing now.

RuleMesh is onboarding a small number of teams doing regulatory work in real engineering this quarter — GDPR, the EU AI Act, or both. If that is your situation, the next page should help you decide quickly.

  • schedule

    Real implementation window

    Your team has engineering capacity to act in the next quarter, not just research the problem.

  • policy

    Real regulatory surface

    You are in scope for GDPR, the EU AI Act, or both, and need an implementation path you can defend, not another policy exercise.

  • route

    Workflow-first adoption

    You want to start with the MCP path now, and use Jira if it fits your workflow today while other surfaces expand.

Not a fit if you only want attestations, outsourced compliance services, or a broad multi-framework rollout before one regulation is working in practice.

See if your team is a fitarrow_forward
Reference surfaces

Start from the regulation surface when the question is scope, terms, or next actions.

These pages are for teams working out applicability, definitions, and obligation scope before implementation begins.

Next step

Connect the agent you already use. Review the evidence before you commit.

Create a free account, choose your coding agent, and copy the setup command. RuleMesh never accesses or uploads your source.

Connect RuleMesh to your coding agentarrow_forwardSee a sample evidence signals report