Grok Can Read, Write, and Send Outlook Mail on First Connect

xAI's Grok can now act inside Microsoft 365 the way most people assumed ChatGPT would — search mail, draft replies, move messages, and send on your behalf. The detail that matters for builders and IT: Outlook permissions are full read-write-send from the first OAuth click, while Grok's Gmail connector starts read-only.

Late-August 2026 news — Grok 4.6 on Microsoft Foundry (August 26) and a OneDrive plugin (August 27) — put the connector story back on the timeline. But the Outlook read/write capability itself has been documented since May 2026, with a dedicated Outlook add-in shipping July 21, 2026.

TL;DR — what people are asking

Two surfaces: connector vs. add-in

Grok meets Outlook two ways:

1. Outlook Mail & Calendar connectors (all Grok users)

Documented on xAI's connector pages, split into two OAuth flows:

Outlook Mail

• Search and read messages (body, headers, attachments)
• Compose, manage drafts, reply-all, forward
• Send mail via Mail.Send
• Move messages, create folders, batch operations
• Upload Grok-generated artifacts as draft attachments

Outlook Calendar

• Read availability, create/update/delete events
• RSVP and manage recurrence

Required scopes at sign-in:

Permissions are delegated — Grok accesses only the signed-in user's mailbox and calendar.

2. Grok for Outlook add-in (paid subscribers)

Shipped July 21, 2026 as a Microsoft commercial marketplace add-in. Sits in Outlook's task pane for thread summaries, backlog sweeps, and draft composition without leaving the inbox. Requires paid X Premium or SuperGrok — unlike xAI's free Word, Excel, and PowerPoint add-ins.

The Gmail vs. Outlook permission asymmetry

If you tested Grok on a Google account and concluded it couldn't act on mail, you tested the conservative half.

For agent harness designers, that asymmetry changes your threat model: connecting a Microsoft work account to Grok is closer to handing an agent your outbox keys than connecting Gmail on defaults.

August 2026 Microsoft stack updates

xAI's broader connector catalog also includes Google Drive, Salesforce, SharePoint/OneDrive (Business/Enterprise), and bring-your-own MCP — part of the same MCP-era connector wave explainx.ai tracks across Grok 4.6 launch coverage and Perplexity's hybrid local-PII desktop client.

IT checklist before you connect a work account

1. Check Azure AD app consent policies — does your tenant require admin approval for xAI Grok?
2. Review delegated scopes — Mail.Send means Grok can send as the user, not just draft
3. Document revocation path — grok.com/connectors and Microsoft account app-permissions page
4. Separate add-in vs. connector — sidebar add-in is paid; web connector path is broader
5. Compare to Copilot — Microsoft Copilot agents run inside the M365 trust boundary; Grok is a third-party OAuth app

How delegated OAuth works in practice

Microsoft Graph scopes like Mail.ReadWrite and Mail.Send are delegated permissions: Grok acts as the signed-in user, not as a service account with org-wide access. xAI's own documentation states that Grok can only reach the mailbox and calendar belonging to the account that completed OAuth — not colleagues' inboxes, shared mailboxes (unless the user has direct access), or tenant-wide search.

That model has two consequences builders should internalize:

First, every send, forward, and folder move is attributable to a real human identity in your audit logs. If Grok sends a message, Microsoft 365 records it as sent by that user. There is no separate "Grok bot" sender unless you build one via a different integration pattern.

Second, the permission boundary is the OAuth consent screen — not a per-action approval UI inside Grok chat. Once a user clicks Accept on Mail.Send, Grok's connector layer can invoke send tools whenever the model decides a conversation requires it. xAI documents real-time access with no retention ("Grok accesses your data when you ask a question, and does not retain it afterward"), but that is a data-handling promise, not a send-approval gate.

For teams comparing this to Claude's Gmail and Drive write actions, Anthropic ships approval-by-default on destructive connector calls. Grok's Outlook path, by contrast, grants send authority at sign-in with no documented per-message confirmation layer on the connector itself.

Enterprise provisioning: console.x.ai vs. grok.com/connectors

On Grok Business and Enterprise plans, connector availability is a two-step process. A team admin must first provision the Outlook connector in console.x.ai under Grok Business → Connectors. Only after provisioning can individual users connect their own Microsoft accounts at grok.com/connectors.

That split matters for IT:

If users hit a "need admin approval" error during sign-in, xAI's docs point them to Azure AD → Enterprise applications → xAI Grok → grant admin consent. Work and school accounts are the documented sign-in path; personal @outlook.com / @hotmail.com mailboxes are the weaker case — the connector documentation explicitly references Microsoft work or school accounts.

Add-in vs. connector: who actually sends mail?

The July 21 add-in announcement and the connector docs describe different send models, and conflating them is a common setup mistake.

xAI's add-in marketing is explicit: "Nothing sends until you hit send." The connector documentation lists "Send messages, reply-all, and forward emails" as first-class capabilities with Mail.Send requested at Accept. A team that installs only the add-in gets an in-inbox drafting assistant. A team that also connects the web connector gives Grok standing send authority outside Outlook's compose UI.

For regulated mailboxes — legal hold, FINRA, HIPAA-adjacent workflows — that distinction is not cosmetic. Draft-only surfaces keep humans on the send button. Connector-level Mail.Send removes that choke point unless you block the OAuth app at the tenant level.

Three-way permission comparison: Grok, Claude, ChatGPT

Email connector design across frontier labs converged on OAuth in 2026, but default authority levels diverge:

Grok's asymmetry is the outlier: conservative on Google, aggressive on Microsoft at first connect. If you tested Grok on a personal Gmail and concluded "email agents are read-only," you never exercised the Microsoft half of the product.

