VectorCraft 0.17.0

What it is, and why it was worth checking

VectorCraft is an open-source vector editor with a desktop app, a command-line tool and a built-in MCP server that lets an AI agent draw, inspect and export documents. An MCP server hands an agent the app's reach — files, helper programs — so it is exactly the kind of component worth checking before it is connected to anything.

Intake confirmed the copy: the source downloads were byte-identical to repository commits, the installer matched its published checksum, and it carries a Microsoft-verified signature, re-verified after the probes.

The scorecard

What the probes showed

Fifteen probes, each in a fresh Windows Sandbox with canary credentials planted, observed with Process Monitor and a once-a-second connection and process poll. All fifteen were within scope. In the probes:

• No network contact, in three online launches. A string search of the shipped binaries found no updater and no HTTP or TLS library — which shows those names are absent, not that no network code of any kind exists.
• Nothing set to start at login: no Run key, scheduled task or service added.
• No canary credential's content read.
• The control port listened on the loopback address only (127.0.0.1:7979): reachable by programs on the same computer, not from the network.
• Only the documented helper programs started: PowerShell print scripts, the printer setup dialog and Explorer.
• The text it shows an agent — 32 tools, 5 prompts, 3 resources — was accurate, with nothing addressed to the agent's own rules.

The MCP finding

By default, the MCP server's file tools reach any path your account can: an unscoped test export landed on the Desktop. With --automation-read-root and --automation-write-root set, every attempt to reach outside those folders was refused:

• 9 of 9 out-of-root calls through the four file tools, including .. traversal.
• 32 of 32 through six path-taking commands run by id, each via four routes (run_command, command_run, command_batch, invoke_menu).
• 4 of 4 through a symlink and junctions placed inside the roots — the server resolves each link to its real target before checking it.

One nuance, stated plainly: to resolve paths before refusing them, the scoped server opened two canary files for their attributes only. It read or wrote no content. The verdict uses that content-access reading; under the probe plan's original wording, which counted any out-of-root file "opened" as a failure, those events could be classified as failures.

Why Medium, not Low

• The code is large and fast-moving. It was spot-checked by pattern search, not read in full, and the exact 0.17.0 commit was not reviewed.
• The MCP server is unscoped by default. Its roots confine files, not actions: run_command reaches printing and Explorer, which was not tested under scoping.
• Per the code review, the control port has no authentication, so another program on the machine could likely drive the app while it is on. That was not tested.

What would move it to Low: a review of the 0.17.0 commit and the forked dependencies, or a rebuild of the installer from that tag with matching binaries — and a release that scopes the MCP server by default.

Recommendation: install with mitigations

• Scope the MCP server before giving it to an agent: start it with --automation-read-root and --automation-write-root pointing at a working folder, not at originals. Keep the agent client's approval prompt on for run_command, command_batch and invoke_menu.
• Use the control port only when needed, and close the app afterwards.
• Stay on 0.17.0 deliberately. Before upgrading, check the new installer's checksum and signature, and ideally re-run the network and self-update probes.

What was not covered

• GUI features nobody clicked: import, WebAssembly plug-ins, image trace, fonts and text, hardware GPU paths.
• Most MCP tools beyond drawing, inspection, preview and the file tools — print and reveal among them, scoped or not.
• Whether the control port can actually be driven by another program; only where it listens was checked.
• A real reboot: the sandbox cannot restart, so the probes show nothing is set up to start again, not what happens across a restart.
• Anything that happens outside the probe window. Probes only see what happens while they run.

This is a check of one version, done for our own use — not a verdict on the project. VectorCraft behaved like a well-behaved desktop editor in every probe, and its root options worked as designed in every case tried. We shared these results with its developers; you can find VectorCraft on its website and its source on GitHub. The full report went through two rounds of peer review, and its corrections are recorded alongside it. This is due diligence, not a guarantee.