> 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

Giving an AI assistant access to your infrastructure deserves clear guardrails. The Remote.It MCP server is built around three layers of protection: **OAuth scopes** you grant at sign-in, **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 scoped 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.

## Scopes: choose what to grant

At sign-in, the consent screen shows the access being requested. Device access is split into independent scopes, so you can grant exactly as much as you're comfortable with:

| Scope            | Allows the assistant to…                                                       |
| ---------------- | ------------------------------------------------------------------------------ |
| `device:read`    | View devices, services, networks, tags, and history                            |
| `device:connect` | Open and close connections to services                                         |
| `device:write`   | Modify devices, services, networks, tags, and sharing                          |
| `device:execute` | Use scripting tools (still gated by the Scripting permission and confirmation) |

A token that lacks a scope simply cannot perform those operations — for example, a read-only grant lets the assistant inventory and monitor your fleet but never connect to it or change it.

{% hint style="info" %}
**Scopes only subtract — they never add.** Granted scopes are 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 scopes were granted.
{% 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, or job records
* Removing a service or connect link
* 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 scopes 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 scopes for monitoring use cases, and review what your assistant proposes before confirming destructive actions.
{% 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 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/permissions-and-safety.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.