> 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/permissions-and-safety.md).

# Permissions & Safety

How the Remote.It MCP server protects your infrastructure — the capabilities you grant, your existing account permissions, and confirmation gates on risky operations.

Giving an AI assistant access to your infrastructure deserves clear guardrails. The Remote.It MCP server is built around three layers of protection: **the capabilities** you grant when you authorize the connector, **your existing account permissions**, and **confirmation gates** on dangerous operations.

## OAuth sign-in — no API keys

The MCP server uses standard OAuth 2.1 authorization. When your assistant connects for the first time, you sign in to Remote.It in your own browser — with your usual credentials, social sign-in, and 2FA. The assistant only ever receives a capability-limited access token; your password and account keys are never shared with it.

You can revoke access at any time by removing the connector from your AI client.

## Capabilities: choose what to grant

At sign-in, the consent screen shows the access being requested. It is split by domain and action, so you can grant exactly as much as you're comfortable with:

| 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 (still gated by the Scripting permission and confirmation) |
| `log:read`                       | Read connection and event history — who connected, when, how much bandwidth    |
| `network:read` / `network:write` | View / modify networks                                                         |
| `product:read` / `product:write` | View / modify device products used for bulk provisioning                       |
| `account:read`                   | Read your account details                                                      |
| `org:read`                       | Read your organizations and their members                                      |

A token that lacks a capability simply cannot perform those operations — the server refuses the call before it reaches the API. A read-only grant lets the assistant inventory and monitor your fleet but never connect to it or change it.

The consent screen also asks **which accounts** the grant covers: your personal account, chosen organizations, or all of them including any you join later. An organization left out is refused entirely — every tool, not just device listings — until you reconnect and add it.

{% hint style="info" %}
**History is separate from inventory.** `device:read` lists your devices; reading who connected to them and for how long needs `log:read`. If your assistant can see devices but cannot answer "who connected to this last week", that is the capability you are missing.
{% endhint %}

{% hint style="info" %}
**Capabilities only subtract — they never add.** What you grant is intersected with what your Remote.It account can already do. An assistant signed in to a member account with view-only role in an organization gets view-only access to that organization's devices, no matter what was granted at consent.
{% endhint %}

## Organization roles still apply

Every tool call is checked against the same [organization roles and permissions](/features/organizations.md) that govern the web portal and Desktop app. Device visibility, connect rights, management rights, and scripting rights per organization all carry through unchanged.

## Confirmation gates

Tools that are destructive or execute code require the assistant to pass an explicit confirmation flag, which well-behaved assistants like Claude will only do after checking with you. These include:

* 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 — once it moves, only the new owner can move it back
* Running a script on devices

## Scripting is opt-in by permission

Script execution is the highest-impact capability, so it stacks every gate:

1. Your granted capabilities must include `device:execute`.
2. Your account role must have the **Scripting** permission for the organization, and it applies per target device.
3. Every `run_script` call requires explicit confirmation.

If any layer is missing, scripting tools are simply unavailable to the assistant.

{% hint style="warning" %}
Even with guardrails, treat an AI assistant with write access like any other operator on your account: grant the least access that does the job, use read-only capabilities for monitoring use cases, and review what your assistant proposes before confirming destructive actions.
{% endhint %}

{% hint style="info" %}
Reviewing this on behalf of a security or OT team? The [Security Review Brief](/mcp-server/security-review.md) covers the same ground in the order a review asks for it — network exposure, what sits in the path, auditability, blast radius and recommended posture.
{% endhint %}


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.remote.it/mcp-server/permissions-and-safety.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.