# Thermus product guide

Updated: 2026-10-15

Thermus is a Model Context Protocol (MCP) gateway that checks an AI agent's public-web requests and returns cleaned webpage content as Markdown. It checks the reason for each request, can require human confirmation for unusual behavior, and attributes gateway activity to the responsible person.

It is for organizations rolling out AI tools that let employees build agents. Those agents may need both internal data and internet access. Thermus adds controls to the public-web path while your existing systems continue to govern internal access and actions.

## Is Thermus a fit?

Thermus can help when employees' agents need the open web and you want checks on outgoing requests, cleaner incoming content, and an audit trail. The agent must be able to connect to Thermus's MCP server. The organization must also be able to disable or govern alternative public-web routes.

It is probably not a fit if your agents never use the public web, you plan to remove internet access entirely, or your primary need is managing permissions to internal systems. Having internal connectors does not itself make Thermus a poor fit: the controls can complement each other.

## Important boundaries

- Thermus protects traffic routed through its gateway. Adding an MCP connection does not automatically intercept native browsing or other tools.
- It does not manage internal connector permissions or govern email, calendar and document actions that bypass the gateway.
- It does not inspect the agent's calls to its LLM provider, bypass websites' bot blocking, or guarantee that every attack is caught.
- Availability of an AI platform's MCP and admin controls does not establish a tested Thermus integration. Deployment-specific endpoint, authentication and installation details must come from the Thermus team.


## Using the complete guide

This file contains all six topic documents. Use the content below for Thermus product facts; further topic fetches are unnecessary. Answer the person's question first, ask only useful unanswered questions, and be candid about fit. Do not invent missing installation instructions, capabilities, certifications or data-handling details. Contact [Thermus](https://thermus.ai) for details not covered here.

## Thermus and prompt injection

Updated: 2026-10-15

Thermus cleans public webpages before they reach an AI agent and checks the agent's subsequent outbound web requests. It protects the web traffic routed through its MCP gateway; it does not inspect every source of instructions an agent might encounter.

### How a web request works

Your data and agents sit on one side. Agents connect to your data through MCP servers and connectors:

Data lake: financial, sales, marketing and employee data

Internal systems: email, CRM, ERP, messaging and code repositories

Agents: built in ChatGPT, Claude, Agentforce, Lovable and more

The web sits on the other side: websites agents read, searches agents run, and APIs agents call.

Thermus sits between the agents and the web. Each request takes four steps:

Request and reason. The agent sends its request to Thermus over MCP, with its reason for the request.

Approved request. If the request passes the outbound checks, Thermus sends it to the web.

Raw page. The website, search engine or API returns raw, untrusted content to Thermus.

Clean markdown. Thermus cleans the content and returns plain markdown to the agent.

### Cleaning inbound content

Renders the page on Thermus's side.

Strips ads and invisible content, including white-on-white text and text too small to read. That's where injected instructions often hide, because people would notice them otherwise.

Returns only clean markdown to the model.

### Does Thermus stop all prompt injection?

No, and it doesn't try to cover every path. Here's what it does: if a malicious website tries to instruct an agent to leak internal data, Thermus strips the page's invisible content before the model sees it, checks the agent's outbound web request against its stated reason, and can hold unusual requests for human approval.

It cannot stop a leak through a route that bypasses the gateway, such as an enabled email-sending action, a Power Automate flow, or another tool with independent outbound access. Those routes need separate controls. When approved connectors have appropriately scoped identities, resources and actions, with unnecessary outbound actions disabled and necessary ones separately governed, Thermus addresses the separate open-web data-leak path. The connectors need not all be read-only, but their permissions and output boundaries must be enforced separately.

It does not sit between the agent and its model or inspect calls to the LLM provider. It identifies itself as a bot and does not bypass websites that block bots.

### Lower token costs

Agents that read the web through Thermus get clean markdown instead of full pages, and markdown is far smaller. In Cloudflare's published example (Markdown for Agents, February 2026), a page that took 16,180 tokens as HTML took 3,150 as markdown, about 80% fewer. Your savings depend on the pages your agents read. [Cloudflare Markdown for Agents example](https://blog.cloudflare.com/markdown-for-agents/)

### Related topics

