MCP Server security

This page describes how the Optimo IoT MCP server protects platform data when access is granted to an external AI assistant (Claude, ChatGPT, Mistral AI, Microsoft Copilot, ...).

In short:

• access is always read-only: the MCP server exposes no function to change configurations, send commands or write data;
• the user explicitly chooses which group to make accessible, and access can never exceed the user's own permissions;
• a granted authorization never widens over time, while it narrows immediately if the user loses permissions;
• new MCP server tools that read new types of data require new explicit consent from the user;
• tokens are short-lived (1 hour) and an authorization expires after at most 30 days, after which access must be authorized again.

Authorization flow

The connection between an AI assistant and Optimo IoT uses the OAuth 2.1 standard with PKCE, as required by the MCP specification:

1. the user adds the MCP server to their AI assistant;
2. the assistant opens the cloud.optimoiot.it login page, where the user signs in with their Optimo IoT credentials (including the second factor, if enabled on the account). Credentials are never shared with the AI assistant;
3. the page clearly states that read-only access is being granted to an external service, and asks the user to select the group the service will be able to access;
4. only after confirmation does Optimo IoT issue the assistant a token limited to the chosen group.

Further protections of the flow:

• tokens are only delivered to the redirect URIs of the supported providers (Claude, ChatGPT, Mistral AI, Microsoft Copilot, Google Antigravity). An authorization request crafted by a third party with a different address is rejected, even if the user's login is valid;
• the intermediate authorization code can be used only once, expires after 5 minutes, and is bound via PKCE (S256) to the client that started the request;
• each login can be used for a single authorization: the same login cannot be reused to change the scope of an authorization after it has been granted;
• the tokens the assistant receives are not the login tokens: they are issued again after the group has been chosen, so they only carry the permissions actually granted.

Permission restriction

Every MCP authorization is bound by three limits, applied together:

Limit	Description
Read-only	Whatever the user's own level (read, write, admin), the assistant only ever receives read permissions. In addition, the MCP server exposes no write tools.
Chosen group	The assistant can only read the group the user selected on the authorization page (and its sub-groups), not every group the user has access to. A single sub-group, such as one plant, can be chosen to minimize the data exposed.
User's current permissions	On every request the granted scope is checked against the permissions the user holds at that moment. The assistant can never read more than the user can.

Within the authorized group, the assistant can access:

• the asset tree and its metadata (names, descriptions);
• the variable list and its metadata (units, limits, ...);
• variable values, both raw and aggregated;
• the AIMS asset log.

The following are not accessible: data of other groups, users and their personal data, gateway configurations, notification settings, billing data.

Changes to the user's permissions

The scope of an authorization is fixed when the user grants it, and from then on it can only narrow.

If the user's permissions are reduced (for example the user is removed from a group, or an authorized sub-group is moved elsewhere in the hierarchy), the reduction also applies to the already-connected AI assistant, within a few minutes and with no action required.

If the user's permissions are extended (for example the user is added to a new group, or is given write permissions), the authorization already granted to the assistant does not change: the assistant keeps seeing only the originally chosen group, read-only. To extend the assistant's access to new data, the user must go through the whole authorization procedure again, with a new login and a new explicit choice of group.

This way, wider permissions never translate, implicitly or silently, into more data exposed to an external service.

New MCP server features

Optimo IoT may release new tools for the MCP server over time. However, what the user consents to on the authorization page covers specific types of data: asset and variable metadata, variable values and the AIMS log. A new tool never silently extends an authorization already granted:

• if the new tool reads types of data already covered by the consent (for example a new way of querying variable values), it stays within what the user already authorized;
• if the new tool reads a new type of data (for example alarms or reports), Optimo IoT updates the authorization page and the consent version. From then on, every authorization granted under an older version is rejected: the AI assistant receives no more data and no new tokens, and the user must sign in again and explicitly confirm the updated consent before the connector can be used.

The consent version is checked server-side on every request and every token renewal, so it takes effect within a few minutes of a release, on access tokens already issued too.

In any case, every new tool is subject to the same limits as all the others: read-only, and only within the authorized group.

Token lifetime, renewal and revocation

