Teramind

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