ChatGPT users should note Check Point's September 2026 sandbox findings: connector read paths and prompt-injection risk are separate from send permissions, but both belong in the same security review.

Grok Automations and standing mailbox authority

Connectors become more consequential when paired with Grok Automations — xAI's workflow layer that turns a prompt into recurring authority. An automation can trigger on incoming mail (sender, subject, recipient filters), pull message context into a Grok run, and invoke connector tools without the user typing a fresh prompt each time.

That pattern is exactly what headless SaaS agent pricing discussions warn about: standing OAuth grants plus event triggers mean the model can act on mail while the user is offline. For Outlook, the documented permission floor already includes send. For Gmail, send only enters the picture after an admin enables the gmail.send tool group — but once enabled, the same automation surface applies.

Practical rollout advice that matches how security teams actually deploy:

1. Start with read-only Gmail or Outlook connected to a sacrificial test mailbox, not a production exec inbox.
2. Verify live behavior with a harmless send test before enabling automations on real threads.
3. Document disconnect paths — grok.com/connectors Disconnect plus myapps.microsoft.com revocation.
4. Treat Grok 4.6 on Foundry as a separate surface — Azure-hosted model endpoints do not automatically inherit grok.com connector OAuth; app architecture determines whether mail tools are in scope.

Grok 4.6 on Microsoft Foundry: model vs. mailbox

The August 26 Foundry launch is easy to confuse with the Outlook connector story because both say "Microsoft" in the headline. They are different products:

Microsoft Foundry sells managed Grok 4.6 model endpoints inside Azure — 200,000-token context window on Microsoft's model card (xAI's own announcement cites 500k on grok.com; treat the Foundry card as the deployment contract), tool calling, Chat Completions and Responses APIs, Global Standard deployment. Pricing on the Foundry blog lists $2.00 per million input tokens, $6.00 output, $0.50 cached for Global Standard preview.

Outlook connectors are OAuth integrations on grok.com that reach live mailboxes. You can deploy Grok 4.6 on Foundry for an internal copilot that never touches Outlook, or connect Outlook on grok.com without using Foundry at all — or combine them in a custom app that calls Foundry APIs and separately holds Graph tokens. The August news cycle bundled them because xAI is deepening its Microsoft partnership, not because one implies the other.

For builders already running Grok 4.6 eval coverage, Foundry is the enterprise inference path; connectors are the productivity integration path.

Security: prompt injection meets Mail.Send

Connector send authority intersects badly with prompt injection — a theme Boris Cherny's September 2026 benchmark surfaced across the industry. Grok 4.6 ranked among the more exploitable frontier models in that chart for unsupervised tool use. Connecting Mail.Send to a model with non-trivial injection attack rates means a malicious email body or a poisoned attachment summary could theoretically steer Grok toward exfiltration or outbound send actions.

Mitigations that actually match the threat model:

• Block or restrict the xAI Grok enterprise app at Azure AD for high-risk tenants until xAI publishes connector-specific injection test results.
• Never connect executive or shared mailboxes without a human-in-the-loop send policy enforced outside Grok (DLP rules, transport rules, conditional access).
• Audit MCP and custom connectors separately — Grok's MCP catalog path can expose internal APIs alongside mail; compound tool access widens blast radius.
• Review MCP security guidance before letting Grok chain mail send with filesystem or code tools in one conversation.

xAI states it does not train on Outlook data and does not store mailbox contents after access. Those policies reduce long-term data leakage risk; they do not prevent real-time mistaken or adversarial sends during an active session.

What builders should take away

If you are designing an agent harness or shipping a product that touches customer mail:

1. Treat OAuth scope as product behavior, not legal boilerplate. Grok's Outlook defaults are a case study in "Microsoft path ≠ Google path."
2. Separate inference hosting from connector grants. Foundry endpoints and grok.com OAuth are independent trust boundaries.
3. Assume send capability is live once Mail.Send is granted — build approval layers in your app if you need them; do not assume the model vendor will.
4. Compare competitor defaults explicitly when writing security questionnaires; "our Gmail integration is read-only" is true for Grok today and false for Outlook on the same account holder's Microsoft work mailbox.

Limitations and open questions

• Personal Microsoft accounts are not the documented happy path; enterprise work/school accounts are.
• No published per-send confirmation on the Outlook Mail connector as of September 2026 — behavior may change; verify against live consent screens before compliance sign-off.
• Add-in vs. connector pricing — Outlook add-in requires paid X/SuperGrok; connector base access is documented for all Grok users, but org features require Business/Enterprise provisioning.
• Context window mismatch — xAI markets 500k on Grok 4.6; Microsoft Foundry's model card lists 200k. Long-thread summarization limits depend on which surface you call.
• Admin audit tooling — Microsoft 365 unified audit logs capture user-attributed sends; Grok-side automation logs are a separate visibility layer teams must wire up themselves.

Related on explainx.ai

• Microsoft Adds Grok to Copilot in Word, Excel, and PowerPoint — a separate, later Microsoft-xAI integration inside Copilot itself, not the standalone Outlook connector covered here

• Grok 4.6 launch and Cursor evals

• What is MCP?

• What is an agent harness?

• Perplexity Mac hybrid compute for local PII

• Microsoft Copilot agents LLM call share

• Starshield Grok government GenAI

• Claude Gmail and Drive write actions

• Check Point ChatGPT sandbox Gmail leak

• Grok Voice Agent Builder and MCP

• MCP security guide

• Prompt injection benchmark (Cherny)

Official sources: xAI Outlook connector documentation, Gmail tiered permissions, Grok for Outlook add-in announcement, Grok 4.6 on Microsoft Foundry.

Connector scopes, add-in pricing, and Foundry availability are accurate as of September 11, 2026.