mcp-server-permissions-and-safety.md
For the complete documentation index, see llms.txt. This page is also available as Markdown.
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.
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.
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.
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.
Every tool call is checked against the same organization roles and permissions that govern the web portal and Desktop app. Device visibility, connect rights, management rights, and scripting rights per organization all carry through unchanged.
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
Script execution is the highest-impact capability, so it stacks every gate:
Your granted scopes must include device:execute.
Your account role must have the Scripting permission for the organization, and it applies per target device.
Every run_script call requires explicit confirmation.
If any layer is missing, scripting tools are simply unavailable to the assistant.
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.
PreviousTool ReferenceNextOverview
Last updated 14 days ago
Was this helpful?