Guides

CAD AI security

A CAD model isn't generic data — it's often the IP itself. What to actually check before an AI assistant gets tool access to it.

Guide · Security & trust

A support ticket, a marketing document, a spreadsheet — most data an AI assistant touches is disposable if it leaks. A parametric model, a toleranced drawing, or a bill of materials usually isn't: it can be design comprehension a competitor uses directly, not just "data." Evaluating AI-CAD security means asking sharper questions than "is it encrypted," and this is the checklist worth running before connecting anything to production CAD work.

Marketplace risk, specifically for CAD

Some AI tool ecosystems allow third-party, community-submitted servers into the same session as everything else you've connected. For generic tools that's already a risk; for a tool with read or write access to CAD data, it's worse, because the payoff for a malicious server is bigger and the tool descriptions that could hide an injected instruction are the same descriptions a CAD tool needs to be genuinely useful ("read the active assembly," "export the BOM").

Prompt injection via tool descriptions
A malicious community server can embed instructions inside its own tool descriptions that hijack the session the moment the assistant reads them — before any CAD tool is even called.
Credential or file exfiltration
A tool with CAD file access is a tool with export access. A malicious implementation doesn't need to break anything to leak a model — it just needs to be the thing your AI already trusts to touch it.
Supply-chain compromise
A community-built CAD server brings its own dependency tree into your session. A compromised package upstream of it becomes a compromise of whatever it can reach — including an open assembly.
No accountable owner
When a third-party server misbehaves, there's rarely a single accountable party to answer for it — which matters enormously once IP, not just uptime, is on the line.

What "least data leaves the machine" means here

For the desktop connectors, this isn't a policy statement — it's the architecture. See local bridge architecture for the full shape, but the security-relevant fact is short: the CAD application and the connector both run on hardware you control, and only the specific answer a tool call asked for crosses the network. There's no upload step to secure, because there's no upload.

What's encrypted, and how access is scoped

All data in transit uses TLS 1.3. Session and account data at rest is encrypted with AES-256, with backups under separate key material. Credentials for cloud-connected platforms are stored as OAuth token references — never a raw vendor password. Desktop connectors use per-device activation rather than a shared credential, so a lost or compromised machine is one revocable activation, not a workspace-wide exposure. See the full security page for the complete infrastructure detail, including authentication options (passkeys, SSO) and Enterprise VPC / BYO deployment.

A checklist before you connect anything

Whichever tool provider you're evaluating — this one included — these are the questions worth getting a specific answer to, not a general reassurance:

  • Can third-party or community servers run in the same session as your CAD tools?
  • Does your CAD data get uploaded anywhere, or is it read where it already lives?
  • Is every tool call logged, attributable, and exportable for review?
  • Are credentials scoped per device or per user, or shared broadly across a workspace?
  • Is data encrypted both in transit and at rest, with a stated standard, not just "encrypted"?
  • Who can you ask for a source or architecture review, and under what terms?
Related