ComplyEdge TrustLint
OfficialProvides a compliance guardrail for OpenAI Agents, using the hosted ComplyEdge API to check agent inputs and outputs against the EU AI Act.
ComplyEdge
ComplyEdge checks every request before it reaches your AI and every answer before your user, blocks the ones that break a rule, and records each decision outside your AI system, with the legal citation when a rule fires. Prompt injection, Article 5 practices and, on EU checks through the hosted API, personal data and secrets (email, phone, IBAN, card and national ID numbers, API keys, private keys) are blocked; Article 50, GPAI and high-risk rules flag text that describes a missing control. The same rules are available to your agent as an MCP server that checks the text you pass it, offline, with an article citation on every finding. It checks this prompt or output; it does not classify your system.
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).
Your system prompt says no and the model does it anyway. Customer data and API keys end up in the prompt. ComplyEdge blocks it before it lands. If an auditor, a regulator or a large customer ever asks what your AI blocked, you have a record of every check, not just logs.
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, 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 article-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 corpus.
Tools (the server exposes MCP tools only: no resources, no prompts; all are read-only and idempotent):
Tool | What it does |
| Check text against the TrustLint rule corpus. Returns PASS/FAIL with rule ID, severity, and the article citation behind each finding. |
| List available rules, filterable by jurisdiction ( |
| Pre-generation prompt scan. Returns |
| Optional, with your API key: hosted enforcement in sandbox mode ( |
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_live_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):
pip install complyedge
pip install trustlint
pip install 'complyedge[mcp]'
npx -y @complyedge/mcp
claude mcp add complyedge -- npx -y @complyedge/mcpListing: smithery.ai/servers/complyedge/complyedge
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_guardrailCI: uses: complyedge/trustlint-action@v1
GOPAL is an OPA library in your process. ComplyEdge is per-request deny + citation + AI Trust Center + MCP.
Related MCP server: scan-your-ai-toolkit
Live enforcement seals
Not a static badge. These seals reflect live /v1/check traffic from open-source projects
embedding ComplyEdge: they change as real enforcement happens.
Both 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; prompt text is never stored, only its SHA-256 hash.
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.
Project | Live AI Trust Center |
IVD Framework | |
Horizon |
Each AI Trust Center is generated from that project's real audit trail: enforcement status, check volume, and the EU AI Act articles its traffic is checked against. (GitHub proxies and caches images, so the seal above can lag; the AI Trust Center is always current.)
Embed one on your own project: Enforcement Seal docs.
Quick Start
pip install complyedgefrom complyedge import compliance_check
@compliance_check(jurisdiction="EU", agent_id="my-agent")
def my_agent(prompt):
return llm.generate(prompt) # every input and output checkedThree lines. Every AI input and output evaluated against the EU AI Act rule corpus (Article 5, Article 50, GPAI). Violations blocked before they reach the user. Every decision gets a rule ID, timestamp and text hash; every block also gets its legal citation.
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)rule_id is the citation key: every rule carries its article reference in the corpus (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 API's deterministic path, EU runs the EU AI Act rules, US and US-* run the SOX §302 disclosure rule, and every check runs prompt-injection detection. The other US rules (HIPAA, COPPA, TCPA, BIPA, CCPA, NYC LL144, ECPA) and the GDPR rules run offline in TrustLint, not on the hosted /v1/check path. The opt-in Layer 2 (use_semantic_fallback=True) adds two LLM judges: a prompt-injection classifier that judges by meaning against the same Article 15 categories and cites them, and a general LLM review. Neither runs the other rules.
TrustLint, Offline Linter
No API key required. Scans text against the YAML rule corpus 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, Article 5(1)(c)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 bycompliance_checkand the/v1/checkAPI. This is the audit trail your production system logs.TrustLint (offline, YAML corpus): 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 testsRules
63 YAML rules + 75 deterministic leaf OPA/Rego policies (+ 8 package aggregators) across 4 jurisdictions.
What a decision from these policies establishes is not uniform, and we publish the split. Every leaf decides by matching the evaluated text (no LLM on the hot path). 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. Per-rule table: docs/rules-management/corpus-evidence-classification.md.
Jurisdiction | Rules | Regulations |
EU | 36 YAML | EU AI Act Articles 4–6, 9–10, 12–16, 26–27, 50, 53, GPAI + Art 15 IPI (hosted); GDPR (offline, TrustLint) |
US | 15 YAML | SOX §302 (hosted, US checks); HIPAA, SOX §§404/802, COPPA, TCPA, BIPA, CCPA, NYC LL144, ECPA (offline, TrustLint) |
Global | 1 YAML | PCI DSS |
Universal | 11 YAML | PII detection, prompt injection (direct + indirect) |
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. The engine (OPA/Rego + TrustLint) evaluates in 4.87ms p99 in a local microbenchmark against the current 6-package bundle (layer1_latency_latest.json, best of 5 trials, 2026-08-04). 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. Opting into the Layer 2 LLM adds 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.)
Layer 2, Interpretive (synchronous, opt-in): When called with use_semantic_fallback=True, two LLM judges run in parallel after the rules pass, and either can block: a prompt-injection classifier that 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) and a general LLM review. If either cannot answer, the request is denied. Off by default since v0.2.2. Adds 2–5s latency per request.
Security products protect AI from bad actors. ComplyEdge blocks requests and answers that break a rule, and records every decision, with the legal citation when a rule fires. The record 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.
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/mcpBlog: 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
Changelog: CHANGELOG.md
Rule Schema: rules/schemas/rule-schema.json
Available Tools
3 toolscheck_complianceARead-onlyIdempotent
EU AI Act Article 5 and Article 50. TrustLint offline regex: not the hosted policy engine, not a system classifier. Check already-produced text (model input or output) against ComplyEdge TrustLint offline YAML rules (regex corpus). Use for post-hoc evaluation of text that already exists; for pre-generation screening of a prompt about to be sent, use scan_prompt. Argument text must be non-empty content to evaluate (empty/whitespace is rejected before any rule runs; this is not a system-risk questionnaire). Optional jurisdiction is EU, US, or GLOBAL; omit it to evaluate the full corpus. GLOBAL is a separate corpus tag, not the union of EU and US : reuse the same token you used with list_rules for a scoped check. Runs fully offline : no network call, no API key, no credentials stored, no writes outside the process, read-only and idempotent; regex match against the bundled corpus; does not classify AI-system risk tiers or call any remote API. Returns PASS/FAIL with rule ID, severity, citation, and remediation.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Non-empty already-produced content to evaluate (model input or output). Empty/whitespace is rejected before rules run; not a system-risk questionnaire. | |
| jurisdiction | No | Corpus scope: EU, US, or GLOBAL. Omit to evaluate the full corpus. GLOBAL is a separate tag, not EU∪US : reuse the same token from list_rules. |
Output Schema
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| message | No | |
| violations | Yes | |
| has_critical | No | |
| rules_evaluated | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnly/idempotent, but the description adds substantial context beyond them: fully offline, no network call, no API key, no credentials stored, no writes outside the process, regex match against bundled corpus, and explicitly does not classify risk tiers or call remote APIs. This is unusually rich disclosure that is consistent with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and the sibling exclusions, and nearly every clause carries operational value (offline guarantees, empty-input rejection, jurisdiction semantics). It is dense and slightly sprawling, but little of it is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read-only checker with an output schema, the definition supplies everything needed: input constraints, scope semantics, offline guarantees, and an explicit statement of return shape (PASS/FAIL with rule ID, severity, citation, remediation). No gaps that would cause a misinvocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3. The description still adds meaning beyond the schema: that GLOBAL is a separate corpus tag rather than the union of EU and US, that omitting jurisdiction evaluates the full corpus, and that the jurisdiction token should match the one used with list_rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (check already-produced text against TrustLint offline YAML rules) and explicitly positions it against siblings: 'not the hosted policy engine, not a system classifier' and 'for pre-generation screening of a prompt about to be sent, use scan_prompt.' An agent can distinguish it from scan_prompt and list_rules without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('post-hoc evaluation of text that already exists') and when-not ('for pre-generation screening ... use scan_prompt'), plus a note to reuse the same jurisdiction token as list_rules. Alternatives and the selecting condition are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_rulesARead-onlyIdempotent
EU AI Act Article 5 and Article 50. TrustLint offline regex: not the hosted policy engine, not a system classifier. List TrustLint offline compliance rules in the ComplyEdge corpus : the discovery tool; returns no PASS/FAIL or SAFE/RISK verdict. Use it to scope a jurisdiction before calling check_compliance; do not use it to evaluate text. Optional jurisdiction is EU, US, or GLOBAL; omit it to list the full corpus. GLOBAL is a separate corpus tag, not EU∪US : pass that exact token into check_compliance next for a consistent scoped evaluation. Returned total is the post-filter count. Runs fully offline : no network call, no API key, no credentials stored, no writes outside the process, read-only and idempotent. Returns rule IDs, titles, severities, jurisdictions, and categories.
| Name | Required | Description | Default |
|---|---|---|---|
| jurisdiction | No | Corpus scope: EU, US, or GLOBAL. Omit to list the full corpus. GLOBAL is a separate tag, not EU∪US : pass the same token into check_compliance next. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rules | Yes | |
| total | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnly/idempotent, but the description adds substantial behavioral context: fully offline (no network, no API key, no stored credentials), no writes outside the process, returns no PASS/FAIL or SAFE/RISK verdict, and that `total` is post-filter. This is exactly the extra context annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense and front-loaded, with the discovery role and usage routing early. Slightly heavy: the GLOBAL-token caveat and the read-only/idempotent claim each appear more than once, and the leading 'EU AI Act Article 5 and Article 50' fragment reads like a topic tag rather than a usable statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, yet the description still notes the returned fields and the meaning of `total`. For a single-optional-param discovery tool, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already defines the enum, the omit-to-list-all behavior, and the GLOBAL-is-not-EU∪US caveat. The description restates those same facts rather than adding syntax or edge-case meaning, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (TrustLint offline compliance rules in the ComplyEdge corpus) and explicitly positions itself as a discovery tool. It names sibling boundaries directly: not the hosted policy engine, not a system classifier, and distinct from check_compliance's evaluation role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when ('scope a jurisdiction before calling check_compliance') and an explicit when-not ('do not use it to evaluate text'), naming the sibling to use instead. The continuation instruction to pass the same jurisdiction token into check_compliance closes the loop completely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_promptARead-onlyIdempotent
EU AI Act Article 5 and Article 50. TrustLint offline regex: not the hosted policy engine, not a system classifier. Scan an AI prompt with ComplyEdge TrustLint offline YAML rules (regex corpus) before generation : pre-generation only. Use when the prompt is about to be sent; for post-hoc evaluation of already-produced text, use check_compliance. Argument prompt must be a non-empty candidate prompt about to be sent to a model (empty/whitespace is rejected; not already-produced output). This tool has no jurisdiction filter : it always evaluates the full bundled corpus. Runs fully offline : no network call, no API key, no credentials stored, no writes outside the process, read-only and idempotent; regex match against the bundled corpus; does not classify AI-system risk tiers or call any remote API. Returns SAFE or RISK_DETECTED with cited findings from the offline regex corpus.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Non-empty candidate prompt about to be sent to a model (pre-generation). Empty/whitespace is rejected; not already-produced output. |
Output Schema
| Name | Required | Description |
|---|---|---|
| risks | No | |
| status | Yes | |
| message | No | |
| recommendation | No | |
| rules_evaluated | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent, but the description goes well beyond them: runs fully offline, no network call, no API key, no stored credentials, no writes outside the process, no jurisdiction filter, and it does not classify risk tiers or call remote APIs. This is exactly the extra behavioral context annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and scope are front-loaded in the first two sentences, which is the right structure. It loses a point for run-on colon/dash chaining and for repeating the offline/no-network point three separate times.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be documented, yet the description still signals the SAFE / RISK_DETECTED outcome and that findings are cited. For a one-parameter scanner every call-time decision an agent needs — when, with what input, under what exclusions — is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter's schema description already states the non-empty, pre-generation, not-already-produced-output rules. The description largely restates that same constraint ('must be a non-empty candidate prompt about to be sent to a model (empty/whitespace is rejected)') rather than adding syntax, format, or size guidance, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening states a specific verb and resource — scanning an AI prompt against the offline TrustLint regex corpus — and immediately delimits what it is not (not the hosted policy engine, not a system classifier). It is trivially distinguishable from list_rules and check_compliance without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit timing rule ('Use when the prompt is about to be sent') plus an explicit exclusion and named alternative ('for post-hoc evaluation of already-produced text, use check_compliance'). The pre-generation-only constraint is stated twice, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
check_compliance - First observed
list_rules - First observed
scan_prompt
TDQS
Scored across 3 tools
list_rules is clearly a discovery tool distinct from the two scanners. check_compliance and scan_prompt run the same regex corpus on different inputs (already-produced text vs. a prompt about to be sent), and both descriptions explicitly point to each other; the lifecycle distinction is clear but the underlying operation is nearly identical, so some misselection is possible.
All three tools use a consistent snake_case verb_noun pattern: list_rules, check_compliance, scan_prompt. The convention is predictable and readable throughout.
Three tools is minimal but well-scoped for an offline regex linter: one discovery tool and two evaluation modes (post-hoc vs. pre-generation). Each tool has a clear role, though the surface is slightly thin for a compliance domain.
The surface covers rule discovery and evaluation for both prompts and generated text, which are the core workflows. Minor gaps exist, such as no tool for retrieving detailed rule content or batch/aggregate scanning, but agents can work around these.
Maintenance
Related MCP Connectors
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
MCP Spec Compliance MCP — audits any MCP server.json against the official Model Context Protocol
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Related MCP Servers
- AlicenseAqualityFmaintenanceUnified MCP safety server that detects prompt injection (75 patterns), scans LLM outputs for leaked secrets/PII, enforces API cost budgets, and creates signed audit trails. Zero ML dependencies, pure Python.1717 PyPI1MIT
- FlicenseNot gradedqualityNot gradedmaintenanceOpen-source AI governance toolkit. MCP servers & CLIs for scanning, auditing, and managing your AI environment-
- AlicenseNot gradedqualityBmaintenanceMCP server for AI agent security guardrails. Provides input validation, prompt injection detection, PII redaction, output filtering, policy enforcement, rate limiting, and comprehensive audit logging.43 npm1MIT
- AlicenseNot gradedqualityCmaintenanceA modular MCP server providing structured, methodology-driven prompt endpoints for rapid legal/compliance landscape mapping, gap discovery, and risk prioritization across privacy, IP, AI governance, security, consumer, and disclosure domains, with argument-based adaptability to any product context.7 npm6MIT