> ## Documentation Index > Fetch the complete documentation index at: https://docs.fitsociety.io/llms.txt > Use this file to discover all available pages before exploring further. # Security & Privacy > Business-readable security model for FITsociety MCP. FITsociety MCP is designed so AI clients only receive the data and tool access that the right account explicitly approved. ## Data use when connecting an AI assistant This page supplements the [FITsociety privacy policy](https://fitsociety.io/privacy-policy) for MCP connections, including ChatGPT. The assistant receives the FITsociety records needed for the actions you request within your approved permissions. Those records can include account and booking information, invoices and credits, training and nutrition records, measurements, goals and self-reported health information, documents, and private messages or coach notes. Sensitive modules require the separate consents described below. FITsociety uses the connection to carry out your requested coaching or fitness workflows. Your selected AI provider receives the requested results and handles them under its own terms and privacy policy. Enabled actions can also send data to intended message recipients, connected Google calendars, configured webhook recipients, or push and email delivery providers; those effects are stated in the relevant tool descriptions. Sharing is limited by the connection's account, company, module, and action permissions. You can review or revoke your AI connection in FITsociety's connection settings. Revocation blocks future access; it does not recall results already shared with your AI provider or notifications already delivered. Use the contact details in the FITsociety privacy policy for data-rights requests. There are two access surfaces: * **Company/coach grants** are approved by a Manager or Admin coach. * **Client AI grants** are approved by the authenticated client and are bound to that one client. They require the client to be connected to the company and to have client AI access enabled for that relationship, with the company MCP integration feature enabled. ## Company scoping Every MCP credential maps to one `CompanyMcpGrant`. Tool execution is resolved from that grant's company context, so the AI client cannot switch to another company by passing a different company ID. Client AI grants also store a client subject. The runtime passes `subjectType: "client"` and `subjectClientId` into the tool context, and client AI tools enforce that all reads and writes stay on that client. ## Feature gates All grants require the company MCP integration feature. Client AI grants additionally require client AI access for the client-company relationship and the company client MCP policy. If any of these gates is disabled later, the grant can still exist for audit and revocation, but `tools/list` and `tools/call` are blocked. ## Grant owner checks Each company/coach grant is owned by the coach who created the API key or approved the OAuth connection. At runtime, the backend verifies that the owner still has active company access and still holds a `Manager` or `Admin` role. If the owner is removed, deactivated, or demoted, the grant stops working. Client AI grants are not coach-owned; they are revoked by the client and are runtime-bound to the approved client subject. ## Read-only default MCP grants are read-only by default. Read-only grants can list, search, inspect, and summarize allowed data, but cannot create or update records. ## Explicit write tools Write access requires two separate choices: 1. The grant must not be read-only. 2. The specific write tool must be listed in `allowedWriteTools`. Every approved write call must also include a unique `idempotencyKey` argument or `params._meta.idempotencyKey`. The runtime durably stores the completed result before responding, so an exact retry replays the stored result without applying the mutation twice. If the mutation succeeds but replay-result persistence fails, the call returns an error and the claimed key remains in `processing` state. It is not converted to a replayable failure, because doing so could hide a completed mutation and encourage a duplicate write. The current write-tool registry is documented on the [Tools & Modules Registry](/mcp/tools) page. It includes company/coach write tools such as: * `create_client` * `create_booking` * `update_attendance` * nutrition-plan and nutrition-log editing tools * recipe create/update/archive tools * training template, assignment, session, performance, preset, and equipment tools * WOD create, update, publish, archive, and settings tools It also includes client AI write tools such as `client_ai_log_my_food`, `client_ai_log_my_measurement`, `client_ai_book_my_event`, and `client_ai_send_message_to_my_coach` when the client approved those tools. ## Health data consent Modules marked with `health` sensitivity require explicit health data consent. Without that consent, those modules are omitted from `tools/list` and cannot be called. Health-sensitive modules include: * company/coach modules: `measurements`, `intake`, `checkups`, `habits`, `goals`, `documents`, `nutrition_logs`, `workout`, and `wod` * client AI modules: `client_ai_nutrition`, `client_ai_measurements`, `client_ai_habits`, `client_ai_goals`, `client_ai_checkups`, `client_ai_workout`, and `client_ai_wod` ## Company records and external-data grants Company-owned nutrition records and measurements require an accessible client/company relationship and the MCP connection's health-data consent. Their reads and writes stay scoped to the connected company; the caller's date filters and applicable nutrition-plan dates remain enforced. The separate `CompanyClientData.dataAccessGrants` field is reserved for explicitly authorized external data sources, such as future wearable integrations. Empty, revoked, or date-limited external-data grants do not block or restrict these company-owned nutrition records and measurements. Do not grant external-data access to work around an unrelated MCP permission error. ## Private communication consent Modules marked with `private_communication` sensitivity require explicit private communication consent. Private communication modules include: * `conversations` * `client_notes` * `client_ai_documents` * `client_ai_messages` ## Audit logging Every authenticated runtime request is logged for review. The audit record must be durably persisted before the runtime response is sent. If that persistence fails, the request fails closed instead of returning an unaudited result. The audit log stores generic execution metadata such as: * grant * tool name * status * error code * duration * request IP * user agent * argument key names * changed entity identifiers and linked domain-audit identifiers where available These records support access accountability, incident investigation, and abuse prevention. MCP tool audit and anomaly records have an automatic 90-day retention period. Access to the company audit view requires an authorized manager or admin; revoking a grant stops further tool access but preserves these security records until their retention period expires. Business records created or updated by a tool follow the FITsociety privacy policy and the relevant account settings. Argument values, prompts, and tool result payloads are not stored in the MCP audit log. Request and result summaries are generated from fixed metadata such as method, tool name, read/write type, and success state; caller-provided text is not copied into those summaries. General HTTP error telemetry applies the same boundary: MCP and Public API request bodies and query values are omitted from 4xx/5xx logs and Sentry context. Only the HTTP method and query-free route path remain available for diagnostics. ## Transport and operational controls The official `@modelcontextprotocol/server` v2 handler validates the request `Host` and, when present, `Origin` against allowlists. Runtime bearer credentials are accepted in the `Authorization` header only. Persistent fixed-window limits protect request IPs and bearer-key identifiers. Tool execution also uses a persistent per-grant query budget and persistent per-company/tool circuit state, so protections remain effective across multiple application instances. Required protection failures return an error rather than bypassing the control. Client IP resolution uses Express with a bounded, deployment-configured proxy hop count. Raw forwarded headers do not override the resolved Express IP. ## Token expiration and revocation Company MCP API keys expire according to their configured lifetime. OAuth grants act as the revocation anchor for issued OAuth tokens. OAuth access tokens expire after 1 hour. OAuth refresh tokens expire after 90 days and rotate when used. Reuse of an already rotated refresh token revokes every still-active token in that grant/client family. The OAuth approval grant expires after 365 days unless revoked sooner. When a grant is revoked, its static API key stops working and all active OAuth tokens for that grant are revoked. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.