# Deploying Thermus in an organization

Updated: 2026-10-16

Thermus is designed for agents that can connect to its MCP server and whose alternative public-web routes can be disabled or separately governed. Adding the connection alone does not make Thermus the only internet path.

## Hosted activation and MCP connection

Hosted is free early access, with no card and no automatic charges. Availability is shown at [signup](https://app.thermus.ai/signup); the server decides whether activation is open. Existing users can [sign in](https://app.thermus.ai/login).

When signup is available:

1. Open signup and read the hosted privacy notice before signing in. The current public sign-in option is Google through WorkOS. Any WorkOS identity with a verified email can qualify, using a personal or company email address.
2. Review the complete hosted terms and notice. Select the initially unchecked agreement checkbox and activate only if you meet the adult and business use requirements, including authority to agree for an organization when applicable. Sign-in alone does not activate access.
3. A new eligible person receives an isolated personal User workspace, with User access only. Activation grants no Admin or Super Admin role and adds no teammates. Select an authorized workspace and return to the portal. Existing users with product access can select Continue without another agreement or personal workspace. Contact support for incomplete or inconsistent activation.
4. In your native MCP client, add a remote MCP server with URL `https://app.thermus.ai/mcp`. Complete the client's authorization flow and choose the actual Thermus workspace for that connection. The client must support Thermus's authenticated remote MCP connection.
5. To use a different workspace, reauthorize the native client and choose that workspace. Browser workspace selection changes only the browser portal; it does not change the workspace of an existing MCP token. Verify the client's actual workspace and access before use.

If your client used the previous Render endpoint, replace that connection
with `https://app.thermus.ai/mcp` and complete authorization again. Credentials
for the previous endpoint do not migrate to the new endpoint.

Hosted free early access does not provide customer audit-log access or export, team management, or shared team policies. The organization controls below are deployment guidance for your AI platform and internal systems; activation does not configure them for you. They do not imply that the personal workspace is a managed team workspace.

## Recommended organization setup

**Turn off unrestricted web access, give agents scoped identities and connector permissions, then provide authenticated webpage fetching through Thermus.** This is the recommended deployment pattern, not a claim that a particular customer or workspace has already implemented all three controls.

### 1. Turn off alternative routes to the public internet

Use organization-enforced controls to disable the agent's native web search and live browsing. Also review code execution, browser tools, research modes, plugins and other tools that can make independent network requests. Disable any ungoverned route that could bypass Thermus. Do not rely on employees switching a feature off themselves or on a prompt that says "always use Thermus."

ChatGPT Enterprise/Edu and Claude Team/Enterprise document relevant administrative controls, but these are multiple controls with different scopes—not a universal "block all internet except Thermus" switch. Use the platform notes below to identify the settings, then verify the result in your actual workspace. [ChatGPT search for Enterprise and Edu](https://help.openai.com/en/articles/10093903-chatgpt-search-for-enterprise-and-edu) [Claude web search](https://support.claude.com/en/articles/10684626-enable-and-use-web-search) [Claude code execution and network access](https://support.claude.com/en/articles/12111783-create-and-edit-files-with-claude) [Claude Cowork organization controls](https://support.claude.com/en/articles/13455879-use-claude-cowork-on-team-and-enterprise-plans)

### 2. Give agents scoped identities and least-privilege connector access

Approve only trusted connectors and establish which identity each one uses. For purpose-built agents, use a dedicated, restricted account or supported workload identity rather than copying a person's full access. For connectors that intentionally act on behalf of an employee, narrow the delegated permissions. In both cases, grant only the workflow's necessary resources and actions; an app-only identity is not automatically less privileged. [Google Cloud service account best practices](https://cloud.google.com/iam/docs/best-practices-for-using-service-accounts) [Microsoft Graph permissions overview](https://learn.microsoft.com/en-us/graph/permissions-overview)

For example, an agent can send from its own mailbox, update a designated calendar and edit selected documents without broad access to a person's inbox or the data lake. Use the [productivity-system boundaries in the internal-connectors guide](https://thermus.ai/guide/internal-connectors.md). Treat the data connection separately: a limited email account does not justify giving another connector a broadly privileged identity.

Read-only access is a good baseline for tasks that need no writes, not a requirement for every agent. Enable necessary writes only on approved resources, with separately enforced recipient, invitee and sharing restrictions and appropriate approvals. Review existing audiences as well as new sharing actions. If the required boundary cannot be enforced, leave the affected action disabled or redesign the workflow. These are controls to implement in the source system, connector or workflow—not capabilities Thermus supplies. [Gmail API scopes](https://developers.google.com/workspace/gmail/api/auth/scopes) [Google Workspace restricted email delivery](https://support.google.com/a/answer/2640542)

**An approval prompt is not the same as disabling an action.** In ChatGPT, the permission named "Allow read actions" allows reads without prompting but asks before changes; use supported action controls and provider permissions to prohibit unwanted writes. Some apps do not expose individual action controls. [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)

Record a human owner for the agent, protect its credentials, review its grants and provide a way to revoke its access without relying on changing an employee's personal permissions. Verify that the actual connection uses the intended restricted identity; a mailbox name or alias alone is not enough.

Thermus does not provision or secure these identities and connectors or manage their permissions. They remain a separate responsibility.

### 3. Connect Thermus as the approved public-web gateway

Run Thermus yourself or use Hosted. For Hosted, follow the activation and MCP steps above. For self-hosted Thermus, use the endpoint and authentication details supplied for your deployment. Add the MCP server through the AI platform's approved custom-connector process. Make it available to the intended employees while keeping alternative public-web routes disabled. Do not assume that adding an MCP server intercepts or reroutes other tools.

For requests routed through Thermus, the GET-only tool validates its URL and reason inputs, checks product access, and cleans returned webpages. The reason is recorded, not scored. Tool completion records use the authenticated user and workspace in operator logs. Hosted free early access does not provide customer audit-log access or export. Configure separate controls for sensitive data in URLs; Thermus has no POST uploads or human approval steps.

The intended result is approved internal data access through restricted connectors, and agent-initiated public-web access through Thermus. "Only path" refers to this public-web access—not communications with the AI provider or separately approved internal connectors.

### Verify before rollout

Test with an ordinary employee account, the actual agent identities and synthetic data. Required internal reads and approved writes should work. Verify which identity each connector authenticates as, that unrelated employee inboxes/files/datasets are inaccessible, and that sends, invitations, edits and sharing outside the approved boundary are blocked. Include a cross-connector test: synthetic confidential information obtained through one tool must not reach an unauthorized recipient or audience through another. Native search, direct URL fetches and independent code/browser requests should not bypass the controls. For self-hosted deployments, operators should check the tool completion records for the authenticated subject and workspace. The dedicated identity used by an internal connector is separate from the identity of the Thermus connection. Hosted customers have no audit-log access or export in this offer.

**Temporarily disable Thermus in the test environment: the agent should have no alternative route for a live public-web request.** Use destination-side or platform evidence as well as Thermus logs; an absent Thermus log alone cannot prove a bypass was blocked. Test fresh sessions after policy changes and review already-running or scheduled work separately. Repeat the checks when enabled tools, actions or policies change.

Only describe Thermus as the sole public-web route after these checks pass. Any remaining exception must be explicitly documented as outside Thermus's coverage.

## Platform controls and deployment prerequisites

Vendor documentation reviewed on 2026-10-15. These notes verify available platform building blocks, not a tested Thermus integration or a guarantee that every network route is closed. Menu names, plans and capabilities can change. Apply this pattern to managed company workspaces; do not assume it governs personal accounts or other AI products.

### ChatGPT Enterprise and Edu

**Native web access.** Owners and admins can disable Web search in workspace administration. This covers ChatGPT and GPTs created in that workspace, but explicitly excludes third-party GPTs. For the protected group, also block third-party GPTs or separately review and constrain every approved one. GPT access and GPT action domains have their own controls. [ChatGPT search for Enterprise and Edu](https://help.openai.com/en/articles/10093903-chatgpt-search-for-enterprise-and-edu) [Managing GPT access in Enterprise and Edu](https://help.openai.com/en/articles/8555535-gpts-chatgpt-enterprise-version)

**Other modes and effective permissions.** Review all workspace defaults and role assignments, and confirm effective access using an ordinary member account. Disable agent mode and deep research for the protected group unless their outbound paths are separately governed. Review network-capable code, Canvas and any other enabled execution or browser tools as well. The public docs describe agent-mode administration and deep-research access separately. [ChatGPT role-based access controls](https://help.openai.com/en/articles/11750701-managing-feature-access-with-role-based-access-control-in-chatgpt) [ChatGPT agent](https://help.openai.com/en/articles/11752874-chatgpt-agent) [ChatGPT deep research](https://help.openai.com/en/articles/10500283-deep-research)

**Lockdown Mode is an optional restricted baseline, not proof of Thermus compatibility.** Where supported, it restricts live browsing and Canvas networking and disables deep research and agent mode. Managed-workspace app access remains dependent on workspace and role configuration. Confirm that the intended Thermus tools can operate under the chosen restrictions; do not assume an exception is available or sufficient. Lockdown Mode does not control Codex network access. [ChatGPT Lockdown Mode](https://help.openai.com/en/articles/20001061-lockdown-mode)

**Custom MCP support.** OpenAI documents custom MCP server connections on ChatGPT web for Business and Enterprise/Edu. In the current Plugins flow, authorized users can add a custom MCP server, configure its endpoint and authentication, and review the discovered tools; workspace publication and access remain governed by admin controls. Legacy workspaces may still expose the Apps flow. MCP support alone does not establish that a plan provides every control needed for this deployment. The web-search shutdown verified here is specifically documented for Enterprise/Edu; do not infer equivalent Business or personal-account enforcement from MCP availability. [Developer mode and MCP apps in ChatGPT](https://help.openai.com/en/articles/12584461-developer-mode-and-full-mcp-connectors-in-chatgpt)

### Claude Team and Enterprise

**Native web access.** Owners can turn off Web search in Organization settings > Capabilities. Claude's search documentation also describes direct web fetch as available when web search is enabled. Test direct-link retrieval as well as search in the actual deployed experience. [Claude web search](https://support.claude.com/en/articles/10684626-enable-and-use-web-search)

**Code execution and browser access.** In Organization settings > Capabilities, turn Allow network egress off for code execution when requiring a strict single public-web route. Package-manager-only access is still an additional network path. This setting does not govern web search, web fetch or MCP connections. Review those separately and disable Claude in Chrome for the protected group if it would provide another browser path. Cowork applies changed network settings to new sessions, not already-running conversations. [Claude code execution and network access](https://support.claude.com/en/articles/12111783-create-and-edit-files-with-claude) [Claude Cowork organization controls](https://support.claude.com/en/articles/13455879-use-claude-cowork-on-team-and-enterprise-plans)

**Custom MCP support.** Owners can add approved remote connectors in Organization settings > Connectors. Users then connect as required. Remote MCP requests originate from Anthropic's cloud, so the server needs an appropriately authenticated endpoint reachable from that environment; a server available only on an employee's laptop is not automatically usable by Claude web. Confirm Thermus's actual supported hosting and authentication with its team. [Claude custom connectors using remote MCP](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp)

### Deployment information still required

The Hosted endpoint and activation steps are above. This guide does not include self-hosted installation commands or an end-to-end tested ChatGPT/Claude recipe. Obtain deployment-specific implementation details and validation evidence from the Thermus team and the deploying organization. The checks above are acceptance criteria to run, not tests already performed.

For other platforms, first verify both prerequisites: approved MCP connectivity and enforceable removal or governance of every alternative public-web route. Treat each additional product surface or runtime as a separate deployment to validate.

## What if built-in browsing stays enabled?

The agent can reach the web without Thermus, and those requests aren't checked, cleaned or logged. Thermus is meant to be the agent's only way onto the web.

## We've locked down coding agents. Do we still need this?

Probably. Agents aren't only in coding tools. They're built into SaaS products like Agentforce and Notion and into low-code tools like Zapier and Lovable. If employees can build agents in any of those that reach the internet and internal data, you have the problem.

## Related topics

- [Agent identities and connector permissions](https://thermus.ai/guide/internal-connectors.md)
- [Self-hosted and Hosted options](https://thermus.ai/guide/pricing-hosting.md)
- [Request logs and workspace attribution](https://thermus.ai/guide/audit-logs.md)