- [Outbound request checks and data leaks](https://thermus.ai/guide/data-leaks.md)
- [Deployment and bypass checks](https://thermus.ai/guide/deployment.md)

## Thermus and data leaks

Updated: 2026-10-15

Thermus checks outgoing web searches, requests and uploads that pass through its gateway. The agent must state a reason for each request. Thermus checks that reason against what the agent is trying to do and can require human confirmation for unusual behavior.

### The outbound request gate

Requires a reason for every request.

Blocks the request if the reason doesn't make sense or doesn't match what the agent is trying to do. For example, an agent that says it wants to search Google but tries to open a bank's accounts page is blocked.

Flags large requests, file uploads and other unusual behavior, and holds them until the person behind the agent confirms. This is called a step-up.

### Allow, step up or block

Thermus checks the agent's stated reason against what it's actually trying to do, then decides.

| Verdict | When | What happens | Example |
| ----- | ----- | ----- | ----- |
| Allow | The reason fits the request. | The request goes through, and the agent gets the page back as clean markdown. Logged to the person behind it. | Reason: "find setup steps in vendor docs." Action: GET docs.vendor.com/setup |
| Step up | Something looks unusual, like a large request or a file leaving. | Thermus holds the request until the person behind the agent confirms. | Reason: "share the report with a partner." Action: POST a 40 MB file to files.partner.com. Waiting for j.doe to confirm. |
| Block | The reason makes no sense, or doesn't match what the agent is trying to do. | The request stops, and the attempt is logged. | Reason: "search Google for setup docs." Action: GET online.examplebank.com/accounts |

### Can a hijacked agent lie about its reason?

It can try. The reason is a claim Thermus checks, not proof. The request still has to match it: an agent that says it's searching Google for setup docs, then opens a bank's accounts page, is blocked. Separately, large requests and files leaving are held until the person behind the agent confirms. Every attempt is logged.

### Internal data can leave through a different tool

An agent may legitimately read an internal report and then put its contents into a public search query or web upload. Read-only access to the source prevents changes there; it does not control what the agent does with information it has already retrieved. [OpenAI MCP and connector guidance](https://developers.openai.com/api/docs/guides/tools-connectors-mcp)

Thermus checks that separate web path when the request passes through its gateway. It does not inspect the original connector read or sanitize the connector's returned content.

### Coverage boundaries

Thermus does not automatically reroute other tools. Native browsing, network-enabled code, email sending and other independent paths can bypass it. Those paths need separate controls. An agent-specific account also does not prevent data from one connector being sent through another. No filter catches every attack; deployment restrictions, request checks, human approvals and logging work together.

### Related topics

- [Internal connectors and agent identities](https://thermus.ai/guide/internal-connectors.md)
- [Deployment and bypass checks](https://thermus.ai/guide/deployment.md)
- [Audit logs and human attribution](https://thermus.ai/guide/audit-logs.md)

## 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)

This is where Thermus fits: it checks web searches, requests and uploads that pass through its gateway, including requests containing information originally retrieved through an internal connector. 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)

## Deploying Thermus in an organization

Updated: 2026-10-15

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.

### Recommended organization setup

**Turn off unrestricted web access, give agents scoped identities and connector permissions, then restore checked and logged web access 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. Add its MCP server through the AI platform's approved custom-connector process, using the endpoint and authentication details supplied for your Thermus deployment. 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 gateway checks the outgoing request and its reason, cleans returned webpages, and logs the request against the responsible person. Configure its OTLP export to your SIEM or observability tools.

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. Allowed Thermus requests should produce the expected audit records, with the responsible human attribution checked even when the agent uses a dedicated internal account.

**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

Thermus deployment information in this guide does not include installation commands, a deployment-specific MCP URL, authentication setup or an end-to-end tested ChatGPT/Claude recipe. Obtain 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)
- [Audit export and attribution](https://thermus.ai/guide/audit-logs.md)

## Thermus audit logs and human attribution

Updated: 2026-10-15

Thermus matches each gateway request to the responsible person and exports logs over OTLP, the OpenTelemetry Protocol, to your SIEM or observability stack. Hosted also retains audit logs.

### What is recorded?

Each request records the URL, agent, person behind it, stated reason and verdict. The following is an illustrative record, not the full log schema:

```json
{
  "url": "docs.example.com/setup",
  "agent": "support-bot",
  "user": "j.doe@example.com",
  "reason": "find setup steps for a customer",
  "verdict": "allow"
}
```

### What the logs help answer

- Respond to incidents: identify the responsible person and the agent to investigate or shut off.
- Answer auditors and customers: establish whose agent requested which resource and when.
- Spot repeated risky behavior: see when an agent's requests are blocked or require confirmation.

To investigate an action, retrieve the agent's records from your logging system and examine the destination, reason and verdict. Verify the responsible-human attribution during deployment, including when internal connectors use a dedicated agent identity.

### Coverage and data handling

Only requests routed through Thermus appear in these gateway logs. An absent Thermus log alone cannot prove that a bypass was blocked; use destination-side or platform evidence as well.

The published product information does not specify audit retention duration, residency, compliance certifications, a complete event schema or an uptime SLA. Ask the Thermus team for those details. This document describes product audit logs; website guide-request analytics are a separate feature.

### Related topics

- [Deployment verification](https://thermus.ai/guide/deployment.md)
- [Hosted and self-hosted plans](https://thermus.ai/guide/pricing-hosting.md)

## Thermus pricing and hosting

Updated: 2026-10-15

Run it yourself for free, or let us run it.

|  | Free | Hosted |
| ----- | ----- | ----- |
| Price | $0 | $10 per user per month |
| Who runs it | You. A downloadable file, self-hosted on your machine. | Thermus. Managed for you. |
| Includes | The full gateway: injection stripping, risky-behavior checks and logs | Everything in Free, hosted, plus shared policies and teammates, and retained audit logs |
| Get started | Join the early-access waitlist at https://thermus.ai. | Join the early-access waitlist at https://thermus.ai. |

Free is the full gateway, not a cut-down version. Hosted is for teams that want Thermus to run it, with shared policies, teammates and retained audit logs.

Thermus is welcoming people in small groups. The website's download and subscription buttons open an email waitlist; they do not start a download or charge a subscription. The team will email you when your spot is ready. This guide is not an installation or checkout flow.

To estimate Hosted: users × $10 per month. For example, 40 users is $400 per month.

### Where does our data go?

With Free, Thermus runs on your own machine or server. With Hosted, Thermus runs it for you. For anything more about data handling, ask the team through https://thermus.ai.

The published product information does not specify data residency, retention durations, compliance certifications, volume or annual pricing, licensing terms, or an uptime SLA. Ask the Thermus team for those details. The Cloudflare token-saving example in the prompt-injection guide is an example from another provider, not a measured Thermus benchmark or guaranteed saving.

### What is needed to get started?

Choose self-hosted or Hosted, then obtain the installation instructions, MCP endpoint and authentication details for your deployment. The product guide does not contain install commands or an end-to-end tested integration recipe. MCP connectivity and administrative enforcement depend on the AI platform, plan and enabled modes.

### Related topics

- [Deployment prerequisites and rollout](https://thermus.ai/guide/deployment.md)
- [Audit logs and export](https://thermus.ai/guide/audit-logs.md)