Security and audit

What the assistant can reach

  • The MCP server only exposes the tools on the Tools reference. There is no general database or file access.
  • Signed-in people get their own CMS visibility. Managers and group editors are fenced to their groups on every read and write tool, and can never target "everyone".
  • Tokens act as the admin who created them, or as the system user when they were created that way or their creator has been deleted, and see the whole company, limited by scope. Prefer the sign-in flow for people, and tokens for automations.
  • Survey results never include respondent names, but they do include up to 15 recent free-text answers per question in the respondents' own words. Anonymous surveys below the respondent threshold hide the question entirely, free text included. Free text is never split by department. Whistleblower forms and their responses are never returned. Hidden form responses are left out.
  • People tools return work contact details: search_users gives each employee's email address, and get_user their email address and phone number. Only give read:users to clients that may hold them.
  • Phone numbers are left out when the company hides phone numbers in the app.

Nothing publishes on its own

Created content is a draft. These changes are live at once:

  • assignments of courses and journeys, which are dry runs until the person approves,
  • additions to already published content (chapters, quizzes, appended blocks) and new covers on it, which the assistant is instructed to confirm with the person first,
  • new groups, which create_group creates live (the assistant is told to check existing names first),
  • walls that create_wall or update_wall publish, which they only do when the person asks.

See Working with an assistant.

Logging

Every tool call and resource read is logged with:

  • who made it (person or token) and which client (Claude, ChatGPT, Gemini, Claude Code, Cursor and so on),
  • the tool name and its arguments (cut at 10,000 characters),
  • the outcome: success or the error message, and response time,
  • IP address and user agent.

Rejected requests are logged too. Logs are kept for 90 days. Monotree uses them to monitor the beta and to help with support questions.

Calls made through call_open_api also appear in the Open API request log (Open API → Logs → API Request Logs in the CMS). Failed calls are always logged there; successful ones only when request logging is enabled for the company. Each call runs on a token created for that one call and deleted right after, so these rows show no token. They carry the IP address and user agent of the assistant's call, the same as its entry in the MCP log above.

Managing connections

  • CMS → Open API → MCP lists the company's signed-in connections that still hold a live access token, so those used in the last 12 hours: person, client, and when that access token was issued and expires. Admins can disconnect any of them; the client loses access at once.
  • People can also remove the connector in their AI client.
  • Token access is managed under Open API → API Tokens, where a token is revoked like any other.
  • Connections that are unused for 90 days expire and are cleaned up automatically.

Transport

  • HTTPS only. The server is https://customer.monotree.com/mcp.
  • OAuth 2.1 with PKCE. Access tokens last 12 hours; refresh tokens 90 days.
  • 60 requests per minute per person or token. Over the limit, the server returns 429.
  • The feature is off by default and enabled per company by Monotree.

Reporting a concern

Email your Monotree contact or use the feedback endpoint. Security reports are handled with priority.