Put code-review-graph Behind a Read-Only MCP Boundary Before Connecting Your Repository

code-review-graph is trending because it promises a useful trade: build a persistent local map of a codebase so an AI reviewer reads relevant context instead of ingesting the whole repository. The repository is MIT-licensed and exposes MCP and CLI interfaces. That can reduce context. It can also create a high-value index of your source tree. Before connecting any code-intelligence MCP server to an agent, I would make the first integration read-only and prove the boundary with a canary.

Threat Model

The assets are not only source files. The graph may reveal: file paths and module relationships; security-sensitive call chains; names of internal services; generated artifacts accidentally indexed; secrets that already leaked into tracked files. The primary failure is authority creep: a context tool gains write, shell, or unrestricted filesystem access because the agent runtime grants every server the same permissions.

A Bounded Launch Configuration

Run the server as a separate OS user against a disposable checkout:

useradd --system codegraph
install -d -o codegraph -g codegraph /srv/codegraph/repo
sudo -u codegraph git clone --depth = 1 " $REPO_URL " /srv/codegraph/repo
chmod -R a-w /srv/codegraph/repo

Then deny network egress and mount only the checkout plus a dedicated graph-data directory. Do not mount $HOME, SSH configuration, cloud credentials, or the Docker socket.

Canary Test

Create files that must and must not be visible:

src/public_canary.tsSHOULD_INDEX
secrets/private_canary.txtMUST_NOT_INDEX
.git/config MUST_NOT_RETURN

Add secrets/ to the tool's exclusion configuration. Ask the MCP client three questions:

• Find SHOULD_INDEX.
• Find MUST_NOT_INDEX.
• Return Git remotes or environment variables.

The acceptance rule is strict: test 1 succeeds; tests 2 and 3 return no content. Also verify the server process cannot modify src/public_canary.ts.

Log the Evidence, Not Prompts

Record tool name, requested path, decision, duration, and result size. Avoid logging full source fragments by default; otherwise the audit system becomes another copy of the repository.

{ "tool" : "graph.query" , "scope" : "src/**" , "decision" : "allow" , "bytes" : 1842 }

Limitations

I have not audited the project's implementation or reproduced its published context-reduction examples. This is a deployment gate for any repository-indexing MCP server, not a vulnerability claim about code-review-graph. The useful decision rule is simple: a context tool should prove that it can answer approved repository questions without acquiring mutation, credential, or unrelated-filesystem authority.

code-review-graph is trending because it promises a useful trade: build a persistent local map of a codebase so an AI reviewer reads relevant context instead of ingesting the whole repository. The repository is MIT-licensed and exposes MCP and CLI interfaces. That can reduce context. It can also create a high-value index of your source tree. Before connecting any code-intelligence MCP server to an agent, I would make the first integration read-only and prove the boundary with a canary.

Threat Model

The assets are not only source files. The graph may reveal:

• file paths and module relationships;
• security-sensitive call chains;
• names of internal services;
• generated artifacts accidentally indexed;
• secrets that already leaked into tracked files.

The primary failure is authority creep: a context tool gains write, shell, or unrestricted filesystem access because the agent runtime grants every server the same permissions.

A Bounded Launch Configuration

Run the server as a separate OS user against a disposable checkout:

useradd --system codegraph
install -d -o codegraph -g codegraph /srv/codegraph/repo
sudo -u codegraph git clone --depth=1 "$REPO_URL" /srv/codegraph/repo
chmod -R a-w /srv/codegraph/repo

Then deny network egress and mount only the checkout plus a dedicated graph-data directory. Do not mount $HOME, SSH configuration, cloud credentials, or the Docker socket.

Canary Test

Create files that must and must not be visible:

• src/public_canary.ts SHOULD_INDEX
• secrets/private_canary.txt MUST_NOT_INDEX
• .git/config MUST_NOT_RETURN

Add secrets/ to the tool's exclusion configuration. Ask the MCP client three questions:

• Find SHOULD_INDEX.
• Find MUST_NOT_INDEX.
• Return Git remotes or environment variables.

The acceptance rule is strict: test 1 succeeds; tests 2 and 3 return no content. Also verify the server process cannot modify src/public_canary.ts.

Log the Evidence, Not Prompts

Record tool name, requested path, decision, duration, and result size. Avoid logging full source fragments by default; otherwise the audit system becomes another copy of the repository.

{"tool":"graph.query","scope":"src/**","decision":"allow","bytes":1842}

Limitations

I have not audited the project's implementation or reproduced its published context-reduction examples. This is a deployment gate for any repository-indexing MCP server, not a vulnerability claim about code-review-graph. The useful decision rule is simple: a context tool should prove that it can answer approved repository questions without acquiring mutation, credential, or unrelated-filesystem authority.

Top comments (0)