appsec-toolbox
Runs Trivy against the mounted target repository through the security.repository capability, producing a native trivy.json report of repository findings.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@appsec-toolboxrun the full security audit and summarize the findings"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
appsec-toolbox-mcp
Let an AI agent audit code you do not trust, without giving it a shell, a path to choose, or the repository's code to run.
Ten pinned security scanners behind eight parameterless MCP tools, in one hardened container. The audited repository is treated as the attacker. The agent only ever collects evidence.
Recorded from examples/agent_demo.py against examples/vulnerable-sample. Waiting time is shortened; the real scan time is in the last line.
In 30 seconds
What it is. Semgrep, Gitleaks, OSV-Scanner, Trivy, Checkov, Syft, and language specialists (Bandit, FindSecBugs, njsscan, gosec) exposed to any MCP client as fixed capabilities:
security.sast,security.secrets,security.dependencies, and so on.The threat model. The repository under audit is hostile: it controls every file the scanners parse and every string the agent reads back. So the agent gets nothing to steer: no arguments, no target path, no shell, no way to run the repository's build or code.
What you get. Native scanner reports, a run manifest that ties each report's SHA-256 to a recomputable fingerprint of the scanned tree, and an audit log of every tool call.
Related MCP server: agent-sec-mcp
Engineering highlights
Each claim links to the code or test that proves it.
Problem | Approach | Proof |
A prompt-injected agent with a shell can do anything. | The agent's whole surface is eight parameterless tasks, governed by Makefile MCP. Maintenance targets exist but are refused. |
|
Scanning untrusted code usually runs it: | Strictly passive analysis: no build, install, or dependency resolution; Go runs with | |
A hostile repository can silence its own findings with | Every scanner runs on toolbox-owned configuration. Inline suppressions are disabled where the scanner allows it, and every marker found is inventoried for the reviewer either way. | settings table, |
Evidence is only worth something if it is tied to what was scanned. | The manifest fingerprints the tree exactly like | |
One malformed file should not let the target stop the audit. | Input a scanner cannot read because of the target (an unloadable Go package, a corrupt lockfile) becomes a recorded coverage limit: not a failed bundle, and not a fake clean result. | |
Results should be reproducible, and a compromised scanner should have nowhere to send the code. | Offline mode: fetch rule and advisory data once, then scan under | |
A security tool is a supply-chain target. | Every downloaded binary is checked against its published SHA-256 per architecture; the base image is pinned by digest; Actions are pinned by commit; release jobs that run project code hold no write token; images carry signed build provenance. |
Verification in layers. Unit tests cover the scripts. A smoke test drives the Makefile through Makefile MCP with fake scanners whose stubs fail if any hardening flag is missing. The image test runs the real scanners against a known-vulnerable sample, a hostile sample that tries every attack above, and offline mode, under the documented resource limits. Independent adversarial reviews attacked the image; every confirmed finding was fixed with a regression test, and what remains is written down in the threat model.
Quick start
IMAGE=ghcr.io/ai-ronin-systems/appsec-toolbox-mcp:0.3.0
docker pull "$IMAGE"
gh attestation verify "oci://$IMAGE" --owner ai-ronin-systemsOffline mode, the resource limits, and the target-settings hardening are on main and ship in the next release. To use them now: docker build -t appsec-toolbox-mcp:dev . and IMAGE=appsec-toolbox-mcp:dev.
Run it as an MCP stdio server against one repository:
docker run --rm -i \
--read-only --cap-drop=ALL --security-opt=no-new-privileges:true \
--tmpfs /tmp:rw,nosuid,nodev,size=3g --memory=6g --pids-limit=512 \
--user "$(id -u):$(id -g)" \
-v "$PWD/my-project:/runner/target:ro" \
-v "$PWD/appsec-output:/runner/output:rw" \
"$IMAGE"Register the same command as a stdio server in any MCP client:
{
"mcpServers": {
"appsec-toolbox": {
"command": "docker",
"args": ["run", "--rm", "-i", "--read-only", "--cap-drop=ALL",
"--security-opt=no-new-privileges:true",
"--tmpfs", "/tmp:rw,nosuid,nodev,size=3g", "--memory=6g", "--pids-limit=512",
"-v", "/abs/path/my-project:/runner/target:ro",
"-v", "/abs/path/appsec-output:/runner/output:rw",
"ghcr.io/ai-ronin-systems/appsec-toolbox-mcp:0.3.0"]
}
}
}Compose, offline mode, language selection, and every evidence file are in Usage.
How it works
untrusted repository (read-only)
|
v
/runner/target
|
v
trusted Makefile + Makefile MCP
| | | | | |
Semgrep Gitleaks OSV Trivy Checkov Syft
|
+---- language profile selection ----+
| | | |
Bandit FindSecBugs njsscan gosec
Python Java Node/JS Go
|
v
/runner/output reports, run-manifest.json, suppressions.json, audit logThe operator mounts exactly one repository at /runner/target and one writable directory at /runner/output. The audited path is never an MCP parameter, so the agent has no host-path capability. A trusted Makefile holds every scanner command; Makefile MCP decides which of its targets the agent may call. Language specialists are picked by detection (APPSEC_LANGS=auto) or by the operator, never by the agent.
Capability | Tool | Evidence |
| everything below | complete bundle |
| Semgrep + suppression inventory |
|
| Gitleaks |
|
| OSV-Scanner |
|
| Trivy |
|
| Checkov |
|
| Bandit, FindSecBugs, njsscan, gosec as applicable |
|
| Syft |
|
Threat model
The audited repository is the attacker, and the agent reading its reports may be steered by it. Read the threat model: attacker goals, sixteen threats with their controls and residual risks, what is and is not guaranteed, and an operator checklist.
Protected | Not protected |
Target builds, installs, hooks, and Makefiles never run. | Scanner parser bugs; the container is the boundary. |
Target-owned scanner settings files cannot suppress findings or load code. | Inline |
The agent cannot pick the target or run anything but the eight scans. | An agent that misreports what the reports say. |
No credentials in the container; read-only, unprivileged, non-root, resource-capped. | Exfiltration by a compromised scanner in online mode. Offline mode runs with no network. |
Each run's manifest ties report digests to a fingerprint of the scanned tree. | Tampering by anyone who can write |
Design choices
Evidence, not verdicts. Reports stay in each scanner's native format. The toolbox never grades, deduplicates, or normalizes findings; a consumer does that with the full evidence.
One closed set of scanners. Four language profiles, no plug-in framework, no user-defined pipelines. Generic SCA stays with OSV and Trivy; specialists add a different analysis engine, not a duplicate one.
Coverage gaps are recorded, never papered over. A source-only Java project gets no FindSecBugs pass, because the toolbox will not compile untrusted code; the manifest says so.
Everything pinned. Scanner versions are pinned and updated one at a time against known-positive and hostile fixtures (update policy).
It is not an autonomous auditor, an LLM agent, a DAST engine, a credential manager, a report normalizer, or a shell server.
Part of a larger system
appsec-audit-hound (planned) decides why to scan, correlates evidence, writes findings
| MCP
appsec-toolbox-mcp collects governed, passive evidence <- this repository
| built on
makefile-mcp exposes trusted Make targets to agents, deny-by-defaultMakefile MCP is published on PyPI and the official MCP Registry, with its own threat model.
Documentation
Document | What it covers |
Attacker goals, threats and controls, guarantees, limits, operator checklist | |
Running, tools and evidence files, language profiles, offline mode, scanner behaviour, network use, versions, development | |
Trust boundary, ownership, design rules | |
Pinned versions, settings each scanner ignores, update policy | |
Supported versions and private vulnerability reporting | |
Released and unreleased changes | |
How to add a scanner without widening the boundary |
Development
pipx install pytest==8.4.2 && pipx install ruff==0.14.0
make test # ruff, unit tests, smoke test
make image
make test-image # the real image: known positives, hostile sample, offline modeMore in Usage.
License
Apache-2.0.
This server cannot be deployed
Maintenance
Related MCP Connectors
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Run verified read-only code tools: quant diagnostics + agent-ops preflight, no source exposure.
Security tools for AI agents: scan MCP servers, validate HDP delegation chains, audit releases.
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables agents to audit and safeguard repositories by detecting dependency pinning issues, license compliance problems, hardcoded secrets, and dead code through MCP tools.4MIT
- AlicenseNot gradedqualityCmaintenanceEnables authorized security auditing of AI-agent supply chains and agent-facing surfaces: deterministic local skill-bundle audits against eight attack patterns, secrets scanning, and scope-gated read-only recon of agent endpoints and MCP surfaces.MIT
- AlicenseAqualityBmaintenanceEnables AI agents to run container forensics, generate container obituaries, and audit git repository history as native MCP tools, producing markdown reports they can reason over.34MIT
- AlicenseBqualityBmaintenanceEnables AI agents to run deterministic, fully local static security and compliance audits of code, configurations, and dependencies through 32 MCP tools covering 24 vulnerability categories. It also detects the project stack, generates risk reports and checklists, suggests stack-aware remediations, and re-validates fixes to confirm vulnerabilities were eliminated.321MIT