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 (1)
Good gate. I'd test exclusion at two separate boundaries: ingestion and retrieval. A query-time filter can hide
secrets/today while the graph still retains its paths, symbols, embeddings, or edges and exposes them later through summaries or neighboring-node traversal.The canary matrix should include symlinks escaping the checkout, case/Unicode path variants, submodules, generated archives, Git metadata/history, deleted files after incremental re-indexing, and a file moved from allowed to denied scope. After each change, prove both direct lookup and indirect graph traversal cannot recover the forbidden token, then rebuild from a fresh process to rule out stale index state.
Source text is also untrusted input. A comment or README can contain instructions aimed at the reviewing agent, so results need provenance and a clear data/instruction boundary; retrieved repository text must never widen tool permissions. I would version the exclusion policy and repository commit in each graph generation, encrypt the graph store, give it an explicit retention/deletion path, and verify network denial from inside the server namespace. Read-only source mounts prevent mutation, but containment also has to cover what the derived index remembers and where it can send it.