Revit Agent Security: The Local Workstation Boundary

This guide describes the security model behind Revit Agents: what stays on the workstation, how the secure connector bridges the cloud console without exposing Revit, and how least privilege is applied to both agents and people.

In short

The Revit Agents security model keeps Autodesk Revit, the Revit API, the local LLM and the MCP server on the workstation. The cloud console holds identity, policy, approvals and audit, and reaches the workstation only through an authenticated outbound connector to a specific paired machine.

The local workstation boundary

The defining constraint of the architecture is simple to state: the browser cannot reach Revit. Revit, the Revit API, the local LLM and the MCP server all sit on the workstation, inside the practice network, and nothing in the cloud console addresses them directly.

That is not a limitation to work around — it is the security property. Project models and design IP never leave the machine they are already on, so the question 'where did our model data go?' has a short answer.

Trust boundaries

── cloud ─────────────────────────────────
Authenticated console      identity · policy
Server functions           approval enforcement
── boundary ──────────────────────────────
Secure connector           paired workstation only
── workstation ───────────────────────────
Local agent runtime · local LLM · MCP server
Revit API · Autodesk Revit · project model

How the secure connector works

The console does not open a port on your network. Execution requests are dispatched through an authenticated, outbound connector to a specific paired workstation, and the local connector is the only component that speaks to the MCP server on loopback.

Two credential concerns are kept separate: the transport-level access credentials that authorise reaching the tunnel at all, and the pairing token that identifies a particular workstation to the console. Neither substitutes for the other.

Capability detection, not assumption

The console probes what a paired workstation genuinely exposes and reports it honestly. If a tunnel is down or a tool is unavailable, that state is shown rather than masked with sample data — a live feature is never claimed on the strength of mock output.

Least privilege, applied per agent

Agents receive only the tools their task requires. A model-audit agent that reads elements and returns findings has no reason to hold a delete or parameter-write tool, and granting one enlarges the blast radius of any mistake for no benefit.

The same principle applies to people. Roles separate who may configure an agent, who may approve a prompt version, and who may authorise a run that writes to Revit.

Scoped tool grants: Each agent's permitted tool list is explicit rather than inherited from whatever the MCP server happens to expose.
Project isolation: Configuration and approvals are scoped so settings do not leak between projects or workspaces.
Workstation identity: Runs are routed to a named, paired workstation rather than to whichever machine answers first.
Server-side enforcement: Preflight and approval checks run server-side, so a client cannot skip them by crafting a request.

Threats worth designing against

Some risks are specific to agents rather than to software generally, and they are the ones that catch teams out.

Prompt injection via model data: Text held in a model or linked document can attempt to steer an agent. Restricting tools limits what any such instruction can achieve.
Over-broad tool grants: The most common real-world issue: an agent given every available tool because it was easier during testing.
Destructive operations: Deletions and bulk parameter overwrites deserve their own approval treatment, separate from ordinary writes.
Stale context: A proposal computed before a synchronise may no longer be valid. Runs should be evaluated against current model state.
Credential sprawl: Access credentials and pairing tokens should be per-workstation and revocable individually.

Questions your IT team will ask

Does the model leave the workstation? No. Does anything inbound need to be opened? No — the connector is outbound and paired. Who can execute a change to a live model? Only a user with the appropriate role, on an authorised run, against a paired workstation. Can we see what happened? Yes — runs, approvals and outcomes are recorded per project.

Where a capability is still being built out during early access, the console is explicit about it rather than implying more assurance than exists.