Built so an AI can help, but never change your tenant on its own.

TenantMCP connects AI assistants to your Microsoft 365 tenant. Because that is a sensitive place, the whole product is built around one idea: reads by default, writes only behind a human, and a full record of everything. This page explains the security model in plain terms and links to the legal detail.

Tenant isolation

Isolation is enforced at the token layer, not by trusting anything a client sends. The tenant a call operates on is derived entirely from the claims in a validated TenantMCP token - the Microsoft Entra tenant id maps to the tenant record, the object id maps to the user - never from request input. No tool accepts a tenant argument, so there is no parameter through which one caller could name or reach another tenant.

Each tenant's access to Microsoft Graph uses its own per-tenant, app-only token that TenantMCP mints for that tenant. The token your AI client holds is never forwarded to Microsoft Graph. An independent adversarial security review confirmed that cross-tenant isolation holds: tenant, Entra tenant id, and Graph token always come from a validated token claim mapped to a database record.

Approval-gated privileged writes and a full audit trail

Three independent gates stand between an assistant and a change to your tenant:

• Admin consent - an administrator approves TenantMCP for the tenant. The Microsoft consent screen requests read and write Graph permissions; granting it provides only the capability.
• Product opt-in - write tools stay switched off until an administrator turns on "Enable write actions" in the portal. Until then, no write tool is even visible or callable to your assistant.
• Per-action approval - when the AI invokes a write tool, it never calls Microsoft inline. The action is queued as a pending action for a human administrator to approve or reject in the portal, and executes only on approval.

Every tool call and every approval decision - the proposed change, who approved or rejected it, the reason, and the outcome - is written to an audit trail, exportable as CSV. There is no path from a tool call to a change in your tenant without a recorded human approval.

Admins-only access

TenantMCP is admins-only. The Service issues an MCP access token to a client only when the signed-in user holds an administrator role in the tenant, so a non-admin member cannot pull tenant-wide data through the Service. On our side, access to production systems and customer data is limited to authorised Circle of Bytes personnel on a need-to-know basis under role-based access controls.

The OAuth security model

You connect one URL and sign in with Microsoft. Behind that URL, TenantMCP runs its own OAuth 2.1 authorization server that fronts Microsoft Entra: your AI client authenticates to TenantMCP, TenantMCP sends you to your normal Microsoft login and consent, then issues its own token scoped to the MCP endpoint. Your Microsoft credentials and your tenant's Graph token are never handed to the AI client.

The tokens TenantMCP issues are hardened:

• Signed and validated with RS256 against a published public keyset; the token-signing service exposes public parameters only.
• Audience-bound (RFC 8707) to the MCP endpoint and rejected if the audience, issuer, or lifetime does not match. Algorithm-confusion and unsigned tokens are rejected.
• Short-lived, with rotating refresh tokens that can be revoked. Tokens are stored as hashes, not in plaintext.
• PKCE (S256) required on the authorization flow, with single-use authorization codes.

EU hosting on Microsoft Azure

TenantMCP is hosted in European Union Azure regions, chosen specifically to keep processing within the EU: application compute in the North Europe region and the database in the Sweden Central region, with secrets held in a managed key vault protected by role-based access control. Data is encrypted in transit (TLS) and at rest on the underlying Azure platform.

Data handling: a relay, not a warehouse

When an assistant asks a question about your tenant, TenantMCP calls Microsoft Graph, shapes the result, and returns it. We do not maintain a mirror or warehouse of your directory, devices, or documents, and we do not use your tenant data to train any machine-learning model.

What we do store are operational records, not tenant contents:

• Approval decisions - the proposed write, the approver, the reason, the outcome.
• Audit metadata - who invoked which tool, when, in which tenant, and the result.
• Metering counts - per-call counters for the free-tier call cap and billing.
• Tenant and configuration records - the Entra tenant id, enabled modules, consent status.
• OAuth token material - stored as hashes, never plaintext.

This keeps the personal data we hold to the minimum needed to run the approval and audit features. Details are in our Privacy Policy.

Who builds TenantMCP

TenantMCP is an independent product built by Circle of Bytes ApS (CVR 45063925), Denmark. Microsoft, Microsoft 365, Intune, Entra, and Copilot are trademarks of the Microsoft group of companies, referenced here only to describe compatibility.

Sub-processors

We keep our sub-processor footprint minimal.

Microsoft is also the operator of your own Microsoft 365 / Entra tenant, which is the source system TenantMCP relays from. Payment processing is handled by Stripe (Stripe Payments Europe, Ltd.), acting as an independent controller for the transaction. We give affected customers advance notice of any new or changed sub-processor as set out in the Data Processing Addendum.

Reporting a vulnerability

If you believe you have found a security issue in TenantMCP, please contact us at security@tenantmcp.com. We take reports seriously and will work with you in good faith. No system is perfectly secure; if we become aware of a personal data breach affecting customer data, we will notify affected customers without undue delay as required by the GDPR and the Data Processing Addendum.