Risks of Giving AI Access to your 365
Security · Governance · Microsoft 365 Risks of giving AI access to your 365 Businesses are being asked to hand AI tools the keys to their email, files and calendars…
Security · Governance · Microsoft 365
Your people are connecting AI tools to your email, your files and your customers' data. Most of those tools don't build AI — they are middlemen holding a key to your business. Here is what has already gone wrong, and what it should cost you to say yes.
If you read nothing else
- 01Most "AI tools" are wrappers. They don't run models. They hold a credential to your data, forward it to somebody else's model, and pipe the answer back.
- 02The incidents that actually leaked data hit the middlemen — a misconfigured database, an over-permissioned OAuth grant, an app that was public by default. The big providers' own failures were mostly flaws found by researchers and patched, plus one breach at an analytics vendor they used.
- 03Three characters — .All — separate a personal assistant from standing access to every mailbox in your business.
- 04Resetting passwords does not revoke it. Neither does MFA. Neither does the person who approved it leaving.
- 05The other half of the problem needs no attacker at all: a share link, a default setting, or a tool sending more than its own privacy control implied.
- 06You stay the data controller either way. The fine, the notification and the phone call to your biggest client are yours, not the vendor's.
Someone finds an AI tool. It reads their inbox, summarises meetings, drafts replies, answers questions about contracts. The demo is superb. To work on real data it needs connecting to Microsoft 365 — and the connection screen asks for rather more than anyone expected.
IT explains that the permissions cover every mailbox in the business, not just the requester's. That the setup guide wants a Global Administrator. And the answer, increasingly, is a shrug: I don't care. Just turn it on.
That is a decision an owner is entitled to make. It is worth making it with the facts.
What you are actually approving
Here is a realistic composite of what a mid-market AI assistant asks for when it wants to be genuinely useful.
Seven lines, four seconds to accept. In plain English: every email, every file, every private chat, every meeting and every staff record in the business — readable and writable by an external company, indefinitely, whether or not anyone is logged in.
The whole story is in the suffix. Mail.Read reads your mailbox. Mail.Read.All reads everyone's. Three characters separate a personal productivity tool from tenant-wide surveillance, and the consent screen renders them in identical grey text.
Note the last line as well. offline_access is the one that turns a session into a standing arrangement — the app keeps working at three on a Sunday morning with nobody at a keyboard.
| What it asks for | What it actually gets | Blast radius |
|---|---|---|
| Mail.Read | The signed-in person's mailbox only | One mailbox |
| Mail.Read.All | Every mailbox in the tenant, including the directors' and HR's | Whole organisation |
| Mail.Send.All | Send mail as anyone — including your MD, to your bank | Invoice fraud on a plate |
| Files.ReadWrite.All | Every file in every SharePoint site and OneDrive | Whole organisation, destructive |
| Sites.FullControl.All | Full administrative control of all SharePoint sites | Effectively SharePoint admin |
| Directory.ReadWrite.All | Modify users, groups and app permissions | Can escalate its own privileges |
| Sites.Selected | Only the specific sites you explicitly name | Exactly what you chose |
| offline_access | A refresh token — access that continues with nobody present | Persistence |
Delegated
The app acts as a signed-in person and can never see more than they can.
Application
It acts as itself. No user, no login, no session to expire — the same reach at 3am on a Sunday as at 3pm on a Tuesday.
That is why they need an administrator: an ordinary user cannot give away data that isn't theirs. So when an AI tool insists on Global Administrator, it is usually not because setup is complicated. It is because nobody else can grant what it is asking for. Sometimes that is honest. More often the vendor simply never did the work to scope it — asking for Files.ReadWrite.All takes no engineering effort, and naming the three sites it actually needs does.
Microsoft's own guidance: only administrators of your entire organisation should hold Global Administrator. An AI connector is not one of them.
You are not buying an AI. You are buying a pipe.
Most tools sold as "AI for your business" neither train models nor run them. They are brokers: middleware that holds a credential to your 365, pulls data out, forwards it to somebody else's model, and pipes the answer back. Zapier is the famous example; the pattern now covers hundreds of automation platforms, notetakers, transcribers and inbox assistants.
So you have consented to a chain, having read the name of only the first link.
- 01Your tenantMail, files, chats, calendars, directory.
- 02The wrapperSees everything in the clear. Stores it.
- 03Their cloudQueued, logged, retained.
- 04A model providerOne you didn't choose, and may change.
- 05Everything behind itTheir hosting, analytics and support tooling.
Take Zapier's own published position — useful precisely because it is transparent, not because it is bad. Zapier is a processor, hosting in AWS in the United States, and by default it retains task history — the content that actually passed through — for 29 to 69 days. Enterprise can shorten that to 7–30. It will not sign a BAA for health data.
That is a competently run vendor doing normal things. The point is that even the good version means a copy of the email your solicitor sent you sits on a third party's infrastructure in another country for up to two months. Multiply by every AI tool in your business, and note that the median vendor is nowhere near as forthcoming.
On the scraping question, honestly: reputable providers do carve training out, and they mean it. But "not used for training" is far narrower than "not retained" — everyone in that chain logs, for abuse detection, debugging, billing and support, and those logs hold your content on infrastructure you don't control. The carve-out is also a property of the tier, not the brand. Staff don't read tier terms. They sign up with a work email and paste in a contract.
The five ways a middleman fails you
- Retention beyond expectation — full requests and responses logged for debugging or abuse monitoring, for longer than anyone realises and often unencrypted at rest.
- Training reuse — consumer and free tiers frequently reserve rights to use submitted data. A wrapper built cheaply on a free tier inherits that, whatever its own marketing says.
- Fourth-party exposure — the wrapper's own subprocessors get a copy too, and you have almost certainly never seen that list.
- Cross-tenant leakage — prompt caching and session-handling bugs have mixed one customer's data into another's response. Rare, but it has happened.
- Credential exposure — some products embed API keys client-side or store them badly, giving an attacker a route to impersonate the account and pull historical logs.
- Silent model swapping — the wrapper reroutes to a different model for cost or failover reasons without telling you. Different provider, different data terms, identical interface.
- Prompt injection — if the tool ingests free text, a transcript or an uploaded document, that text can sometimes manipulate the model into disclosing other context it holds.
- Error propagation — a mistranslated symptom or instruction in a clinical or client-facing setting is not a privacy problem. It is a correctness problem with consequences.
- Cascading outages — your feature now depends on the wrapper's uptime, the model provider's uptime and the wrapper's rate limits. Three points of failure where you had one.
- Noisy neighbours — shared API keys across many of the wrapper's customers mean somebody else's traffic can throttle yours.
- No real DPA — many small vendors have a privacy policy and nothing that meets Article 28. That is a live problem the moment client or health data is involved.
- Residency — data transits or lands outside the UK and EU, which matters for UK GDPR and for any client contract specifying where data sits.
- Breach of your own contracts — routing a client's data through an unvetted tool can itself be the breach, whether or not anything ever leaks.
- Privilege and discovery — handing data to a third party can affect legal privilege and make it independently discoverable in litigation.
- Shadow AI — staff signing up without procurement or security review, so the business doesn't know the data path exists. This is the most common real-world version of all of this.
- No deletion guarantee — when you offboard the tool you usually cannot verify historical data was purged from it or its subprocessors.
- Discovery risk — a client or regulator finding an unvetted AI intermediary in the data path is an audit finding and a trust problem on its own, Cyber Essentials renewal included.
And you cannot audit what you cannot see. In July, twice, someone checked.
It was told not to open any files. It uploaded the entire repository.
On 12 July 2026 a researcher publishing as cereblab put xAI's Grok Build coding assistant through an interception proxy. The prompt was blunt: reply with exactly "OK", and do not read or open any files. The tool complied — and uploaded the whole repository anyway, as a Git bundle, to a Google Cloud Storage bucket named grok-code-session-traces. On a 12 GB test repository the channel doing the actual work carried about 192 KB; the storage channel carried 5.1 GiB in 73 chunks, roughly 27,800 times more data than the task required. Canary credentials in a .env file came through unredacted, and secrets deleted months earlier travelled with the Git history.
The "Improve the model" toggle — what any reasonable person would read as the data-collection control — had no effect; the server kept returning trace_upload_enabled: true. xAI switched the uploads off with a server-side flag within a day of publication, and Elon Musk promised on X that the collected data would be deleted. There has been no advisory, no changelog entry and no statement on retention or scope, and the upload code reportedly remains in the binary behind a flag. Equivalent tests of Claude Code, Codex and Gemini CLI did not show the same behaviour.
Why this matters to you: nobody was breached. No attacker, no malware, no stolen token — a legitimate provider's tool, working as built, sending far more than its own privacy control implied. Different product category, identical mechanism to the one you are about to authorise. The only reason anybody knows is that one person watched the wire.
Staff pressed "share". Google published it.
On 25 July 2026 a Reddit user demonstrated that the search query site:claude.ai/share returned a long list of publicly shared Claude conversations. Claude's share feature creates a public web page by design — but the pages were missing a working noindex instruction, so Google and Bing crawled and indexed them like any other page on the open web. Shared Artifacts were affected as well: the prototypes, dashboards, internal tools and planning documents people had published out of Claude, each sitting on its own public URL.
Reported finds across the indexed pages included résumés, legal questions, engineering work, internal business discussions and, in several accounts, credentials and API keys that had been pasted into prompts. Anthropic added the missing tags and the results cleared from Google within a couple of days, with some reportedly lingering in Bing. Private conversations were never part of it. This has happened before and not only here: Forbes reported roughly 600 Claude chats indexed in September 2025, and 404 Media reported that a researcher scraped around 100,000 publicly shared ChatGPT conversations in August 2025.
Why this matters to you: nothing was hacked, and no permission was granted to anybody. A convenience feature did something more public than its users understood, and a missing crawler instruction turned "send this to a colleague" into "publish this page". Ask every member of staff to open Settings → Privacy → Shared Chats in Claude today, and the equivalent in ChatGPT, and unshare anything that should not be on the open internet. Then write "no client data in shared links" into your AI policy, because the next tool will have the same button.
What has actually happened
Not hypotheticals. The public record of the last twelve months.
The models were never touched. The company holding the transcripts was.
Chat & Ask AI is a wrapper: it connects users to models from OpenAI, Anthropic and Google, and lets them choose which one to use. It doesn't run any of them. What it does is store — and that is exactly where it failed. A misconfigured Firebase backend exposed roughly 300 million messages belonging to some 25 million users, including full chat histories, which model each user had selected, account settings, timestamps and the names users had given their chatbots. The exposure reached other apps from the same developer, Codeway, not just this one.
The contents are the part worth sitting with. People type things into a chat window that they would never put in an email, on the assumption that it is private. Among what was left readable were messages from people in acute personal crisis.
Why this matters to you: the three model providers in this story were not breached and did nothing wrong. The company in the middle — the one nobody in procurement had heard of — was holding everything, and lost it to a configuration mistake. When you approve a wrapper, its security posture becomes yours.
One employee ticked "Allow All". Then they stopped using the app.
A Vercel employee connected a consumer AI productivity app to their corporate Google account and granted it broad "Allow All" permissions. Then they lost interest. Nobody revoked it.
The vendor, Context AI, was breached — reportedly after infostealer malware on one of its own employees' machines — and OAuth tokens for its consumer users were compromised. One of those tokens was still live. Attackers used it to take over the employee's account and cascade into their mailbox, drive and identity, reaching internal systems and credentials that weren't encrypted. Vercel brought in Mandiant, confirmed customer data had been stolen before the main intrusion was detected, warned it could affect hundreds of users across many organisations, and told customers to rotate their keys.
Why this matters to you: OAuth grants don't expire when interest does. Every AI tool anyone has ever trialled in your tenant is still connected unless somebody actively disconnected it. Go and look — it takes ten minutes and you won't enjoy it.
An AI chatbot's tokens became a skeleton key for hundreds of companies
Drift was an AI chat platform integrated with Salesforce. Attackers compromised Drift's own infrastructure and stole the OAuth tokens it held on behalf of its customers, then spent ten days bulk-exporting data from more than 700 tenants — Cloudflare, Google, Palo Alto Networks, Proofpoint and Zscaler among them.
They weren't after CRM records. They combed exported support cases for secrets — AWS keys, Snowflake tokens, VPN credentials, passwords customers had pasted into tickets — and used them to move into entirely separate environments. Then they deleted the query logs behind them.
Why this matters to you: not one of those organisations was breached at its own perimeter. Every one had made a deliberate, individually reasonable decision to connect a legitimate tool. The tool was the perimeter, and it belonged to someone else.
They didn't hack anything. They asked the AI nicely.
In March 2026 Meta gave an AI support assistant the power to reset passwords and perform account maintenance. Attackers worked out they could open a chat, give the bot a target's username and an email address they controlled, and ask it to link the two. The bot did. It sent a verification code to the attacker's inbox, accepted it back, and offered a Reset Password button — bypassing two-factor authentication without ever checking whether the person asking owned the account.
404 Media broke the story on 1 June 2026 after high-profile accounts fell, including the Obama White House account, a US Space Force account and Sephora. Meta's breach filing put the total at 20,225 users who lost contact details, dates of birth, profile information, posts, account activity and direct messages. Meta says it doesn't know what the attackers read. They had roughly seven weeks.
Why this matters to you: not a hack. No malware, no exploit, no phishing. An AI was given a powerful permission and an attacker asked it to use that permission. It obliged, because that is what it was for. Meta's own explanation is the instructive part — the tool functioned as intended, and a separate code path simply failed to verify the email matched the account.
Nobody chose to publish any of it. A default did.
Researchers at RedAccess, investigating unauthorised staff use of AI tools, found that apps built on AI "vibe-coding" platforms were left publicly accessible unless a user manually set them to private. Real exposures included unredacted customer service conversations for a UK cabinet supplier, internal financial data from a Brazilian bank, patient conversations from a long-term children's care facility, and incident data a security company was using to triage its own clients' issues.
Why this matters to you: in every one of those cases an employee solved a real problem quickly with a tool that worked. None of them intended to publish anything. Shadow AI is not staff being reckless — it is staff being productive on infrastructure nobody reviewed, with defaults nobody read.
Also on the record
- June 2026 · KlueA credential from 2022 took down ~200 companiesBreached via a credential issued for a limited pilot four years earlier and never decommissioned. Attackers took the keys Klue held to customers' cloud services, stole data and extorted. LastPass, HackerOne and Jamf among those affected. Their credential hygiene is your credential hygiene.
- Sept 2025 · postmark-mcpEvery outbound email quietly copiedA malicious npm package mirroring a legitimate email connector for AI assistants. Fifteen versions were faithful copies and earned trust; 1.0.16 added a hidden BCC to an attacker address. Mail flowed through the organisation's own infrastructure, so SPF and DKIM passed.
- 2026 · Cisco300+ repositories cloned, AI product code includedAttackers used credentials from a separate supply-chain compromise to reach Cisco's development systems and clone over 300 GitHub repositories, including code tied to AI products, unreleased work and customer-linked repos.
- Dec 2025–2026 · MexicoThe inverse case: AI as the attacker's toolAttackers allegedly framed requests as legitimate bug-bounty work to get an AI assistant to generate scripts later used against about ten Mexican government entities and a financial institution — roughly 150 GB taken, 20+ vulnerabilities exploited, over about a month. Not your data being scraped; your adversary moving faster.
Read them together: not one of those breaches began at a model provider. Every single one began at the company sitting in the middle, or at a feature nobody had read the defaults of.
That should reframe the question. The dominant risk is not a model provider quietly stealing your data — the reputable ones have more to lose than you do. The risk is uncontrolled data flow through unvetted intermediaries, with weak contracts, unclear retention and no visibility, made routine by staff adopting tools nobody reviewed. That is a supply-chain and vendor-management problem wearing an AI badge, and it shows up as a gap in a Cyber Essentials-style audit long before anything actually leaks.
It isn't only the middlemen
The section above could be read as "use the big names and you're fine". That would be the wrong conclusion. The large providers have had a bruising year too — and the pattern of their failures is different in a way that is worth understanding, because it changes what you do about it.
Broadly: the wrapper failures leaked real data, through configuration mistakes and stolen tokens. The first-party failures were mostly serious flaws found by researchers, disclosed responsibly and patched quickly, with no confirmed exploitation. That is a meaningfully better outcome. It is not the same as safe, and two of the three below never needed a flaw at all.
Not OpenAI's systems. Still OpenAI's users.
On 9 November 2025 attackers gained unauthorised access to Mixpanel, the third-party analytics provider OpenAI used on its API platform. Names, email addresses, approximate location, operating system and browser details belonging to API platform users were taken. OpenAI stated plainly that this was not a breach of its own systems and that no chats, API requests, usage data, passwords, credentials, API keys, payment details or government IDs were exposed. It removed Mixpanel from production, ran an investigation, and warned users to expect convincing phishing built on the stolen details.
Both things are true at once: OpenAI's statement is accurate, and the affected developers still had their details taken because of a company they had never chosen, never heard of, and never agreed to.
Why this matters to you: this is the fourth-party problem in its purest form — an analytics tool inside your vendor's stack. Every diligence question in this article about your vendor's sub-processors applies equally to your vendor's vendors, and the honest answer is that you will never see the full list. Which is the argument for keeping the amount of data you hand over as small as the job allows.
The sandbox that couldn't reach the internet, reached the internet
Check Point Research found a hidden outbound path from ChatGPT's isolated code-execution runtime — the Python environment OpenAI describes as unable to make direct outbound network requests. Using DNS queries as a covert channel, a single malicious prompt could turn an ordinary conversation into an exfiltration route for user messages, uploaded files and other content, and the same channel could carry commands back in, giving an attacker an effective remote shell inside the sandbox, outside the model's safety checks and invisible in the chat window. A backdoored custom GPT could abuse the same weakness against anyone who used it.
A separate flaw in OpenAI Codex exposed GitHub tokens, putting private repositories at risk. Both were reported responsibly; OpenAI had already identified the runtime issue internally and deployed the fix on 20 February 2026, with the Codex issue addressed on 5 February. There is no evidence either was exploited maliciously.
Why this matters to you: the reassuring architectural claim — "that environment is isolated, it cannot call out" — was sincerely made and briefly untrue. Isolation is a property somebody has to keep verifying, not a promise you can file. If your risk assessment leans on a vendor's description of their own sandbox, note that this one needed a third-party researcher to test it.
Anyone who can send you a document can give instructions to your assistant
Noma Labs disclosed GeminiJack, a zero-click indirect prompt injection affecting Gemini Enterprise and Vertex AI Search. The attack needs no access to your systems at all: share a document, send an email or create a calendar invite containing hidden instructions, and when an employee later asks Gemini an ordinary question, the retrieval system feeds that poisoned content to the model as context — and the model executes the embedded instruction as though you had typed it. In the demonstrations the payload told Gemini to gather data and embed it in an image URL pointing at an attacker's server, so the exfiltration happened as a routine image load that data-loss tooling had no reason to flag. Researchers showed years of email correspondence, complete calendar histories and whole document repositories leaving this way.
It is not an isolated bug. Miggo Security found a calendar-invite injection exposing private meeting data; Tenable's "Gemini Trifecta" covered three flaws turning search history, logs and browsing into attack vectors; a Gemini CLI flaw rated CVSS 10.0 allowed remote code execution before the sandbox initialised. Google has patched the specific vectors and built layered defences — injection classifiers, Markdown sanitisation, URL redaction, confirmation prompts for risky actions — but HiddenLayer has since shown control tokens hidden in Gmail messages and Slides speaker notes still overriding Gemini's output.
Why this matters to you: this is the failure mode with no consent screen and no permission to revoke. It exists because language models do not reliably separate instructions from data, and every assistant wired into a mailbox inherits it — Gemini is simply the best-documented example because it is the most deeply integrated. The practical control is not a setting. It is limiting what any assistant can reach, and requiring a human to approve anything that leaves the building.
Two more worth knowing
- Nov 2025 · ChatGPTPrompts turned up in other people's analyticsA flaw in ChatGPT's web browsing mode embedded user query text into search URLs, which were then crawled — so fragments of private prompts appeared in the Google Search Console logs of unrelated websites. OpenAI fixed it but could not say how many prompts had leaked.
- Jan 2026 · CISAShadow AI reaches the top of the security agencyReporting indicated that the interim head of the US Cybersecurity and Infrastructure Security Agency uploaded contracting documents marked For Official Use Only into public ChatGPT, despite departmental restrictions on the tool, triggering an internal review. If it happens there, assume it is happening in your finance team.
Put the two halves together and the practical rule falls out. Choosing a reputable provider genuinely reduces your risk — they patch, they disclose, they have something to lose. It does not remove it, because the failure modes that remain are architectural: sub-processors you cannot see, isolation you cannot verify, and an injection class nobody has fully solved. Which is why the controls at the end of this article are about scope and revocation, not about picking the right logo.
The next layer: connectors, agents and MCP
The consent screen at the top of this article is last year's problem. The current one is the Model Context Protocol — the standard way AI assistants now plug into business systems. It is the same bargain with more moving parts: instead of one app holding one token, you have a fleet of small servers, often built quickly, each holding credentials and each capable of acting on your data.
The research that exists is not reassuring, and it is worth reading as an indication of maturity rather than as precise measurement.
- 492MCP servers found exposed to the open internet with no authentication at allTrend Micro
- 82%of 2,614 MCP implementations analysed used file operations prone to path traversalEndor Labs
- ~30%of public servers scanned carried at least one exploitable flaw; roughly 8.5% used OAuthMultiple scans, 2025–26
- 540%rise in prompt-injection reports over the yearHackerOne
OWASP's own framing makes the shift plain: its 2025 agentic-AI security guidance catalogued plausible threats, while the 2026 edition catalogues CVEs, vendor advisories and actual breach reports across nearly every category. Coding assistants dominate the advisory counts, because they are the tools with the deepest access to the most sensitive material.
The practical governance point is the same one as before, one layer down. An MCP server is a piece of software somebody wrote, running with your credentials, processing untrusted input. Treat it as you would any other third-party component with production access: an approved list, least-privilege scopes, no write access where read will do, isolation, and a human in the loop for anything consequential.
Your incident response plan does not work here
Notice what is missing from every case above. No attacker cracked a password. MFA never failed — in several, it was completed correctly by the real user. Access was granted properly, by someone with the authority to grant it, and then stolen or abused.
Where you stand legally
You are the controller, and that never transfers. Route customer email through an AI tool and you own the consequences. If the vendor loses the data it is your breach, your notification, your fine and your letters to customers. The ICO's ceiling is £17.5m or 4% of global turnover.
No contract, no lawful processing. UK GDPR Article 28 requires a written contract with any processor handling personal data for you. A privacy policy is not one. A free-tier signup with a work email is certainly not one. The processing is unlawful from the first prompt — before any attacker appears.
A DPIA is mandatory here, not optional. Connecting AI to the whole corpus of your email and documents hits several ICO triggers at once: innovative technology, large-scale processing, invisible processing, and special category data about your own staff. The ICO treats it as a gate before you start, not paperwork produced afterwards to justify a decision already taken — and expects you to show which less risky options you considered and rejected.
Your customer contracts probably bar it anyway. Most commercial agreements — and effectively all public sector, financial services and enterprise ones — restrict sub-processing or require notice. Connecting an AI tool to the mailbox handling that client's account can breach the contract regardless of what the ICO thinks.
And the professional duties don't bend. Legal privilege, medical confidentiality, FCA obligations, safeguarding. Data handed to a third party can also complicate privilege and become independently discoverable in litigation — a problem that has nothing to do with data protection law at all.
What to do instead
Prohibition does not work. Staff route around it and you lose the visibility you had. Give people a good option so they don't go and find a bad one.
Ten controls, this week
Enumerate what is already connected
Entra → Enterprise applications. Everyone finds something they didn't know about.
Turn off user consent
Or restrict it to verified publishers and low-risk permissions. This one toggle would have prevented several incidents above.
Enable the admin consent workflow
So requests arrive as tickets, not as discoveries.
Publish an approved AI tools list
Shadow AI is the most common failure mode. Give people two sanctioned options and a fast route to request a third.
Audit Global Admins
More than four? Fix it today. Move to PIM for just-in-time elevation.
Alert on consent grants
In the audit log — especially
IsAdminConsent = True.Disable device code flow
Via Conditional Access, unless you have a documented need.
Turn on app governance
In Defender for Cloud Apps, if you're licensed.
Fix SharePoint oversharing
Before enabling any AI that reads files.
Audit share links and stale grants
Ask staff to clear their shared AI chats, and put an owner and a review date on every remaining grant. Quarterly. Start with anything untouched in 30 days.
Before you approve any AI tool
The eight questions that matter
0 / 8 answeredThe bottom line
Giving an AI tool full access to Microsoft 365 is not a configuration change. It is a decision to let an external company — and everyone behind it — read every confidential thing your business holds: your commercial position, your legal advice, your customers' data, your employees' private circumstances. Indefinitely, through a chain you have never met, with a persistence that survives every incident response step your team knows.
Sometimes it is worth it. Usually a scoped version delivers most of the value at a fraction of the exposure, and the only reason it wasn't chosen is that nobody spent an afternoon on it. Either way, this belongs to someone with the authority to make it and the willingness to put their name on it.
Accepting takes four seconds. Meta's attackers had seven weeks. Klue's credential sat there for four years. Nobody in any of those stories thought they were making a decision at all.
Want to know what's already connected to your tenant?
We work with Microsoft 365 and Entra ID every day — see our cyber security and IT support services.
Sources
- Malwarebytes and others — reporting on the Chat & Ask AI / Codeway Firebase exposure (2026).
- 404 Media — Hackers simply asked Meta AI to give them access to high-profile Instagram accounts (1 June 2026); further reporting by TechCrunch.
- Google Cloud Threat Intelligence Group — Widespread data theft targets Salesforce instances via Salesloft Drift (August 2025).
- TechCrunch — Vercel confirms customer data stolen via breach at Context AI (April 2026); incident analysis by Blue Radius.
- Axios — reporting on RedAccess research into publicly exposed AI-built ("vibe-coded") applications (2026).
- TechCrunch — The worst hacks and breaches of 2026 so far (Klue / Icarus).
- Snyk — Malicious MCP server on npm: postmark-mcp harvests emails; disclosure by Koi Security.
- Bright Defense — reporting on the Cisco development systems and repository access incident (2026).
- Hoplon Infosec and others — reporting on the AI-assisted intrusion affecting Mexican government agencies (2026).
- The Hacker News — Grok Build uploaded entire Git repositories to xAI storage, not just files it read (July 2026); original wire capture by cereblab, published as a gist. Follow-up on xAI's response: The Register.
- TechCrunch — PSA: your Claude shared chats and Artifacts may have ended up on Google (27 July 2026); VentureBeat; 404 Media, Tons of peoples' Claude chats and creations are exposed on Google (July 2026).
- The Independent / OpenAI — the November 2025 Mixpanel incident affecting OpenAI API platform users; OpenAI incident statement.
- Check Point Research — ChatGPT data leakage via a hidden outbound channel in the code execution runtime (2026); The Hacker News on the ChatGPT and Codex fixes.
- Noma Labs — GeminiJack: zero-click indirect prompt injection in Google Gemini Enterprise; Miggo Security on the Gemini calendar-invite flaw; Tenable on the "Gemini Trifecta"; Google Workspace guidance on indirect prompt injections and layered defences.
- OWASP GenAI Security Project — State of Agentic AI Security and Governance (2026 edition); MCP exposure and vulnerability figures via Trend Micro, Endor Labs, Equixly and HackerOne, as collated in industry reporting.
- Microsoft Learn — Microsoft Graph permissions overview; Detect and remediate illicit consent grants; Best practices for Microsoft Entra roles.
- ICO — Guidance on AI and data protection; When do we need to do a DPIA?
- Zapier — Data privacy overview.
General information for IT and business decision-makers, not legal advice. Data protection outcomes turn on the specific facts of your processing — consult a qualified practitioner before relying on any of it. Vendor terms and product behaviour change frequently; verify against primary sources before deciding.