Secure Design of Model Context Protocol for Agentic AI Assistants in CAD Software

Background

I joined Vertex in 2023 as a summer trainee, working on the development of Vertex BD. I returned each summer and worked part-time alongside my studies. In 2024, I wrote my bachelor’s thesis for Vertex about BIM libraries and how they could be delivered to customers. Early in 2026, I began my master’s thesis, also commissioned by Vertex.

The topic took shape in January. I was initially interested in a thesis about a CAD API, and another colleague was exploring a related topic. We decided to split the work into two projects. Our CTO suggested exploring an AI assistant and the Model Context Protocol (MCP). The idea caught my interest, as an assistant that understands the CAD context could help users find information and automate some manual tasks.

The scope became clearer as the project developed. I focused on CAD rather than cloud features and authentication, and on how an AI assistant could connect to CAD software through MCP. I also examined the security risks such a system could introduce. The thesis combined three things: designing an architecture for an AI assistant, identifying relevant security risks and possible mitigations, and building a proof of concept (POC) to explore how different agent patterns perform.

Designing an assistant for CAD

CAD applications offer extensive toolsets, and users need to know the software well to find and combine the right operations. An AI assistant could make some workflows easier by answering questions about the current model or carrying out selected operations on it.

AI agents can use tools to interact with other software. MCP provides a standard way to make those tools available to AI applications. MCP has often been described as the USB-C port for AI agents. In a CAD assistant, MCP tools could, for example, retrieve information about model elements or make changes through the CAD application’s API.

Because CAD systems contain many features, giving one agent access to every available tool could make it harder for the agent to choose the right one. My thesis therefore proposes a modular MCP architecture. It combines tools shared across Vertex products with product-specific modules, so that an application can expose relevant tools without loading capabilities it does not need.

The proposed design also uses a supervisor agent to coordinate specialist agents, or subagents. Each subagent has a more focused role and access to a relevant set of tools. An MCP gateway sits between the agents and MCP servers, providing a place to route requests and manage which tools are available to each agent. Other services could also be connected through the gateway.

It’s important to distinguish the proposed architecture from the POC: the POC did not implement the full modular MCP architecture or the MCP gateway. It was used to explore MCP and compare agent patterns in a CAD environment.

Security matters

Connecting agents to CAD models also raises security concerns. CAD projects can contain valuable customer information, and an assistant may be able to read or modify model data. Some risks considered in the thesis include prompt injection, excessive permissions, misuse of tools, and misleading information generated by the AI.

The thesis also identifies measures that could help address these risks. These include keeping human oversight for important actions, giving agents only the permissions they need, validating inputs and outputs, and carefully reviewing external MCP servers and tools before allowing them into the system.

These are recommendations for a production system, not safeguards that were all implemented or tested in the POC. In particular, a locally running CAD application does not necessarily mean all data stays local. For example, if a cloud-based language model is used, relevant prompts and context may be sent to that service. Data handling therefore needs to be considered as part of the system’s design.

Comparing agent patterns

To explore how different approaches might perform, I built a POC using FastMCP for the MCP server and LangChain for the agents. I compared three patterns:

• Single agent: One agent receives the task and has access to the available tools.
• Supervisor and subagents: A supervisor delegates parts of the task to specialist agents.
• Handoffs: Specialist agents pass control between one another without a central supervisor.

The patterns were tested on three tasks of increasing complexity. The basic task asked how many walls in a building were thicker than 400 mm. The intermediate task asked the assistant to find those walls and change their height to 3,000 mm. The advanced task asked it to create a row of three houses, including their walls and roofs. A sequence diagram of the advanced task is shown below.

For each pattern and task, testing continued until ten successful runs had been recorded. Failed attempts were also included when calculating the success rate. The evaluation measured token usage, latency, and whether the assistant completed the task on its first attempt. It did not measure the effectiveness of the security mitigations.

The advanced task revealed the clearest differences between the patterns. In the recorded runs, the supervisor succeeded every time, compared with a 67% success rate for the single agent and 59% for handoffs. Handoffs had the lowest average token usage and latency for this task: about 5507 tokens and 14.9 seconds. The supervisor used about 8329 tokens and took 31.8 seconds, while the single agent used about 12478 tokens and took 20.1 seconds.

These results suggest a trade-off. Handoffs were more efficient on the advanced task, but the supervisor was more reliable in the runs I tested. The supervisor’s central role adds extra steps and latency, but it also gives the system a place to coordinate subagents and manage information between them.

A single agent performed well on the basic and intermediate tasks, where it did not need to coordinate with other agents. It struggled more with the advanced task, which required it to manage more steps and model information. Handoffs were efficient, but their lower success rate on the advanced task suggests that passing the right information between agents is important for complex work.

What I learned

The results point to different strengths for different tasks. A single agent may be enough for simpler work with a limited set of tools. Handoffs may be useful when efficiency is a priority. A supervisor-and-subagents pattern looks like a promising starting point for more complex tasks where coordination and reliable completion matter.

The findings are preliminary. This was a POC with a small number of tasks, and the supervisor pattern had received more development during the project than the other patterns. The results should therefore be read as an initial comparison, not as proof that one pattern will always perform best.

The thesis provides a starting point for developing a CAD assistant, but further work is needed before a production system is ready. That work includes developing the CAD API, implementing the modular MCP architecture and gateway, and adding and testing appropriate security controls. More evaluation across a wider range of tasks would also help clarify which agent patterns work best in different situations.

MCP offers a way to connect AI agents to CAD software, while a multi-agent design can help divide complex work into more manageable tasks. But the assistant’s access, the data it handles, and the actions it can take all need careful design. Building a useful CAD assistant is not only a matter of connecting an AI model to tools; it also means deciding how to keep the system understandable, controlled, and secure.