Complyedge MCP Server

ComplyEdge

Block AI requests that break EU law.

Every check is logged: the rule, the law and the time. Never what your users typed or what the AI answered.

Each log entry holds the rules that fired and the article behind each, the exact rule set that decided (bundle_digest), the time, a keyed hash of the text and an event_id. It is kept outside your AI system, and you keep the text: with the event_id you can prove to an auditor, a data protection officer or a certifier which text a log entry was about, and ComplyEdge never keeps the content. When a rule that covers the act itself fires (Article 5 practices, prompt injection under Article 15(5), and on EU checks personal data and secrets such as email, phone, IBAN, card and national ID numbers, API keys and private keys), the request or answer is blocked and the block is recorded with its citation. Article 50, GPAI and high-risk rules fire on text that describes a missing control, and when one fires the call is blocked and recorded the same way. It checks this prompt or output; it does not classify your system. The rules in this repository are the rule set ComplyEdge runs. What a decision record must contain and prove is a separate document, ADCR, the open rulebook: complyedge.io/rulebook.

The same rules are available to your agent as an MCP server that checks the text you pass it, offline, with a citation on every finding.

Ships three ways: a Python SDK, an offline CI linter (TrustLint), and an MCP server, a Model Context Protocol server that exposes compliance checks as tools to any MCP host (Claude, Cursor, MCP Inspector).

When an auditor, a regulator or a large customer asks "which rule decided this, under which law, and can you prove it was this text?", the log entry answers. When a rule fires, the entry names the rule and the article; every entry, blocked or allowed, lets you prove which text it was about without sending the text to anyone who did not already have it. The sections "Verify a record" and "The rulebook" below show how.

What does your compliance tool tell a regulator when it blocks a request? A probability score?

ComplyEdge says: Article 5(1)(a), rule rego-art5-1a-001, timestamp, keyed input hash. One is an audit trail. One is a guess.

MCP Server (Model Context Protocol)

ComplyEdge TrustLint is an MCP server built on the official MCP Python SDK (mcp>=1.9). It gives an agent cited compliance checks instead of a probability score, and it runs fully offline: no API key, no network call, rules evaluated from the bundled YAML rule set.

Tools (the server exposes MCP tools only: no resources, no prompts; all are read-only and idempotent):

Local (stdio): for Claude Desktop, Cursor, MCP Inspector, or any MCP host:

pip install 'complyedge[mcp]'
complyedge-mcp          # or: python -m complyedge.mcp_server

{
  "mcpServers": {
    "complyedge": {
      "command": "complyedge-mcp"
    }
  }
}

Remote (Streamable HTTP): https://mcp.complyedge.io/mcp

sandbox_check is the one tool that needs a key. Locally, set COMPLYEDGE_API_KEY in the server's environment (without it the tool is not listed and the server stays fully offline). On the hosted server it is always listed and works only for a caller that sends its own key as the Authorization: Bearer <key> header on the MCP connection; the key is never a tool argument, never logged, and the hosted server keeps no keys.

{
  "mcpServers": {
    "complyedge": {
      "url": "https://mcp.complyedge.io/mcp",
      "headers": { "Authorization": "Bearer ce_your_api_key" }
    }
  }
}

Server source: sdks/python/complyedge/mcp_server.py. Full MCP docs: sdks/python/README.md. The three offline tools use the TrustLint engine and never call the hosted OPA/Rego policy API; sandbox_check is the one that does, and only with your key.

Install (coding agents):

Each line is an alternative; pick the one you need.

pip install complyedge                               # Python SDK: hosted checks and the decorator
pip install 'complyedge[mcp]'                        # plus the Python MCP server: complyedge-mcp
pip install trustlint                                # offline linter CLI
npx -y @complyedge/mcp                               # the MCP server on Node, no Python
claude mcp add complyedge -- npx -y @complyedge/mcp  # add the Node MCP server to Claude Code

Cursor one-click: Install TrustLint MCP

