# Thermus with internal connectors and agent identities

Updated: 2026-10-15

Thermus does not protect MCP servers or connectors to internal systems, and it does not manage their permissions. It adds a control on a different path: what the agent sends to the open web and what comes back.

You do not need to reason about every connector that could exist. Start with the systems and actions your organization actually enables. Two useful categories to discuss are productivity systems and internal data platforms.

### Separate the agent's identity from the employee's identity

**Giving an agent permission to act is not the same as giving it an employee's access.** An agent that sends email, updates a calendar or edits documents does not need blanket access to a person's inbox, files or the company's data lake.

For purpose-built, autonomous workflows, the recommended starting point is a dedicated, restricted agent account or workload identity where the platform supports it. Grant the resources and actions needed for that job; do not copy an employee's full permissions or pool unrelated workflows into one powerful bot account. Google's guidance on single-purpose service accounts and narrow resource permissions supports this approach for Google Cloud workloads. [Google Cloud service account best practices](https://cloud.google.com/iam/docs/best-practices-for-using-service-accounts)

The goal is the right identity, the right resources and the right actions, not "all connectors must be read-only." Reading, sending, editing and sharing should each be explicitly considered. For example, Gmail defines a send scope separately from its mailbox-read scopes; sending email does not itself require granting mailbox-read access. [Gmail API scopes](https://developers.google.com/workspace/gmail/api/auth/scopes)

Identity separation must be real. An alias or a different From address is not a separate authenticated account; Google Workspace explicitly distinguishes email aliases from Google Accounts. A dedicated mailbox account and a cloud service account are also different things. Use the identity and authorization model the actual connector supports. [Google Workspace email aliases](https://support.google.com/a/answer/33327) [Google Cloud service account best practices](https://cloud.google.com/iam/docs/best-practices-for-using-service-accounts)

This is a recommended pattern, not a claim about what every agent platform does by default. Some integrations act through an employee's delegated authorization; others use an application's own identity. App-only permissions can be broader, not narrower. For employee-assistant use cases that require delegated access, restrict the effective permissions rather than automatically switching to app-only access. [Microsoft Graph permissions overview](https://learn.microsoft.com/en-us/graph/permissions-overview)

### Productivity systems

Examples include Google Drive or equivalent document platforms, including documents, spreadsheets and presentations, plus email and calendar. Review the identity the connector actually uses, its OAuth scopes, the source system's resource permissions and the agent platform's enabled actions together. Authentication alone does not establish these restrictions. [Gmail API scopes](https://developers.google.com/workspace/gmail/api/auth/scopes) [OpenAI admin controls for apps and connectors](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-in-connectors-enterprise-edu-and-team)

Use the following as recommended configurations, not statements about a particular customer's setup or capabilities available in every connector:

| Workflow | Recommended permission boundary |
| ----- | ----- |
| Email | Use an agent-specific mailbox or narrowly scoped sending identity. Permit only the needed sending/reading actions and approved recipients. Do not grant broad access to an employee's inbox merely so the agent can send messages. |
| Calendar | Permit changes only to the workflow's designated calendar or explicitly authorized calendars. Separately restrict external invitees and information included in invitations. |
| Documents, spreadsheets and presentations | Permit creation or editing only in designated folders or explicitly authorized files. Restrict sharing and publishing, and review who can already see edited content. |

An agent can therefore have useful write access without having broad employee access. For a workflow that needs only reads, disable unnecessary writes. For a workflow that needs writes, scope them instead of assuming that the whole connector must be read-only.

Recipient restrictions are a separate control from the identity and send permission. Google Workspace, for example, supports restricting email delivery to authorized addresses or domains by organizational unit; its documentation also flags possible Google Groups bypasses. Verify the policy on the actual sending path rather than assuming the presence of a dedicated mailbox is sufficient. [Google Workspace restricted email delivery](https://support.google.com/a/answer/2640542)

### Internal data platforms

Examples include a data lake, warehouse or database. Give the workflow an appropriately scoped data-access identity and apply the platform's permissions to the identity the connector actually uses. Allow only the necessary datasets, tables or views, with row- and column-level restrictions where supported; use read-only permissions unless the workflow explicitly needs writes. Do not supply a person's privileged credentials just because the agent needs to perform an unrelated email or calendar task. BigQuery, for example, provides granular resource and data-access controls. [BigQuery access control](https://cloud.google.com/bigquery/docs/access-control)

Verify each connection separately: the account used to send email does not establish the permissions used by a data connector. A limited email identity is not evidence that the same agent's other data connections are limited.

### Permission to read is not permission to send outside

Consider an agent authorized to read an internal revenue report. Reading that report can be legitimate. Sending its contents to a public search engine or an attacker-controlled website is a different action. Source-system permissions can allow the first without deciding whether the second is appropriate. Read-only access limits changes to the source; it does not prevent information already retrieved from being sent through another tool. [OpenAI remote MCP and connector guidance](https://developers.openai.com/api/docs/guides/tools-connectors-mcp)

Thermus fetches and cleans webpages through its GET-only MCP tool. It records the stated reason without scoring it and does not provide POST uploads or human approval. A GET URL can still disclose sensitive information; the client must enforce that sharing boundary. It does not inspect that original connector read or sanitize the content returned by the connector.

### The deployment assumptions matter

This approach assumes approved, trusted connectors with appropriately scoped identities, resources and actions. Necessary sending, editing and sharing can remain enabled when separately governed; the architecture does not require every connector to be read-only. Unnecessary actions and independent network routes must be disabled. A read-only label alone is not enough either: requests send arguments to the connector server, so review its trustworthiness and actual behavior. [OpenAI remote MCP and connector guidance](https://developers.openai.com/api/docs/guides/tools-connectors-mcp)

**Separate accounts restrict access; they do not erase information the agent has already received.** For example, an agent could read a confidential report through one connection and put it in an email sent from its own mailbox through another. Review the data available across the workflow and the recipients or audiences of every allowed output. The same reasoning applies to calendar invitations and edits to documents visible to other people. This is a risk scenario to assess, not an observation about a particular customer.

Thermus does not govern those email, calendar or document actions when they bypass its gateway. They require separately enforced source-system, connector or workflow controls. When those paths are restricted, public-web access remains a separate data-leak path for Thermus to govern—not a claim that connectors are inherently safe or that all leaks happen through the web.

**Your existing controls govern the agent's identity and what it can read, change or send through internal connectors. Thermus adds checks to what it sends to the public web.**

## Does read-only mean a connector is completely safe?

No. Read requests send arguments to the connector server, and retrieved content can contain malicious instructions. Review the server's trustworthiness, the data sent in tool arguments, effective permissions, and the actual actions it can perform. OIDC authenticates identity; OAuth scopes and enforced resource permissions help determine authorized access. Neither makes prompt injection or data misuse impossible. [OpenAI remote MCP and connector guidance](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) [OpenID Connect Core specification](https://openid.net/specs/openid-connect-core-1_0.html)

## Discussing a specific deployment

Establish whose identity each connection uses, which resources it can access and which actions and recipients are permitted. A useful question is: "Does the agent use its own restricted account or an employee's connection, and what can it access and do?" If the identity is already known, ask only about the missing boundary. Do not infer permissions from a mailbox name, assume every agent is read-only, or treat a supported identity mechanism as proof of a safe deployment.

## Related topics

- [Data leaving through the public web](https://thermus.ai/guide/data-leaks.md)
- [Organization setup and validation](https://thermus.ai/guide/deployment.md)