Skip to content
secure-mcp
Esc
↑↓navigate↵open⌘Jpreview

Getting started

Install once. Review in six phases.

Everything from install to handoff — the commands are real, from the current v2 build.

  1. 01

    Clone and build the server

    Clone and build require Git, Node.js 20+, and pnpm 10; the installer also requires Bash and Python 3 (PowerShell on Windows). The checkout contains the server, installer, and master agent skill.

    git clone https://github.com/brbndon/secure-mcp.git
cd secure-mcp
pnpm install --frozen-lockfile
pnpm build
  2. 02

    Authorize and install

    Allowlist the parent that contains the repositories you review. The installer wires the checkout and skill into pi, Cursor, and Codex and requires MCP protocol 2026-07-28. Grok is unsupported until it speaks that revision.

    SECURE_MCP_ALLOWED_ROOTS=/abs/path/Code \
  ./scripts/install-agents.sh install
  3. 03

    Verify and restart

    Check the installed skill, client configuration, allowlist, and server startup. Then restart agent sessions so they reload the integration.

    ./scripts/install-agents.sh check
  4. 04

    Start the first review

    Ask the agent for an authorized defensive review of an allowlisted repository. It should inventory first and preserve coverage through the final report.

    Review /abs/path/repositories/my-app with secure-mcp.
Keep it read-only and remediation-focused.

The audit workflow

Six phases, one mandate.

The recommended sequence keeps scans bounded, guidance stack-aware, and findings confirmed before they reach a human.

  • Phase 1

    Inventory

    secure_mcp_list_project_structure scopes the repository and reports stacks, paths, and coverage.

  • Phase 2

    Architecture and guidance

    secure_mcp_analyze_architecture detects stacks and recommends knowledge packs; secure_mcp_get_knowledge_pack loads them on demand.

  • Phase 3

    Category checks

    Authentication, injection risks, and secrets reviews run in parallel, each returning structured candidates.

  • Phase 4

    Confirmation

    The agent opens each candidate's file at the cited line and confirms the data flow before anything is reported.

  • Phase 5

    Remediation report

    When confirmed findings remain, secure_mcp_produce_findings dedupes, filters, and prioritizes them. Otherwise the agent writes a coverage-qualified no-findings narrative.

  • Phase 6

    Handoff

    Executive summary, fix plan, methodology limits, and a retest checklist — no exploit content anywhere.

Coverage honesty

“Not observed” never means “not scanned”.

Every bounded scan returns structured coverage: which paths were included, ignored, excluded, or truncated — and why.

Coverage distinguishes three situations that scanners usually blur together:

  • No candidate found — every reviewed file was checked and nothing matched.
  • Scan truncated — caps were hit and the remaining scope was not reviewed.
  • Candidate pending — heuristics stay candidates until the data flow is confirmed in code.

An empty finding list is never presented as proof that a whole tree was clean. That keeps the report trustworthy — and actionable.

Defensive use policy

Hardening only. By design.

secure-mcp is a defensive, remediation-focused review tool. Its mandate is to identify potential weaknesses, classify them, and recommend concrete remediation.

The server and its skills never do these

  • Generate exploit code or proof-of-concept attack code
  • Offer offensive bypass or weaponization guidance
  • Use discovered secrets against any system
  • Execute target-project code, scripts, or binaries— review is read-only

Use it only on code you own or are explicitly authorized to review.

Common questions

The details that matter.

Why is a filesystem allowlist required?

The allowlist prevents an agent prompt from turning a local MCP server into a general filesystem reader. Set SECURE_MCP_ALLOWED_ROOTSto the narrowest parent directories that contain repositories you intend to review.

How do I confirm a finding in code?

Open the cited file at the cited line, trace the data flow from source to sink, and check runtime configuration. High and critical findings are never reported as confirmed until the evidence is verified this way.

Can I request a stack pack or a tool?

Yes — stack packs and tool coverage evolve on a roadmap. Open a GitHub feature request with the stack or surface you need and where it fits in the defensive audit workflow.

How do I report a product issue?

Provide a minimal reproducible local fixture, the tool and input shape, and the structured coverage report. No live credentials, sensitive source, or exploit code — keep reports focused on containment, read-only behavior, and misleading audit results.

Which stacks are supported?

Current focus: TypeScript and Next.js (App Router, Server Actions, middleware) and Swift and SwiftUI, with Expo and React Native detection. More surfaces are planned.

Stuck on something specific? Contact support. Or read the full documentation.