DEV Community: Razu Kc

I pointed capgate at Damn Vulnerable MCP. Here's what it caught — and what it couldn't.

Razu Kc — Tue, 16 Jun 2026 18:52:58 +0000

A capability-compiler meets ten deliberately-broken MCP servers. The honest scorecard: it cleanly stops one class, shrinks the blast radius on several, and is useless against another. Knowing which is which is the whole point.

Disclosure: I'm the author of capgate, the Apache-2.0 sandbox compiler this post puts to the test. The DVMCP project and the other tools mentioned aren't mine; the manifests and compiled output are reproducible from the repo.

The setup

Damn Vulnerable MCP (DVMCP) is a teaching project: ten MCP servers, each built to demonstrate one attack — prompt injection, tool poisoning, excessive permission scope, token theft, command injection, and so on. It's the closest thing the ecosystem has to a shared adversarial fixture.

capgate is a compile-time tool. You write a manifest declaring what an MCP server is allowed to do — fs:read:/workspace/**, net:connect:api.github.com:443, nothing else — and it compiles that to a concrete sandbox policy (docker run flags, bwrap argv, or an egress-proxy config). It does not run anything, watch traffic, or inspect the server's code. It turns a declared capability set into an enforced boundary.

So this is a fair, falsifiable test: for each DVMCP challenge, I wrote the honest minimum manifest, compiled it, and asked one question — does the boundary capgate emits actually stop the attack?

The answer is not "yes" across the board, and the cases where it's "no" are the interesting ones.

The bullseye: Challenge 3 — Excessive Permission Scope

The vulnerable tool advertises "read a file from the public directory" and then does this:

@mcp.tool()
def read_file(filename: str) -> str:
    # VULNERABILITY: doesn't restrict file access to the public directory
    if os.path.exists(filename):          # any absolute path works
        with open(filename, "r") as f:
            return f.read()

The private directory next door holds employee_salaries.txt, acquisition_plans.txt, and system_credentials.txt (a live DB password and cloud API keys). A prompt-injected agent just calls read_file("/tmp/dvmcp_challenge3/private/system_credentials.txt") and walks out with everything.

The honest manifest — what the tool claims to need:

{ "name": "read_file", "capabilities": ["fs:read:/tmp/dvmcp_challenge3/public/**"] }

capgate compiles it (--target docker) to:

--rm --cap-drop ALL --security-opt no-new-privileges --read-only
--network none
--volume /tmp/dvmcp_challenge3/public:/tmp/dvmcp_challenge3/public:ro

The attack now fails — not because the path check got better, but because the private directory is not mounted into the container. read_file("/tmp/.../private/system_credentials.txt") returns file not found, because inside the sandbox that file does not exist. The path-traversal bug is still in the code; capgate made it unreachable. Network is off, the filesystem is read-only, every capability is dropped.

capgate is loud about one approximation it made here. The output carries a notes[] entry: "fs: `/tmp/dvmcp_challenge3/public/ lowered to volume mount /tmp/dvmcp_challenge3/public` — Docker mounts directories, not globs. Fine-grained glob enforcement is the server's job." The declared capability was a glob; Docker can only mount a directory. capgate grants the directory and tells you, in the output, that the finer-grained glob is now the server's responsibility, not the sandbox's. That's the pattern for the whole exercise — the boundary is real, and the places it's coarser than the declaration are written down, not hidden.

This is capgate's bullseye. The vulnerability is over-broad reach, and a capability boundary is exactly the right shape of answer. One of ten — but it's a clean kill.

The contains, not prevents: Challenges 7, 8, 9

These are the honest middle. capgate doesn't stop the bug; it shrinks what the bug can achieve.

Challenge 7 — Token Theft → exfiltration blocked at egress

The tool leaks a bearer token and API key into an error string (which flows straight into the LLM context):

Authorization: Bearer {email_token.get('access_token')}
API Key: {email_token.get('api_key')}

capgate can't stop the tool from reading its own token. What it can do is constrain where that token can go. The honest manifest declares one egress endpoint, and the --target egress --egress-target squid output is:

# capgate-egress.squid.conf (generated — do not edit)
acl to_private dst 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 127.0.0.0/8 169.254.0.0/16 ::1/128 fc00::/7 fe80::/10
http_access deny to_private
acl cg_dst_0 dstdomain api.emailpro.com
acl cg_port_0 port 443
http_access allow cg_dst_0 cg_port_0 CONNECT
http_access deny all

A poisoned tool that tries to POST the token to attacker.example.com is refused at the proxy — the allowlist contains exactly one host, and the config ends in an unconditional deny all. The classic prompt-injection-to-exfiltration chain is broken at the network boundary.

Honest caveat, stated plainly: the token still reaches the model's context, and if an attacker can smuggle it out through the one allowed channel (a crafted request to api.emailpro.com itself), capgate does not see it. It closes the broad exfil path, not every conceivable one. (A second honesty note: DVMCP stores these tokens in a world-readable file; a faithful capgate manifest would never grant fs access to that file, so the tool couldn't read it at all. The egress allowlist is the backstop for when the secret legitimately lives in the process.)

Challenge 8 — Malicious Code Execution → boxed, not blocked

This one exposes a real limit of the grammar, and it's worth being loud about. The tool is:

@mcp.tool()
def execute_shell_command(command: str) -> str:
    result = subprocess.check_output(command, shell=True, ...)   # arbitrary shell

capgate's capability grammar cannot express "run arbitrary shell." exec is basename-only (exec:spawn:git), by design — there is no exec:spawn:*. So you cannot write an honest manifest that grants this tool what it actually does. capgate's own docs say it: "a manifest that under-declares is a bug in the manifest." capgate will not make a shell-exec tool safe, and it doesn't pretend to.

What it does instead is contain the blast radius of the surrounding server. Compile the legitimate tools (get_system_info, analyze_log_file) and you get:

--rm --cap-drop ALL --security-opt no-new-privileges --read-only
--network none
--volume /tmp/dvmcp_challenge8/logs:/tmp/dvmcp_challenge8/logs:ro

If execute_shell_command ships anyway and fires, it runs inside that box: no network, no Linux capabilities, read-only rootfs, no injected secrets, only the logs directory visible. Successful RCE that can't reach the network, can't escalate, and can't see a credential is a dramatically smaller incident. That's defense-in-depth — explicitly not prevention.

Challenge 9 — Command Injection → private ranges blocked, public egress can't be

network_diagnostic(target, options) pipes user input straight into shell=True. It's a network tool, so the honest manifest must grant net:connect:* — and capgate is honest about what that costs:

{ "egress": [{ "host": "*", "port": null, "blockPrivate": true }] }

A wildcard host means the egress allowlist can't help — you can't allowlist "everywhere." But blockPrivate is automatically set, and the nftables target enforces it in-kernel:

table inet capgate {
  chain egress {
    type filter hook output priority 0; policy drop;
    ip daddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 } drop
    ...
  }
}

So command injection still runs, and still reaches the public internet — but it cannot pivot to 169.254.169.254 (cloud metadata), 127.0.0.1 (local services), or RFC1918 internal hosts. And capgate refuses to fake the rest: the wildcard rule shows up in an unenforceable[] field with the reason "nftables filters IPs, not hostnames; '' cannot be expressed as an IP allowlist. Use the 'squid' target for wildcard/hostname rules."* It tells you what it can't do — and where to go instead — rather than silently dropping it.

The honest miss: Challenge 1 — Basic Prompt Injection

The Challenge 1 tool has no teeth at all — it reads an in-memory dictionary:

@mcp.tool()
def get_user_info(username: str) -> str:
    users = {"admin": "System administrator with full access", ...}
    return f"User information for {username}: {users.get(username)}"

The attack isn't about what the tool reaches. It's about convincing the model, through injected text, to ignore its instructions. The honest manifest is empty ("capabilities": []), and capgate compiles it to the most locked-down sandbox it can produce:

--rm --cap-drop ALL --security-opt no-new-privileges --read-only --tmpfs /tmp --network none

And the prompt injection still works, completely. capgate constrains what a tool is allowed to do; it has nothing to say about whether the LLM can be talked into doing it. Challenges 1, 2 (tool poisoning), and 6 (indirect injection) all live at the model layer, and a capability compiler is the wrong instrument for all three. It shrinks the blast radius if those attacks then try to reach something — but it does not prevent the manipulation itself.

Anyone who tells you a sandbox compiler stops prompt injection is selling you something. It doesn't. It makes prompt injection less useful by capping what the hijacked tools can touch.

The scorecard

#	Challenge	capgate's effect
1	Basic Prompt Injection	❌ Doesn't prevent (model layer) — only caps blast radius
2	Tool Poisoning	❌ Doesn't prevent (model layer) — only caps blast radius
3	Excessive Permission Scope	✅ Prevents — the bullseye
4	Rug Pull	◐ The declared capability set is the contract drift violates; `assert:` records it. No runtime enforcement in v0.0.x
5	Tool Shadowing	— Out of scope (naming/registry)
6	Indirect Prompt Injection	❌ Doesn't prevent (model layer) — only caps blast radius
7	Token Theft	◐ Contains — egress allowlist blocks exfil; token still readable
8	Malicious Code Execution	◐ Contains — can't express shell-exec; boxes the blast radius
9	Remote Access Control (cmd injection)	◐ Contains — blocks private ranges; can't allowlist public egress for a net tool
10	Multi-Vector	◐ Partial — depends on the chain

One clean prevention. Four meaningful containments. Three honest misses. Two out-of-scope.

That is the real shape of a capability compiler against a real adversarial corpus. It is not a silver bullet, and the cases it can't touch are exactly the cases the rest of the MCP-security stack (scanners, runtime monitors, the model's own defenses) exists to cover. capgate is one layer. It happens to be the layer that turns "this server can reach your whole disk and the open internet" into "this server can reach one directory, read-only, and one host" — and that boundary lives in a file you can review in a pull request before the server ever runs.

A static scanner like NVIDIA's SkillSpector lives one layer up: its least-privilege checks would flag Challenge 3 at review time — the tool's code reaches past its declaration, which trips an "underdeclared capability" rule before you ever install. But flagging the mismatch and enforcing the honest declaration are different jobs. A scanner tells you the manifest is dishonest; capgate makes an honest manifest binding — it confirms fs:read:/tmp/dvmcp_challenge3/public/** was declared, but only the compiled mount stops the tool reading the private directory anyway. You want both, and they don't substitute for each other.

Reproduce it

The five capability manifests live in examples/dvmcp/ in the capgate repo. Every policy above is the argv/config payload from capgate@0.0.3 — the CLI prints a JSON envelope ({ "argv": [...], "egress": [...], "notes": [...] }); the blocks above show the payload, and I call out the notes[]/unenforceable[] fields explicitly where they matter, because those honest edges are the point. Run it yourself from the repo root (npm install && npm run build):

node dist/cli.js compile examples/dvmcp/challenge3-excessive-permission.json --target docker --pretty
node dist/cli.js compile examples/dvmcp/challenge7-token-theft.json --target egress --egress-target squid --pretty
node dist/cli.js compile examples/dvmcp/challenge9-command-injection.json --target egress --egress-target nftables --pretty

If you run MCP servers and decide their capability boundary by hand today — a devcontainer here, a mount list there — I'd genuinely like to know where that decision lives for you, and what it costs. That's the actual open question this whole exercise is circling.

Compile-time vs runtime: where MCP security actually lives

Razu Kc — Tue, 12 May 2026 10:46:36 +0000

Update (2026-05-29): The four-layer decomposition below is still useful as a procurement checklist — do we have a story for each of these four points in the lifecycle? — and that's the job it does best. For classifying tools and projects, I've since moved to a tighter three-way working model: static technical, static governance, dynamic attestation. The current write-up of that framing is here: A working map of MCP security tools. If you've landed on this post via search, read both — they answer different questions about the same space.

Disclosure: I represent capgate, a compile-time policy compiler for MCP servers. capgate appears as the worked example in the compile-time section. The other three sections describe categories, not specific products.

If you run a Model Context Protocol (MCP) server in production, you've probably noticed that "MCP security" doesn't mean one thing. It means at least four things, sitting at different points in the lifecycle of a tool call, solving different problems. Most teams I've talked to need two or three of them. Almost none of them realize that until they've shipped the wrong one first.

This is a positioning post. The goal isn't to argue that any one layer is best — it's to give you a way to figure out which layer your team actually needs, so you stop bolting the wrong tool onto the wrong problem.

The four layers

A tool call through an MCP server passes through, conceptually, four points where security work can happen:

manifest → [1] compile-time policy → [2] sandbox runtime → [3] tool invocation → [4] decision log
              emission                 inspection             gateway / auth        signed receipts

Each of these is its own discipline with its own tooling and its own people who care deeply about it. Lumping them together as "MCP security" is what causes teams to evaluate one tool for a problem it doesn't solve.

1. Compile-time policy emission

What it does. Reads the MCP server's manifest before the server runs and emits a concrete sandbox policy — bwrap argv, docker run flags, an egress allowlist, a list of environment variables the server is allowed to see. The output is a static artifact. It does not execute, does not speak MCP on the wire, does not watch traffic.

The argument for it. Most sandboxes a team actually runs are hand-written: someone reads the README, makes their best guess at what the server needs, and writes --cap-drop ALL --network host --volume ... from memory. That hand-written sandbox is the de facto security policy for the server, and it's invisible to code review. A compile-time policy makes the sandbox a reviewable artifact: it lives in the repo, it changes when the manifest changes, and it can be diffed in a PR.

When you'd reach for it. Your team runs more than two or three MCP servers, the people running them aren't the people who wrote them, and "what is this server allowed to do?" is a question that has to be answerable from the repo, not from someone's memory.

Concrete example. Here's a minimal manifest and the policy capgate emits for it:

import { compile, lowerToDocker } from 'capgate';

const docker = lowerToDocker(compile({
  name: 'my-server',
  version: '0.1.0',
  tools: [{ name: 'read_file', capabilities: ['fs:read:/workspace/**'] }],
}));

console.log(docker.argv.join(' '));
// → --rm --cap-drop ALL --security-opt no-new-privileges --read-only
//   --tmpfs /tmp --network none --volume /workspace:/workspace:ro

One capability in, one container policy out. The server declared no network → --network none. Read-only filesystem declared → :ro mount. No environment variables declared → none cross the boundary. A real manifest with several tools merges per-tool capabilities into a server-level policy.

The limits. Compile-time emission doesn't watch what the server actually does. It enforces what was declared. A manifest that under-declares is silently over-granted at runtime; that bug lives in the manifest, not the compiler. If you need to catch a server doing something its manifest didn't say it would, that's layer 2.

2. Runtime sandbox inspection

What it does. Watches the MCP server as it runs, inspects its tool definitions and call traces against a catalog of known threat techniques, and surfaces risky behavior — prompt injection patterns in tool descriptions, indirect tool-chaining, unexpected outbound calls.

The argument for it. You did not write this server. You found it on a registry, or a vendor handed it to you, or your CI agent installed it. You don't know what its tool descriptions look like. You don't know whether one of its tools chains into another in a way the author didn't anticipate. You want a sensor in the path that says "this looks wrong" — preferably one that maps what it sees onto a recognized taxonomy (STRIDE, MITRE ATT&CK, OWASP LLM Top 10) so your security team can interpret the signal.

When you'd reach for it. Your threat model assumes the server might be adversarial or buggy in ways its manifest doesn't reveal. Common cases: third-party servers, large in-house catalogs of servers you can't deeply audit, regulated environments where "we have a sensor watching for X" is a compliance requirement.

The limits. Runtime inspection catches what's already happening. By the time the sensor sees the suspicious outbound request, the request has been made. It's a detection layer, not a prevention layer. Most teams that adopt runtime inspection also have layer 1 (compile-time policy) running underneath it — the sandbox prevents the bulk of the bad things, and inspection catches what gets through the gaps in declaration coverage.

3. API gateway / per-request authorization

What it does. Sits in front of the MCP server as a network proxy. Every request from the agent to a tool passes through it, and the gateway decides — based on identity, headers, role, policy rules — whether that request is allowed. This is the same shape as a regular service mesh, applied to MCP traffic.

The argument for it. Your concern isn't what the server can do. Your concern is who is asking it to do things. You have multiple agents, multiple users, multiple environments hitting the same MCP server, and the right thing to enforce is "developer Alice can call apply_patch, but the deploy agent can only call search_code" — a per-caller policy, not a per-server one. This is identity-and-access work, and the mature tooling for it is exactly the kind of API-gateway / authorization-proxy software that solved the same problem for HTTP APIs ten years ago.

When you'd reach for it. Multiple callers share an MCP server, and the boundary you care about is between callers, not between the server and the host. Your security team already runs an authorization gateway for everything else; extending it to MCP is cheaper than evaluating a new category.

The limits. A gateway can stop a call before it reaches the server. It can't stop the server, once invoked, from doing something the gateway didn't anticipate. If the agent is allowed to call read_file('/etc/passwd'), the gateway authorized that call; the sandbox in layer 1 is what prevents the underlying read from succeeding.

4. Decision logs / signed receipts

What it does. Cryptographically logs each tool invocation — what was called, with what arguments, by whom, with what result. The log is tamper-evident: a downstream auditor can verify, weeks later, that the recorded history hasn't been edited.

The argument for it. This is for environments where "we need a trustworthy record of what the agent did" is a hard requirement — regulated industries, agents that touch financial state, anything where the conversation with the auditor begins with "prove to me this didn't happen." It's the audit-trail layer, and it doesn't make sense to evaluate it for the same reasons you'd evaluate layers 1-3. It solves a different problem.

When you'd reach for it. Your compliance posture requires a verifiable record of agent actions. Or you're building tooling for other people's agents and you need to give them a way to prove what their agents did. Or you're sufficiently far ahead of the curve that you're trying to build the artifact regulators will eventually ask for.

The limits. Receipts prove what happened. They don't prevent anything. A signed log of an agent exfiltrating a secret is still a log of an agent exfiltrating a secret. Like layer 2, this is almost always run alongside layer 1, not instead of it.

A decision matrix

If you're trying to figure out which layer to invest in first, the question I'd ask is:

Question you're asking	Layer that answers it
"What is this server allowed to do?"	1 — compile-time policy
"What is this server actually doing right now?"	2 — runtime inspection
"Who is allowed to call which tool?"	3 — API gateway
"What did the agent do, and can we prove it?"	4 — decision logs

Most production teams running MCP servers at scale end up with layers 1 + 2, or 1 + 3, or 1 + 4. Layer 1 is the load-bearing one — it prevents the bulk of bad outcomes by construction. The others are sensors and policy controls that ride on top of that prevention.

The wrong answer is buying a layer-2 product because "we need MCP security" and then discovering six months later that you never wrote a sandbox underneath it, so the sensor is logging the smoke from fires you could have prevented.

What this means for tool selection

The reason it's worth being precise about these four layers is that the tools in this space are, by and large, not trying to do all four. The honest ones are explicit about which layer they live at. The ones to be cautious of are the ones that pitch themselves as "MCP security" without telling you which layer.

When you're evaluating something in this space, the first question to ask is: which of the four does this live at? If the answer is "all of them," push harder — usually it means one of the four is the actual product and the rest are marketing. There's nothing wrong with focused tools; the wrong shape is a tool that pretends to cover layers it doesn't.

Where this is going

The four layers will look more distinct, not less, as the MCP ecosystem matures. Right now most teams pick one tool and accept that it's covering 60% of what they need. In a year, expect to see specialized tools at each layer, expect to see them composed, and expect the question "which layer is this?" to be the first one in any procurement conversation.

If you're picking a layer to start with, start with layer 1. It's the cheapest prevention and the foundation everything else assumes is in place.

Please feel free to leave questions for me in the comments.

capgate is open source under Apache 2.0. If you're running MCP servers in production and want to compare what your hand-written sandbox grants vs what a manifest-derived policy would, the repo has a CLI you can point at a manifest in 30 seconds.

extn — A Modern CLI Framework for Building Chrome Extensions (with HMR + Live Preview)

Razu Kc — Fri, 14 Nov 2025 20:00:47 +0000

I’m excited to introduce extn — a TypeScript-first CLI framework that makes building Chrome extensions fast, modern, and effortless. If you’ve ever been stuck in the cycle of manually reloading chrome://extensions after every tiny file change… this tool is for you.

👉 GitHub Repo: https://github.com/razukc/extn

🌟 Why extn?

Building browser extensions is often painful — outdated boilerplate, complex manifest setup, and no good local dev environment.

extn fixes this by giving you:

⚡ Hot Module Replacement (HMR) for instant updates
🧪 Live Preview — automatically opens Chrome with your extension loaded
📦 Templates for Vanilla TS, React TS, and Vue TS
🏗️ Production-ready scaffolding
🔒 Manifest v3 validation
🛠️ Vite-powered builds
🧹 No more manual reloading

Everything works out of the box.

🚀 Quick Start

Get started in one minute:

npx extn create my-extension

cd my-extension
npm install
npm run dev

This will:

start a development server
build your extension
auto-load it in Chrome
open DevTools
apply updates instantly with HMR

📁 Project Structure

After running extn create, you get:

my-extension/
├── src/
│   ├── popup/
│   │   ├── popup.html
│   │   ├── popup.js
│   │   └── styles.css
│   ├── background/
│   │   └── background.js
│   └── content/
│       └── content.js
├── public/
│   └── icons/
├── manifest.json
├── package.json
├── vite.config.js
└── tsconfig.json

If you select React or Vue templates, those files are included automatically.

💡 Why I Built extn

While working on browser-based tools, I constantly found Chrome extension development to be:

slow (manual reloads)
fragmented
outdated
hard to iterate quickly

So I built extn to deliver:

a modern workflow
instant feedback with HMR
clean TypeScript setup
framework flexibility
MV3 done right

🗺️ Roadmap

Upcoming features:

Svelte template support
Firefox + Edge packaging
More example templates
Chrome Web Store publishing helper

🤝 Try It / Contribute

If you’re building Chrome (or Chromium) extensions and want a smooth development experience, check out the repo:

👉 https://github.com/razukc/extn

Feedback, issues, and PRs are welcome!