OpenAI Agents extra (hosted path; needs COMPLYEDGE_API_KEY):

pip install 'complyedge[agents]'

from complyedge.agents import create_compliance_guardrail

CI: uses: complyedge/trustlint-action@v1

Live enforcement seals

Not a static badge. Each project below is a ComplyEdge tenant that chose to show its seal, and each seal is drawn from the real /v1/check calls it runs, so it changes as real enforcement happens.

All six projects below are our own. ComplyEdge runs in production against our own code before we ask anyone else to run it against theirs. You choose the region when you create an account: EU (https://eu.api.complyedge.io, key prefix ce_eu_) or US (https://api.complyedge.io, key prefix ce_). The seals below use the US host because those accounts live in the US. The SDK reads the key and calls that host. To move an existing account, use Request a region change in the dashboard. Support moves the account and issues a new key. Setting an API URL does not move the account. The region is where checks run and audit records are stored; the prompt and the AI's answer are never stored, only a keyed hash of the checked text (HMAC-SHA-256 under the account's own key). It does not decide which laws are checked: the jurisdiction field on each check does. No general law requires either region. US law does not require US storage, and GDPR allows transfers outside the EU with safeguards such as standard contractual clauses (Chapter V). Choose the region your own contracts or customers ask for.

Each AI Trust Center is generated from that project's real audit trail: enforcement status, check volume, and the EU AI Act articles the rule set covers, which run on checks sent with an EU jurisdiction. (GitHub proxies and caches images, so the seals above can lag; the AI Trust Center is always current.)

Embed one on your own project: Enforcement Seal docs.

Quick Start

pip install complyedge

from complyedge import compliance_check

@compliance_check(jurisdiction="EU", agent_id="my-agent")
def my_agent(prompt):
    return llm.generate(prompt)  # every input and output checked

Three lines. Every AI input and output evaluated against the EU AI Act rule set (Article 5, Article 50, GPAI). Every decision gets a record with an event_id, the rules that fired (if any), a timestamp and a keyed text hash; a block by a rule also gets its legal citation. On a paid plan the injection check can also block when the month's model budget covers it, and that block names the law. A wider-review block does not cite an article. If that review is on and clears every hit, the request is allowed. With the default fail_mode="open", an API outage lets traffic through unchecked and unrecorded; use fail_mode="closed" to block instead.

Set COMPLYEDGE_API_KEY to your key. The decorator activates by default; to disable without removing the key (e.g., in CI), set COMPLYEDGE_ENABLED=false.

Without a decorator

from complyedge import is_safe, check
import os

api_key = os.environ["COMPLYEDGE_API_KEY"]

# Boolean check: returns True if no violations
if not is_safe(prompt, api_key=api_key, jurisdiction="EU"):
    raise ValueError("Prompt violates EU AI Act")

# Full result: returns ComplianceResult with the violations that blocked it
result = check(prompt, api_key=api_key, jurisdiction="EU")
if not result.allowed:
    for v in result.violations:
        print(v.rule_id, v.severity, v.rule_description)

Verify a record

ComplyEdge never stores your prompts or outputs. The record keeps text_hash, a keyed hash (HMAC-SHA-256, text_hash_alg: "hmac-sha256-1") of the text under your account's own key, which never leaves ComplyEdge. User and session identifiers you send are stored as keyed pseudonyms (p1:...), not as sent. So the record proves a decision without holding the content, and the reconciliation step is yours:

1. Store the event_id returned by every check next to your own copy of the prompt or output.
2. Verify the pair later with POST /v1/audit/verify ({"event_id": ..., "text": ...}), or from the SDK:

from complyedge import ComplyEdge

ce = ComplyEdge(api_key=api_key)
result = ce.check(text, jurisdiction="EU")
my_log.write(prompt=text, complyedge_event_id=result.event_id)   # your own copy

# later, in an audit or a complaint
assert ce.verify_input(result.event_id, text)   # True only for this exact text

In TypeScript the same call is client.verifyInput(eventId, text). The text you send to verify is used for that request only; it is not stored and not logged. If your copy of the text is gone, the record still proves that a decision was made and which rule made it, but not which text it was about. Full walkthrough: complyedge.io/docs/audit-reconciliation.html.

Each record joins your account's hash chain as it is written, in the same transaction. On Enterprise, the audit export carries that chain and is tamper-evident: any edit, deletion or reordering of a record is detectable, and a reviewer can check it offline with python -m audit_export verify export.json (services/api/audit_export.py).

The log is written for the people who have to judge a decision afterwards: an auditor, a data protection officer, a certifier. It records what was checked and what was decided; it does not prove that every AI call went through it (only routed calls are checked), and it does not decide whether a law applies to your system.

The rule set and the rulebook

The rules in rules/ are the rule set ComplyEdge runs: one rule per legal provision, each with its citation and approval status; rules/README.md maps the directories. What a decision record must contain and prove is a separate, open document: ADCR, the AI Decision Check Record, published at complyedge.io/rulebook as version 0.1.0, in development, with its schemas, an offline verifier and test vectors. A record names the rule set that decided it by digest. ComplyEdge is ADCR's first implementation. No conformance class is claimed; the gaps are listed field by field in Annex C of the rulebook.

• Rule IDs. Every rule has a stable ID that names the provision: rego-art5-1c-001 is AI Act Article 5(1)(c), first rule. Other forms cover Annex III points (rego-art6-annex3-5b-001), the Article 15(5) prompt-injection family (rego-art15-ipi-001), GPAI (rego-gpai-53a-001), GDPR (rego-gdpr5-1c-001) and US securities disclosure (rego-sox-302-001, which covers SEC Regulation FD, 17 CFR 243.100(a); the ID is kept from when it was filed under SOX §302). The full scheme is in rules/RULE_STANDARD.md.
• Citations. Each rule's citation names the instrument and the provision at paragraph and point level, then the text of that provision, for example Regulation (EU) 2024/1689, Article 5(1)(c): .... That string is what goes into the record when the rule fires.
• Approval states. Rego leaf headers carry Status: approved (or review / pending re-approval). YAML rules carry an approval object with the same meaning. Only approved means a named person signed off. Today 75 of the 75 Rego leaves and 63 of the 63 YAML rules are approved: 136 of the 136 rule IDs in the published rule set (the 75 Rego leaves carry 73 distinct IDs, because two indirect prompt-injection leaves share the ID of the technique they extend). Most were approved on 2026-10-22 through agent-delegated review (RULE_STANDARD §5.5): an agent ran the §5.2 checklist and the approver authorized the result; each file's approval line says so.
• Bundle digest. Every check response and every record carries bundle_digest, a SHA-256 over the rule files that were loaded when the decision was made. It changes whenever any rule changes, so a record names the exact rule set that decided it.

rule_id is the citation key: every rule carries its article reference in the rule set (rego-art5-1c-001 → Article 5(1)(c)), and the full citation text ships with the rule under rules/.

jurisdiction is where the end user is, not where your company is based: the EU AI Act applies when an AI system's output is used in the EU, wherever the provider or deployer is established (Art. 2(1)(c)). Default: EU. On the hosted phrase rules, EU runs the EU AI Act rules and the personal data and secrets rules (citing GDPR Articles 5(1)(c) and 32(1)), US and US-* run the Regulation FD disclosure rule, and every check runs prompt-injection detection. The other US rules (HIPAA, COPPA, TCPA, BIPA, CCPA, NYC LL144, ECPA) and the GDPR YAML rules (consent, data minimisation, DPIA, erasure, breach notification, transfers) run offline in TrustLint, not on the hosted /v1/check path. The YAML rules also run hosted through POST /v1/sensitivity/detect, by plan: Free runs the 12 prompt-injection, PII and PCI DSS rules; Developer adds HIPAA, SOX, COPPA and TCPA; Enterprise runs all 63, including the EU AI Act, GDPR, CCPA, BIPA and OFAC sanctions rules. On a paid plan, after the phrase rules pass, an injection meaning check runs. It judges by meaning against the same Article 15 categories, cites them, sends the text to a model, and can block. A missing answer denies. The wider legal review (use_semantic_fallback=True) runs only when you turn it on and can block text the rules passed. Neither model check runs the offline TrustLint rules.

TrustLint, Offline Linter

No API key required. Scans text against the YAML rule set using regex patterns. Published as a standalone package, versioned independently of the SDK.

pip install trustlint

trustlint check --text "We use social credit scoring to evaluate applicants"
# → [CRITICAL] EU_AI_ACT_ART5_SOCIAL_SCORING_001 (add -v for the citation and remediation)

Exit codes: 0 = pass, 1 = violations found. Designed for CI/CD pipelines. Source: packages/trustlint/.

Rule IDs: two namespaces

ComplyEdge resolves the same regulations through two engines, each with its own rule-ID namespace:

• Runtime API (OPA/Rego): IDs like rego-art5-1c-001: returned by compliance_check and the /v1/check API. This is the audit trail your production system logs.
• TrustLint (offline, YAML rule set): IDs like EU_AI_ACT_ART5_SOCIAL_SCORING_001: emitted by the offline linter.

Both cite the same legal article and differ only in engine. Map between them via the article reference carried in every rule.

What's In This Repo

sdks/python/          Python SDK (@compliance_check decorator, CLI)
  └ complyedge/mcp_server.py   MCP server (stdio): check_compliance, list_rules, scan_prompt
packages/trustlint/   Offline regex linter (TrustLint): no API key, for CI/CD
rules/regulations/    63 YAML rules (EU AI Act, GDPR, HIPAA, SOX, PCI DSS, and more)
rules/rego/           75 leaf OPA/Rego policies + 8 package aggregators
rules/schemas/        Rule validation schema
rules/scripts/        Schema validator (`validate_rules.py`)
examples/             Usage examples (decorators, OpenAI Agents)
scripts/benchmark/    Runtime benchmark (runner + prompt YAMLs + committed results)
tests/                Rule validation + acceptance tests

Rules

63 YAML rules (EU, US, global and universal) + 75 deterministic leaf OPA/Rego policies (+ 8 package aggregators).

What a decision from these policies establishes is not uniform, and we publish the split. Every leaf decides by matching the evaluated text (the leaf does not call a model). On a paid plan the hosted check also runs an injection meaning check after a clean pass when the month's model budget covers it. If that budget is used up, the phrase rules decide. For 32 of them the text is the regulated act (Article 5 prohibited practices, Article 15 prompt-injection resilience, personal data and secrets matched by format and checksum, one US disclosure control) so a block prevents the act and the citation on the decision is load-bearing. The other 43 fire on text describing a state the engine cannot verify: no text matcher can establish whether a technical file, a quality management system, a human-oversight assignment or a FRIA exists. Those are useful for triage; they are not a compliance finding, and their silence is not one either. On the hosted API any leaf that fires blocks the call and records it with its citation, whichever group it is in. Per-rule table: docs/rules-management/corpus-evidence-classification.md.

Each rule specifies conditions, severity, detection scope, and remediation with legal citations. See the rule schema for the format.

Writing Custom Rules

id: MY_CUSTOM_RULE_001
jurisdiction: EU
effective_date: "2025-02-02"
description: "Detect prohibited practice X under Article Y"
severity: critical
conditions:
  - type: regex
    value: "prohibited pattern"
source:
  regulation: "EU AI Act"
  article: "Article Y(1)(z)"

Validate: cd rules && python scripts/validate_rules.py

Architecture

Layer 1, Deterministic (hot path): 75 leaf OPA/Rego policies (+ 8 package aggregators) evaluate every request, no LLM. On the live API the engine's own time (opa_latency_ms) measured a p50 of 58ms and a p95 of 114ms over 20 warm requests (production_opa_latency_latest.json, 2026-07-30). The engine (OPA/Rego + TrustLint) evaluated in 1.018ms p99 in a local microbenchmark against the 8-package bundle the API queries (layer1_latency_latest.json, one 500-iteration run, 2026-10-21); queried one package after another, the same 8 packages measured 4.055ms p99. End-to-end through the live API, the published 60-prompt run measured a p50 of 139ms and p95 of 2,519ms across the 39 OPA-decided prompts, with individual requests spanning 47ms to 10.7s (runtime_benchmark_latest.json, 2026-07-28). That run mixes cold and concurrent invocations against a Lambda-backed API, which is where the long tail comes from; we publish the whole run rather than a hand-picked warm figure. The paid-plan injection check, when the month's model budget covers it, and the wider review when it is on, add 2-5s on the long tail. Binary pass/block, legal citation when a rule fires. (TrustLint applies the same regex corpus offline for CI use.)

Injection check and wider review: On a Developer or Enterprise plan, after the phrase rules pass, an injection meaning check runs when the month's model budget covers it. If that budget is used up, the phrase rules decide. It judges by meaning against the Article 15 prompt_security categories. A block is llm-art15-ipi-*, carries the Article 15 citation, and must quote the injected text from the request. A missing answer denies. The wider legal review runs only when use_semantic_fallback=True or the account's Layer 2 setting is on, and the month's model budget covers it. Its block is LLM_LAYER2_BLOCK. That label is not an article citation. If the wider review cannot answer, the request is denied. The wider review is off unless turned on. Free plans get no model call. A model check adds 2-5s.

ComplyEdge blocks and logs. On the hosted API a request or answer is blocked when a phrase rule fires. The paid injection check can also block when the month's model budget covers it, and the wider review can block when you turn it on. Every check is logged. The rule and the law are named when a phrase rule or the injection check fired. A wider-review block does not cite an article. Security products protect AI from bad actors; ComplyEdge is written for the auditor, the data protection officer and the certifier who have to judge an AI decision afterwards. The log is kept outside your AI system, so it is evidence your system did not write about itself.

Benchmark

A 60-prompt corpus runs against the live API. The runner, prompt YAMLs, and the latest result JSON are committed under scripts/benchmark/: inspect the results directly, or re-run with your own COMPLYEDGE_API_KEY.

False positives, measured. The false-positive battery is 1,185 texts that must be allowed: plain explanations of the law, policies, refusals, negations and realistic outputs that mention regulated topics without doing them. Each is checked under both the EU and the US jurisdiction, so one run is 2,370 checks, evaluated by opa eval over the same Rego packages the API reads. The latest run (2026-10-10) blocked 514 of 2,370 checks, a false-positive rate of 0.2169 on this battery, with the count per rule in scripts/benchmark/results/false_positive_measure_opa_latest.json. The battery runs in CI against a baseline that may only shrink: a new false positive fails the build.

GPAI leaderboard. The GPAI provider leaderboard scores providers' published documentation against Articles 50(2), 51 to 53 and 55. Every row is marked needs_review: the scores are a reading of public documents, not a legal verdict, and none has been confirmed by the provider or anyone else. Method: scripts/benchmark/gpai_benchmark_methodology.md.

Contributing

We welcome rule contributions. See CONTRIBUTING.md for details.

Every rule must include: article + paragraph citation, verifiable detection condition, and test cases.

Security

To report a vulnerability, see SECURITY.md. Do not open a public issue for security reports.

License

Apache License 2.0: see LICENSE.

Links

• Website: complyedge.io
• MCP server docs: sdks/python/README.md · remote endpoint https://mcp.complyedge.io/mcp
• Blog: complyedge.io/blog/
• GPAI Compliance Benchmark: complyedge.io/blog/gpai-compliance-benchmark.html
• Why OPA/Rego for EU AI Act: complyedge.io/blog/why-opa-rego-eu-ai-act.html
• PyPI: pypi.org/project/complyedge
• Changelog: CHANGELOG.md
• Rule Schema: rules/schemas/rule-schema.json