Teramind MCP Server

Teramind MCP Server

MCP server for Teramind's insider-threat/employee-monitoring API - computer inventory, agent (user) inventory, departments, alerts, anomaly-rule and behavior-policy configuration, and monitoring-profile metadata - for AI assistants and the WYRE Conduit gateway.

This connector is PII-dense by construction (insider-threat/employee-monitoring product) and requires security review before merge - see Scope and Credential scope below.

Authentication

Teramind authenticates with a JWT Access Token, self-generated per-account in the Teramind dashboard (User menu -> Access Tokens), sent as the x-access-token header. There is no OAuth flow.

Teramind's API is per-customer-instance (cloud or on-premise/private-cloud) - there is no shared multi-tenant base URL like most other connectors in this catalog. Every credential set also carries the customer's own instance URL (e.g. https://yourcompany.teramind.co). In gateway mode both arrive per-request via the X-Teramind-Access-Token / X-Teramind-Instance-Url headers; in local/stdio mode they're read once from TERAMIND_ACCESS_TOKEN / TERAMIND_INSTANCE_URL.

Configuration

Tools

Computers

• teramind_list_computers - list monitored computers (hostname, FQDN, MAC/IP, OS, monitoring status).
• teramind_get_computer - get full detail for a single computer.

Agents (users)

• teramind_list_agents - list monitored agents (Teramind's term for a monitored employee/user identity): id, name, email, avatar, online status.
• teramind_get_agent - get full detail for a single agent.

Departments

• teramind_list_departments - list departments (org-structure metadata).
• teramind_get_department - get full detail for a single department.

Alerts

• teramind_list_alerts - list fired rule-violation events in a time window, optionally filtered by agent/computer/department.

Anomaly rules

• teramind_list_anomaly_rules - list configured ML-based anomaly-detection rules (type, risk quotient, trigger conditions).
• teramind_get_anomaly_rule - get full detail for a single anomaly rule.
• teramind_list_anomaly_rule_tags - list the tags available to categorize anomaly rules.

Behavior policies

• teramind_list_behavior_policies - list behavior policies (what activity type each policy watches and its match conditions).
• teramind_get_behavior_policy - get full detail for a single behavior policy.
• teramind_list_behavior_policy_groups - list behavior policy groups (the containers that organize behavior policies).
• teramind_get_behavior_policy_group - get full detail for a single behavior policy group.

Monitoring

• teramind_list_monitoring_profiles - list monitoring profiles (which data types are configured to be captured, and for whom).

Account

• teramind_get_account - get the authenticated account's own settings (credential sanity check).

Scope

This is a deliberately narrow, read-only v1 surface, scoped MORE conservatively than this catalog's usual bar given the sensitivity of an insider-threat/employee-monitoring product. Teramind's documented API (fetched directly from its published Postman collection, apidoc.dev.teramind.co) has 239 operations across dozens of product areas (monitoring, BI reporting, time tracking, scheduling, productivity classification, LDAP, task management, scheduling). This connector implements 16: literal HTTP GET reads covering only computer/user/session inventory, department metadata, and rule/alert configuration. Every tool is classified isAdmin: true in the Conduit gateway regardless of verb, given the sensitivity of employee-monitoring data.

No literal GET endpoint exists for session inventory. Teramind's session data (Sessions report, Login session BI grid) is only reachable through POST query/grid-style endpoints, not a plain resource GET - documented here as a finding, not fabricated as a tool. Session data is out of this connector's v1 scope as a consequence, not a separate exclusion decision.

Hard-excluded: anything that returns actual monitored content, or mints/reveals a credential - by name, even where the verb is GET

Per this connector's scope boundary, the distinction is: metadata about monitoring (who is monitored, when, what rule fired) is in scope; the actual captured content of what was monitored, or a mechanism to obtain a live credential, is not, regardless of read/write verb.

No GET endpoint anywhere in Teramind's documented API returns raw keystroke logs, chat/IM content, printed-document content, or social-media activity content - those are exclusively reachable through the POST /tm-api/report/*/grid and POST /tm-api/wip/tma-query (BI) families, which this connector excludes as a category below. This connector's GET-only scope therefore rules out keystroke/screenshot/chat-content exposure by construction, not merely by the per-endpoint judgment calls above - see Credential scope for what this claim does and does not cover.

Excluded by category (out of the named scope: computer/user/session inventory + rule/alert data)

They can be added as a follow-up if there's demand, after a deliberate scope decision - not by default.

Field-level restriction, not just endpoint-level

GET /tm-api/v1/agents[/:id] supports an optional fields query parameter that can return salary_type and default_wage (compensation data) and ldap_attrs (raw directory attributes) - HR/PII data well beyond "who is monitored." This connector's client.ts never passes that parameter, so only the default identity fields (agent_id, name, email_address, avatar, online) are ever returned, regardless of what a caller requests through the tool's input schema (there is no fields parameter exposed on teramind_list_agents / teramind_get_agent at all).

Judgment call flagged for reviewer attention: alert content

teramind_list_alerts is squarely in this connector's named scope ("rule/alert data"), and its response shape is documented by Teramind to include description/caption/values fields describing why a rule fired. Depending on the rule type, those fields may carry a short excerpt of the triggering context (e.g. a matched keyword, or a visited URL) rather than pure metadata - this is passed through as Teramind returns it, unmodified. This was judged in-scope because alerts are explicitly named in this connector's scope and the excerpt (if present) is bounded to what a human already configured a rule to flag, not raw unfiltered activity capture - but it is flagged here explicitly, per this task's instruction, rather than decided unilaterally as a closed question.

Credential scope (read this before connecting a real account)

This is the single most important finding in this README. Two claims, deliberately kept at different confidence levels:

(1) STRUCTURALLY VERIFIED - this connector's own code never calls a content-capture, credential-issuance, or write endpoint. Confirmed against client.ts: exactly 16 functions exist, one per tool, each a literal GET against one of the endpoints listed in the Tools section above; there is no wildcard/passthrough/generic-request function anywhere in src/. This connector is read-only and non-content-capturing by construction.

(2) VENDOR-DOCUMENTED, NOT INDEPENDENTLY VERIFIED - whether the underlying access token itself can be restricted to a metadata-only scope is a separate question from what this connector's code calls, and the answer is more nuanced than a clean yes/no:

• Per Teramind's own Knowledge Base ("User Menu"; "How to change a user's access level" - both fetched directly, 2026-09-20), an access token inherits the full permissions of whichever account created it, fixed at creation time. Teramind does not offer a token-scoping mechanism independent of account role.
• The default case - a single full "Administrator" account, which is what a fresh self-serve cloud trial signup produces - has NO restrictions. A token created there can reach every one of Teramind's 239 documented operations, including screen recordings, keystroke logs, and email/chat content capture. This connector's code never calls those endpoints, but the credential itself is not restricted unless the customer takes deliberate, manual, vendor-side action beyond anything this connector or Conduit controls or verifies.
• Teramind does document a reduced role, "Operational Administrator," that CAN create its own access tokens and is explicitly documented as unable to "browse any recordings or view monitoring data" and unable to see "Alerts" (per Teramind's "How to change a user's access level" article, quoted directly). This is the closest documented approximation to a metadata-only token - but (a) it is a manual account-configuration choice the customer must make, not anything this connector or the Conduit connect flow enforces or checks at connect time; (b) Teramind's documentation describes this as menu/UI-level access, and no independent test was performed sending a request with an Operational-Administrator-scoped token against one of this connector's excluded endpoints to confirm a real server-side 403 versus a UI-only restriction; and (c) that role is explicitly documented as also blocking Alerts, which this connector treats as in-scope - so even the reduced role doesn't map cleanly onto this connector's own scope boundary.
• A further role, "Infrastructure Administrator," is more restrictive still, but (a) cannot create its own access tokens at all (only be assigned one after creation by an Administrator), and (b) per Teramind's docs is "not able to list employee or computer accounts" - i.e. it would also block this connector's own computer/agent inventory tools, so it is not a usable configuration for this connector's purpose either.

Net finding: by default, nothing about the Teramind access token credential itself prevents it from reaching every endpoint this connector deliberately excludes. The connector's own code is the actual control boundary (per point 1 above), not the credential. Recommendation for whoever operates Gate 3 review or advises customers connecting this vendor: consider documenting that customers should create the token under a dedicated Operational Administrator account rather than a full Administrator, as defense-in-depth against a differently-configured client reusing the same stored token - while treating this connector's own code (which never calls a content-capture endpoint) as the primary, verified control.

Development

npm install
npm run build
npm test
npm run lint   # tsc --noEmit

Docker

docker build -t teramind-mcp .
docker run -p 8080:8080 -e TERAMIND_ACCESS_TOKEN=... -e TERAMIND_INSTANCE_URL=https://yourcompany.teramind.co teramind-mcp