The Google Workspace MCP server lets Claude, Cursor, ChatGPT, and AI agents read Gmail, Drive, Docs, Calendar, and Chat. Here's the official setup, the real security risks, and how to deploy it with DLP-grade redaction across the full Workspace surface.
.webp)
taylorwilsdon/google_workspace_mcp cover more surfaces (Tasks, Forms, Slides) and are widely deployed.[REDACTED_PII] placeholders. Useful, but narrow — no PHI detection, no source-code/secret detection, no OCR inside images and scanned documents, no vault-redaction flow, no per-call audit evidence formatted for SOC 2 / HIPAA / PCI.The Google Workspace MCP server is a Model Context Protocol implementation that exposes Google Workspace's APIs as a standard set of tools to AI agents. Once connected, an agent like Claude can read your inbox, search your Drive, draft a Doc, schedule meetings on your Calendar, post to a Space in Chat, and act across the full Workspace surface — under the authenticated user's permissions.
Google publishes the official MCP servers for the major Workspace products: Gmail, Drive, Calendar, Chat. The implementation is split per product (the Drive MCP server is its own configuration, the Gmail MCP is its own, etc.) and you wire each one up via Claude's Settings → Connectors → Add custom connector flow with an OAuth client ID and secret.
Common tools the Google Workspace MCP servers expose:
gmail_search_messages, gmail_get_thread, gmail_send_message, gmail_draft_message, gmail_modify_labels, gmail_list_attachmentsdrive_search_files, drive_get_file, drive_download_file, drive_create_file, drive_share_file, drive_list_permissionsdocs_get_document, docs_create_document, sheets_get_values, sheets_update_values, slides_get_presentation, slides_create_slidecalendar_list_events, calendar_get_event, calendar_create_event, calendar_modify_eventchat_list_spaces, chat_list_messages, chat_post_message, chat_get_memberIn addition to Google's first-party servers, a popular community implementation bundles all of the above into a single deployable MCP server with broader surface coverage (Tasks, Forms, Search). It's what most engineering teams use in practice when they want one configuration for the whole Workspace.
From the user's perspective, the AI agent suddenly knows their Workspace. From the security perspective, the AI agent now has read access — and often write access — to every document, message, and calendar entry the user can touch.
That's the value. It's also where every healthcare, fintech, and enterprise security team should pause.
Google's own AI Security and Safety documentation is explicit that MCP-mediated agent access creates a new data surface that traditional DLP was not built for. The risks fall into five categories.
1. Gmail returns regulated data in every search. When an agent calls gmail_search_messages for "customer contracts" or "Q3 forecast", the response is a list of full message bodies — frequently containing customer PII, employee PHI, salary data, M&A keywords, attached PDF previews, and credentials pasted into threads. All of it flows into the model's context window without inspection.
2. Drive is a goldmine the agent can grep. drive_search_files matches across every file the authorizing user has read access to — including files shared in error, files inherited from prior teams, files containing regulated data the user forgot they had access to. A single tool call can return a Drive folder full of clinical research, customer lists, or M&A drafts.
3. Doc fetches pull raw content into the model. docs_get_document returns the full text of a Google Doc, including images embedded inside it. If the doc contains a screenshot of a patient record, an exported credit-card-prefilled CSV, or a list of API keys — the agent now has it.
4. Sheets is a leak vector most teams ignore. sheets_get_values returns cell-level data — including PII columns (names, emails, phones, addresses) and PHI columns (MRNs, ICD-10 codes, lab values) that live in spreadsheets across nearly every Workspace tenant. No row-level access control survives the MCP call.
5. The write tools create exfiltration paths. gmail_send_message, drive_create_file, chat_post_message all let the agent emit data into Workspace from somewhere else. A compromised or confused agent that read a customer record and posts a summary into a wide-open Chat space is a data breach in one call.
Google's own remediation guidance is to use Sensitive Data Protection (SDP) — formerly Cloud DLP — to build de-identification templates that mask data flowing through MCP interactions. The official template Google recommends covers six PII categories with a static [REDACTED_PII] placeholder:
That is useful starting coverage. It is also, on its own, insufficient for any enterprise that handles PHI, source code, secrets, regulated data outside the six categories, or any data inside images and scanned documents. Symantec is in the market explicitly because Google's native coverage isn't enough — they've publicly partnered with Google Cloud to add DLP scanning at the Agent Gateway layer.
For organizations that need broader detection, deeper inspection, and audit evidence formatted for SOC 2 / HIPAA / PCI / GDPR — the answer is a category-defining MCP DLP layer above the Workspace MCP servers, not below them.
Strac's Google Workspace MCP DLP sits between AI agents and Google's official MCP servers. Every tool call — Gmail search, Drive get, Doc fetch, Sheets read, Calendar list, Chat history — passes through Strac's MCP-layer inspection before content reaches the AI agent's context window. Sensitive content is redacted, tokenized, or vaulted depending on policy. Non-sensitive content flows through untouched.
What that looks like in practice across the Workspace surface:
gmail_search_messages, Strac inspects every returned message body and attachment. PII, PHI, credit card numbers, API keys, source code, and content inside attached images (via OCR) are redacted inline. The agent gets the email context with regulated data removed.drive_get_file responses pass through Strac before the file content reaches the agent. PDFs, DOCX, XLSX, ZIP archives, and image files are all parsed and inspected with the same depth Strac applies across its DLP product line. Cross-account / cross-tenant edge cases are handled gracefully.sheets_get_values on a tab with PII columns returns tokenized values to the agent (e.g., <EMAIL_REDACTED>, <MRN_REDACTED>) — the analytics still work; the regulated data stays out of the AI context.Beyond the six PII categories Google's native template covers, Strac detects:
Every invocation produces a structured audit entry: AI client, user, Workspace product, tool name, resource accessed, data classes detected, redactions applied, vault references, disposition. The log is exportable to your SIEM and formatted for the audit evidence SOC 2, HIPAA, PCI, and GDPR auditors will actually ask about.
Setup is agentless and takes under 10 minutes per Workspace tenant.
json
"mcpServers": {
"google-workspace": {
"url": "https://mcp.strac.io/google-workspace",
"auth": { "type": "bearer", "token": "<your-strac-token>" }
}
}
For Cursor, OpenAI Agents, Cowork, and custom agents — same endpoint, same auth.No application code changes. No agent SDK changes. No Workspace re-permissioning.
The compliance evidence is generated per tool call automatically. It is the same evidence Strac produces across every other SaaS MCP DLP integration — so a single audit cycle covers the whole MCP control plane.
1. Healthcare operations team uses Claude to summarize patient correspondence. Care coordinators search Gmail for "discharge summaries this week" and ask Claude to triage. Without DLP, every PHI-laden thread flows into Claude's context — HIPAA violation. With Strac, PHI is tokenized inline; Claude still produces an accurate summary; the BAA-uncovered AI surface never sees PHI. (See Is Claude HIPAA Compliant? for the broader healthcare context.)
2. Fintech engineering team uses Cursor with Drive MCP to find production runbooks. Engineers search Drive for "incident runbook auth service" and Cursor pulls the matching docs into context. Without DLP, the runbooks contain pasted production credentials, customer IDs, and database connection strings. With Strac, the secrets are tokenized to <REDACTED:API_KEY> and <REDACTED:DB_CONN> placeholders — the engineer still gets the runbook flow, the secrets never enter the AI context.
3. Enterprise sales operations uses an internal agent to draft account briefs from Gmail + Drive. The agent searches Gmail for prior customer correspondence, pulls related Drive docs, and drafts a brief. Without DLP, the agent ingests every contract, every deal-size discussion, every CC'd executive's PII. With Strac, sensitive deal details are vaulted (replaced with retrieval links resolvable only by authorized viewers), keeping the workflow productive while the regulated data stays compartmentalized.
The Google Workspace MCP server is a set of Model Context Protocol implementations published by Google that let AI agents (Claude, Cursor, ChatGPT, Perplexity, custom agents) read and act inside Gmail, Drive, Docs, Sheets, Slides, Calendar, and Chat via standardized tool calls. It's the official way to wire an AI assistant into Workspace, separate from the Workspace API SDKs.
You need a Claude Enterprise, Pro, Max, or Team plan (Claude Free is not supported for custom connectors). Then: create a Google Cloud project, enable the relevant Workspace APIs, create an OAuth client with https://claude.ai/api/mcp/auth_callback as an authorized redirect URI, and add a custom connector in Claude Settings → Connectors using the OAuth client ID and secret. Google's official setup guide walks through the full flow.
By itself, no — not without an additional DLP layer. The Workspace MCP server honors the authorizing user's permissions but returns whatever that user can see, including PII, PHI, credentials, source code, and other regulated content. Google's own AI Security and Safety documentation recommends adding a DLP layer (Google's own SDP for basic coverage; third-party solutions like Strac for production-grade enterprise coverage).
Google's recommended template covers six PII categories: person names, email addresses, phone numbers, credit card numbers, US Social Security numbers, and street addresses — each replaced with a static [REDACTED_PII] placeholder. That's a useful starting point. It does not cover PHI, source code, credentials, secrets, custom data classifications, or content inside images and scanned documents. For most enterprises, a broader DLP layer is required.
Three differences that matter. (a) Detection breadth: Strac covers PII, PHI, PCI, secrets, source code, custom ML detectors, and OCR inside images — beyond Google's six PII categories. (b) Remediation: Strac supports redaction, tokenization, and vault-redaction (replace with a short-lived secure-retrieval link), not just static [REDACTED_PII] placeholders. (c) Audit evidence: Strac produces per-call SOC 2 / HIPAA / PCI / GDPR-mapped evidence; Google's SDP is built for the GCP audit context, not the broader compliance program.
google_workspace_mcp server (taylorwilsdon)?Yes. Strac sits in the MCP protocol layer, so it works with Google's official Workspace MCP servers, the community google_workspace_mcp aggregator, and any future Workspace MCP implementation. Same Strac MCP endpoint in your AI client's connector config — Strac transparently proxies and inspects the traffic.
Under 10 minutes for the first Workspace tenant. OAuth Strac into Workspace, paste the Strac MCP endpoint into your AI client's config, pick a policy template, done. No agents to install, no Workspace re-permissioning, no application code changes.
Redacted content is replaced inline in the tool response. Optionally, sensitive content can be vaulted — replaced with a short-lived retrieval link that only authorized users can resolve, so the original data is retrievable for legitimate use without ever entering the AI context. Vaulted data is stored encrypted at rest in your Strac tenant; you control retention.
Yes. Strac produces a per-call audit log: timestamp, AI client identity, user, Workspace product (Gmail / Drive / Docs / etc.), tool invoked, resource accessed, data classes detected, redactions applied, vault references, disposition. The log is queryable in the Strac console and exportable to your SIEM. This is the evidence trail SOC 2, HIPAA, PCI, and GDPR auditors will ask about for AI-agent activity in Workspace.
The Google Workspace MCP server is on track to become the way every AI agent reaches into your Workspace. That surface includes every email, every doc, every calendar invite, every spreadsheet, every Chat message — and the regulated data living in all of them. Running Workspace MCP in 2026 without an MCP-layer DLP control is not a question of if the first incident reaches your security team; it's when.
Strac Google Workspace MCP DLP gives you the inspection layer, the redaction and vaulting flow, the audit evidence, and the framework-agnostic compliance coverage — across Gmail, Drive, Docs, Sheets, Slides, Calendar, and Chat in one control plane.
If you are running — or about to run — Google Workspace MCP in production, book a 30-minute demo. We'll walk through the architecture, the policy templates, and a deployment plan for your specific Workspace tenant and AI clients.
For the broader MCP DLP control plane across every SaaS surface, see the MCP DLP pillar. For Workspace-product-specific deep dives, see the Gmail MCP and Google Drive MCP guides.
.avif){kind=icon}
.gif)
