MCP Registry & Auditor

The MCP Registry is the operator interface for RenLayer’s MCP server auditor. It lets security and platform teams submit a public GitHub URL of any Model Context Protocol server, runs a multi-layer security review against it, and synthesizes the results into a single risk verdict before the MCP is ever wired into an agent.

It addresses the new supply-chain class introduced by MCP: customers integrate third-party MCP servers from GitHub into their agents, and the code those agents load is rarely reviewed before deployment. The MCP Registry closes that gap as a pre-deploy gate.

What the audit covers

For every submission, RenLayer downloads the repository at the requested ref and runs an in-depth review across four dimensions:

• Code — static application security analysis to surface dangerous patterns, weak crypto, command-injection sinks, and other risky code shapes.
• Dependencies — known-CVE matching across the full dependency graph, including transitive dependencies pulled by lockfiles.
• Secrets — credential and API-key detection across the working tree.
• Misconfiguration — Dockerfile, IaC and config-file analysis for insecure defaults.

The findings are synthesized into an executive summary, a numeric risk score (0–100), and a categorical risk level. The audit always completes — it never silently dies.

Submitting an audit

From /mcp-registry, click Submit MCP. The dialog asks for:

• GitHub URL (required, must be https://github.com/owner/repo).
• Branch, tag, or commit SHA (optional; defaults to the repository’s default branch).
• Description (optional; free-text label that shows up in the list and detail views).
• Scan profile (optional override — see below).

After submitting, the page redirects to the detail view, which polls automatically while the audit runs. A typical audit completes in 1–3 minutes depending on repo size and the active profile.

Scan profiles

The auditor ships three profiles. Each picks a different depth/coverage trade-off; pick the one that matches your tolerance for false positives and run time.

Profile	Coverage	Use case
Conservative	Tight, high-confidence checks only	Smoke check, low false-positive rate, fastest run.
Moderate (default)	Balanced multi-language coverage with curated rule packs	Day-to-day default before integration.
Aggressive	Broad coverage with deeper rule packs	Pre-deploy gate. More findings, more noise.

You set a tenant default in Settings → MCP Auditor, and you can override it per audit at submit time. The detail page header shows the effective profile (profile: aggressive) so you always know what was applied.

Reading the report

The detail page is organized top-to-bottom:

1. Header: GitHub URL with copy/external-link buttons, ref, commit SHA, description, and the effective scan profile.
2. Status card: current queued/running/completed/failed state, a risk badge (HIGH, MEDIUM, etc.) and the numeric risk score (68 / 100), or the error message if the run failed.
3. Executive summary: the synthesis prose. Renders markdown — paragraphs, **bold** for the worst named risk per paragraph, and `inline code for CVE IDs, package names, file paths and CLI suggestions.
4. Risk overview: a 4-up grid with finding counts per category (code, dependencies, secrets, misconfig).
5. Findings: collapsible groups by category, sorted by severity within each group. Click a row to expand the description, remediation, file/line, and any CWE/CVE link.
6. Raw outputs: collapsible advanced section with the unfiltered scan output. Useful when a number looks off or the synthesis missed a pattern.

Re-running an audit

Click Re-run audit in the detail header. This creates a new audit row pointing at the same github_url, carrying forward the original scan_profile so the comparison is apples to apples. Re-running pulls the latest commit on the requested ref, so the resolved commit SHA in the new audit may differ from the original — that is intentional, since the point of a re-run is to check current state.

The original audit is preserved; you can compare the two reports side by side from the list view.

Tenant configuration

Settings → MCP Auditor has a single setting: the default scan profile. It applies to any audit submitted without an explicit override. The default is moderate. Changing it does not retroactively affect audits already submitted, only future ones.

The save button writes through to the platform API and emits an audit-log entry (update / mcp_auditor_config) with the previous and new profile, so you have a record of who changed the default and when.

Audit log integration

Every state change writes to the immutable audit log:

Action	Resource type	When
submit	mcp_audit	A new audit row is created.
rescan	mcp_audit	A re-run is requested. The details JSON includes rescan_of pointing to the original.
complete / fail	mcp_audit	The audit finishes. Includes finding count, risk level and effective profile.
delete	mcp_audit	A row is deleted.
update	mcp_auditor_config	The tenant default profile is changed.

This is the same audit chain used by every other governance action in RenLayer, so MCP audit activity is part of the GDPR / EU AI Act-mapped trail.

API surface

Programmatic access is available under /api/v1/mcp-audits:

Method	Path	Purpose
POST	/api/v1/mcp-audits	Submit a new audit. Body: { github_url, git_ref?, description?, scan_profile? }.
GET	/api/v1/mcp-audits	Paginated list. Query params: status, risk_level, limit, offset.
GET	/api/v1/mcp-audits/{id}	Full report including findings and raw outputs.
POST	/api/v1/mcp-audits/{id}/rescan	Create a new audit row reusing the original repo and profile.
DELETE	/api/v1/mcp-audits/{id}	Permanently remove an audit.
GET	/api/v1/mcp-audits/config	Read the tenant default profile.
PUT	/api/v1/mcp-audits/config	Update the tenant default. Body: { scan_profile }.

Mutations require the Owner or Admin role; reads work for any authenticated session.

Operational notes

• Tenant isolation: every audit is scoped to your tenant; no other operator sees your submitted repos or findings.
• No execution: RenLayer never executes the MCP server’s code. Only static analysis runs, in a sandboxed working directory.
• Hard timeouts ensure a hung scan never wedges the audit queue.
• Resilient: if any single layer of the analysis fails, the audit completes with the layers that succeeded and notes the failure in the raw outputs.