"Is it safe to let an AI touch my CAD model" is really three separate questions: can it only do specific, bounded things, can a bad edit be undone before it costs anything, and can someone check afterward what actually happened. Here's what's true today, grounded in what's actually shipped — not a general promise that everything will be fine.
Typed tools, not free-form execution
Every write is a specific, named operation — set this dimension, add this feature, export to this format — with a typed schema the AI client already showed the engineer before the call was made. There's no general "run this code against my model" surface exposed by default. Where a CAD application offers its own scripting as an advanced capability, it's an explicit opt-in: off until an engineer enables it in the server configuration, and the tool reports itself as gated until then. See parametric CAD automation for why a scoped, named edit is fundamentally different from regenerating geometry.
Nothing persists until you save
This is the single biggest safety property, and it isn't a policy — it's how the desktop connectors are built. As stated on the Inventor tool reference: a named dimension's previous value is read before it's written and returned alongside the result, "and the document is never saved for you — undo and save stay with the engineer." A tool call acts on the CAD application's open, in-memory session, the same session a person is looking at. Nothing an AI does through it is more permanent than a manual edit would be, right up until someone chooses to save.
Read before write, and the undo stack still works
A write returns the value it changed from as well as the value it changed to — so confirming or reverting a specific edit doesn't require reconstructing what happened from memory. And because a parametric edit goes through the CAD application's own feature tree and history, its own undo stack is exactly as available afterward as it would be for a change made by hand.
Reads are zero-risk by construction
Listing a feature tree, reading dimensions and equations, computing mass properties, pulling GD&T callouts off a drawing — none of it mutates the document. The "just looking" case, which is most of what an engineering conversation with an AI actually does, carries none of the risk a write does, because it's structurally incapable of one.
Two more layers: consent before, audit after
Before any of the above even runs, the AI client's own interface is where a person approves a tool call — that's outside ForgeMCP's own code, and it's real regardless. See MCP vs. direct CAD APIs for how that consent step fits into the protocol. And after the fact, Business and Enterprise plans get a full audit log — which tool, when, with what parameters, what came back — immutable and exportable, independent of whether the underlying change was ever saved. See the full security page for the complete detail.
The caveat that matters: this is a desktop-connector story
Everything above about data staying local is specifically true of the desktop connectors — see local bridge architecture for the full shape of why. It is not true of cloud-connected platforms, and saying so plainly matters more than repeating a reassuring line that doesn't apply everywhere. A cloud CAD platform's model already lives in the vendor's own cloud before ForgeMCP is involved at all — that's the nature of a cloud platform, not a ForgeMCP choice. Connecting to one means ForgeMCP reaches that existing copy through the vendor's own API, under a credential scoped to your account; it doesn't create a new place your data goes, but it also isn't "nothing leaves your machine," because there's no single machine boundary in that picture to begin with. The properties that do carry over — typed and scoped tools, consent before a call, an audit trail after — aren't about where the data lives, so they hold either way.