Item	Lifetime	Notes
Authorization code	5 minutes	Single use, bound via PKCE
Access token	1 hour	Sent by the assistant with every request, signed and verified on every call
Refresh token	30 days from login	Used by the assistant to obtain new access tokens. Once expired, a new login is required
MCP authorization	30 days from the last token renewal, and never beyond the refresh token expiry	Checked on every request: if the assistant is not used for 30 days, the authorization lapses

In practice:

• a stolen access token is usable for at most one hour;
• at least every 30 days the user must sign in again and confirm again which group to share, even if the assistant is used regularly;
• every renewal checks that the authorization is still valid: a revoked or expired authorization prevents new tokens from being issued.

Revocation

An authorization can be revoked at any time:

• by the user, by disconnecting the connector from their AI assistant: the assistant discards the tokens and, if the provider supports it, revokes the refresh token via the revocation endpoint, preventing new tokens from being issued;
• by Optimo IoT, on the customer's request, for a single authorization or for all of a user's authorizations. This revocation is checked server-side on every request, so it also takes effect within a few minutes on access tokens already issued;
• implicitly, if the user's account is disabled or removed, or if the user loses access to the authorized group.

Data ownership and traceability

Data read through the MCP server remains the customer's property, like all other data on the Optimo IoT platform. It is important to be clear about the path the data follows:

1. Optimo IoT sends the requested data only to the AI assistant authorized by the user, in response to its requests and only for the authorized group;
2. from then on, the data is processed by the AI assistant's provider (Anthropic, OpenAI, Mistral AI, Microsoft, ...) under the contractual terms and privacy settings the customer has with that provider (for example conversation retention, or use for model training). Optimo IoT has no control over this stage;
3. Optimo IoT never sends data to any AI provider on its own: every transfer only happens after an explicit authorization by the user and a request from the assistant.

For this reason, the authorization page explicitly warns the user that they are allowing an external service to read all data of the selected group and its sub-groups, and asks them to make sure this is allowed by their company policies.

For each authorization, Optimo IoT records which user granted it, when, and for which group. This information can be provided to the customer on request, for example for internal reviews or audits.

Prompt injection

Prompt injection is the case where text read by an AI model contains instructions the model might follow as if they came from the user. With regard to the Optimo IoT MCP server, the risk has to be considered in two directions.

Can the MCP server inject instructions into the assistant?

No. The Optimo IoT MCP server:

• exposes a fixed set of tools, with static descriptions defined and versioned by Optimo IoT, which only describe how to query data;
• only returns structured data (JSON) read from the platform, or predefined error messages, with no text generated by the server;
• cannot start requests towards the assistant on its own: it only answers the calls the assistant makes.

Can platform data contain malicious instructions?

Some of the returned data is free text entered by platform users: asset and variable names and descriptions, custom metadata, AIMS log entries. In theory, a user with write permissions on these fields could enter text designed to influence the behavior of the AI assistant reading it.

This risk is contained by the way access is designed:

• no action is possible on the platform: access is read-only and there are no write tools, so a malicious instruction cannot make the assistant change configurations, send commands to plants, or alter data on Optimo IoT;
• limited scope: even if manipulated, the assistant can only read data of the authorized group, which the user can already read;
• known authors: free-text fields can only be edited by authenticated users with write permissions on the group, i.e. people already authorized by the customer.

The residual risk is the combination with other connectors enabled in the same conversation: if the assistant also has tools that can take actions (for example sending emails, writing to shared files or browsing the web), malicious text could try to make it send the data it read elsewhere. Protection against this depends on the AI assistant and its configuration, not on the MCP server.

Summary

Topic	Measure
Prompt injection from the server	Tools with static descriptions, responses only carrying structured data, no server-initiated requests
Prompt injection from data	Read-only, no write tools, scope limited to the authorized group
Permission restriction	Read-only, group explicitly chosen by the user, current permissions checked on every request
Wider permissions	Never propagated to an existing authorization: a new explicit authorization is required
New MCP tools	A new type of data requires new explicit consent: earlier authorizations are rejected
Narrower permissions	Applied to existing authorizations within a few minutes
Token lifetime	Access token 1 hour, new login required at least every 30 days
Revocation	By the user (disconnecting the connector) or by Optimo IoT on request, enforced server-side even on tokens already issued
Data ownership	Data remains the customer's, is only sent to the assistant authorized by the user, every authorization is recorded