Security Review Brief

The security brief for IT and OT teams reviewing the Remote.It MCP server — what changes, what doesn't, network exposure, authentication, authorization, auditability and recommended deployment posture

This page is written to be forwarded. If someone on your team has been asked to approve an AI assistant having access to production equipment, this is the document for them.

It is organized as the questions a security review actually asks, in the order they get asked.

The short answer

The MCP server does not create a new way to reach your devices. It is another client of the same Remote.It API that already backs the web portal and Desktop app, subject to the same authentication, the same organization roles, and the same per-device permissions.

What is new is the control surface: an AI assistant can now call those existing operations on your behalf. So the review question is not "is there a new hole in my network" — there isn't one — but "what is this assistant allowed to do, and how do I bound it." That is what the rest of this page covers.

Does this change my network exposure?

No. The connectivity model is unchanged.

Remote.It devices make outbound connections only — the service agent needs outbound UDP on ports 5959–5970 and nothing else. There are no inbound ports to open, no port forwarding, no firewall rules to relax, and no public IP requirement. This is what allows Remote.It to work across NAT, CGNAT and restrictive firewalls in the first place, and the MCP server does not alter any of it.

An assistant asking to open a connection produces exactly the same connection the Desktop app would produce, over the same path, with the same scoping.

What is actually in the path?

Three things, and it is worth being precise about each.

Component	Role	Who operates it
Your AI client	Holds the OAuth access token; decides which tools to call	Your AI provider (e.g. Anthropic)
Remote.It MCP server	Hosted endpoint that translates tool calls into Remote.It API calls	Remote.It
Remote.It API	The existing control plane behind the portal and Desktop app	Remote.It

The MCP server is hosted by Remote.It — there is nothing to install, and no component of it runs inside your network. Your devices continue to talk only to the Remote.It service as they already do.

Content of your conversations with the assistant — your prompts, and the tool results returned into them — is handled by your AI provider under whatever agreement you have with them. Review that separately; it is the same consideration as any other connector you enable in that assistant.

How does it authenticate?

OAuth 2.1, through your browser. There are no API keys to mint, paste, or rotate.

• You sign in with your normal Remote.It credentials, including social sign-in, 2FA, and SAML SSO where your organization uses it.

• The assistant receives only a capability-limited access token. Your password and account keys are never exposed to it.

• Access is revoked by removing the connector from your AI client.

Because sign-in goes through your existing identity path, whatever controls you already enforce there — MFA, SSO policy, conditional access — continue to apply. Enabling the MCP server does not create a second, weaker way into the account.

How is it authorized?

Two layers, and they multiply rather than add.

Layer one — capabilities granted at consent. Access is split by domain and action, so you can grant a subset. The assistant's token carries exactly what you approved:

Capability	Allows the assistant to…
device:read	View devices, services and tags
device:connect	Open and close connections to services
device:write	Modify devices, services, tags and sharing
device:execute	Use scripting tools
log:read	Read connection and event history
network:read / network:write	View / modify networks
product:read / product:write	View / modify products

A token without a capability cannot perform those operations at all — the server refuses the tool call before it reaches the API. A read-only grant can inventory and monitor a fleet but can never connect to it or change it.

Note that history is granted separately from inventory: device:read lists devices, but reading who connected to them and for how long requires log:read. Grant it deliberately.

Layer two — the account's own permissions. Every call is checked against the same organization roles that govern the portal.

Capabilities only subtract. What you grant is intersected with what the signed-in account can already do. An assistant signed in as a view-only member gets view-only access no matter what was approved at consent. You cannot escalate privilege by granting a broader capability.

This is the property that makes the review tractable: the assistant's maximum blast radius is the account it signed in as. If you can describe what one operator can do, you have described the worst case.

What requires a human?

Destructive and code-executing operations require an explicit confirmation flag, which a well-behaved assistant only sets after asking you:

• Deleting a device, network, product, or job records

• Removing a service or connect link

• Transferring ownership of a device or product

• Running a script on devices

Transfer is worth calling out: once ownership moves, only the new owner can move it back.

Script execution stacks three independent gates, all of which must hold:

1. The token carries device:execute.

2. The account role has the Scripting permission for that organization, evaluated per target device.

3. The specific run_script call is confirmed.

If any layer is missing, the scripting tools are not merely refused — they are unavailable to the assistant.

What gets logged?

Remote.It maintains account event logs, queryable through the GraphQL API. Each event carries a timestamp, an event type, the affected device or service, and — for shares and connections — the actor who initiated it and the users affected.

Currently exposed event types include DEVICE_STATE, DEVICE_CONNECT and DEVICE_SHARE, with more being added. Because MCP-initiated actions run through the same API as any other client, connection and sharing activity appears in the same log your team already reviews, attributed to the account that authorized the connector.

If your review requires distinguishing assistant-initiated activity from portal-initiated activity, raise it with us during your evaluation — this is an area we are actively developing and we would rather hear the requirement now.

What if the assistant is wrong, or compromised?

The honest framing, since a good reviewer will ask.

An AI assistant is a non-deterministic operator. It can misread a request and act on the wrong device. Treat it as you would any other operator with credentials — because architecturally, that is exactly what it is.

What bounds the damage:

• It can never exceed the permissions of the account it signed in as.

• It can never exceed the capabilities granted at consent — and a read-only grant is genuinely read-only.

• It cannot delete or execute without a confirmation step.

• Revocation is immediate and unilateral: remove the connector, and the token stops working.

• Nothing it does opens a network path that did not already exist.

What does not bound it: within its granted capabilities, it can act quickly and at fleet scale. An assistant with device:write across a large organization can retag or reshare a great many devices in one instruction. Scope accordingly.

Recommended deployment posture

Recommendation	Why
Start with device:read and log:read only	Delivers most of the value — inventory, triage, reporting — with no ability to change anything
Use a dedicated account, not an owner account	Bounds blast radius to a role you define, and makes event-log attribution unambiguous
Add device:connect before device:write	Connecting is reversible; modifying sharing and services is the part worth deliberating
Withhold device:execute until you have a reason	Script execution is the highest-impact capability. Most teams never need to grant it
Grant network:write and product:write only if you use those features	They are separate from device:write; leaving them out costs nothing if unused
Evaluate against a non-production organization first	Same tools, same behavior, no consequences
Review connected clients on a schedule	An OAuth grant is durable until revoked — treat it like any other standing credential

Preview status

The MCP server is currently in preview at https://mcp.demo.remote.it/mcp, and that URL will change at full release. If you are conducting a formal review, note that the endpoint address is not yet final and plan to re-point any allowlisting you put in place.

Quick answers

Can the assistant see devices I haven't shared with it? No. It sees exactly what the signed-in account sees — no more.

Can it open a port on my firewall? No. Remote.It never requires an inbound port, and no tool exposes one.

Can it run commands on a device? Only through scripting, which requires the device:execute capability, the Scripting permission on the account and target device, and per-call confirmation.

Can it change my account's permissions or roles? No. There is no tool that modifies organization roles or licensing.

Does anything run inside my network? No. The MCP server is hosted; your devices run the same service agent they already run.

How do I turn it off? Remove the connector from your AI client. Access ends immediately.

Related pages

• Permissions & Safety — the same guardrails, written for the person using the assistant

• Tool Reference — every operation the server exposes, with destructive ones marked

• Prompt Library — what teams actually use it for