> For the complete documentation index, see [llms.txt](https://docs.remote.it/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.remote.it/mcp-server/security-review.md).

# 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](https://app.remote.it) 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                     |
| `account:read`                   | Read account details                       |
| `org:read`                       | Read organizations and their members       |

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.

The grant is also bounded by **account**: at consent the user chooses whether it covers their personal account, specific organizations, or all accounts including ones joined later. An organization outside the grant refuses every tool call, not only device reads, until the user reconnects and adds it.

**Layer two — the account's own permissions.** Every call is checked against the same [organization roles](/features/organizations.md) that govern the portal.

{% hint style="info" %}
**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.
{% endhint %}

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, script, or job records
* Removing a service or connect link, or a service definition from a product
* 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](/developer-tools/api/usage/event-logs.md). 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.

{% hint style="info" %}
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.
{% endhint %}

## 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          |

## Endpoints

The MCP server is `https://cloud.remote.it/mcp` and sign-in goes through `https://login.remote.it`. Those are the two hosts to allowlist; both are served over TLS and neither requires an API key.

## 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](/mcp-server/permissions-and-safety.md) — the same guardrails, written for the person using the assistant
* [Tool Reference](/mcp-server/tools.md) — every operation the server exposes, with destructive ones marked
* [Prompt Library](/mcp-server/prompt-library.md) — what teams actually use it for


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.remote.it/mcp-server/security-review.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.