← All news
Shadow AIIncident ResponseAI Security

Nobody Exploited Anything at McKesson. Two Phone Calls and a Consent Screen Moved 284 Million Records

Obiguard Research Team·August 29, 2026·9 min read

There is no CVE in this story. There is no patch to schedule, no vendor advisory to read, and nothing for a scanner to flag. That is the entire point of it.

On August 28, 2026, McKesson — the largest pharmaceutical distributor in the United States — disclosed a cybersecurity incident in a Form 8-K filed with the SEC. The company's own words are worth reading precisely: it is "in the early stages of investigating a cybersecurity incident involving third-party applications and unauthorized access and exfiltration of data," and has not determined the incident to be material.

McKesson discovered the intrusion on August 25. Data left between August 21 and 25.

The extortion group ShinyHunters claims responsibility, and claims roughly 1TB of data covering 284 million records — pulled, it says, from McKesson's Salesforce and Snowflake environments. It is demanding $55,236,150 and says McKesson has not replied.

Everything after the 8-K is an attacker's claim and should be read as one. But the claimed intrusion path is the part worth your attention, because it is boring, it is repeatable, and it is almost certainly present in your environment right now.

The claimed method: two employees, one help desk impersonation, one consent

ShinyHunters says it phoned two McKesson employees, impersonated internal support, and walked them into handing over their Okta single sign-on credentials — from which it reached the connected Salesforce and Snowflake instances.

Note what is absent. No zero-day. No malware on an endpoint. No lateral movement through a flat network. No privilege escalation chain. The access was granted, by people, through the front door, in a conversation.

This is not improvisation. Microsoft published a detailed writeup of exactly this playbook on July 13, 2026, in Defending SaaS-based applications against ShinyHunters OAuth abuse. The pattern has two halves:

  1. Voice phishing into OAuth consent. The caller impersonates IT support and talks the user through authorising an attacker-controlled application inside Salesforce — often dressed as something plausible like Data Loader. The app then makes API calls as the user.
  2. Supply chain via an already-trusted integration. Salesloft Drift in August 2025. Gainsight-published apps in November 2025. Klue in June 2026. In each case the attacker did not break into the customer — it inherited a token the customer had already issued to a vendor.

Microsoft's characterisation of the resulting activity is the sentence to keep: it "appeared indistinguishable from legitimate Salesforce usage." Trusted identity, approved app, authorised integration. There is nothing anomalous to detect, because nothing anomalous happened.

The reason this belongs on an AI security site

Because the fastest-growing category of "third-party application holding a standing grant into your SaaS" is AI, and nobody is counting them.

Grip Security's analysis of 23,000 SaaS environments, covered by SecurityWeek in March, found that 100% of the organisations studied were running AI-enabled SaaS, averaging 140 AI-enabled SaaS environments each, against a 490% year-over-year rise in public SaaS attacks. Those AI features arrived as product updates to tools already in the estate. Almost none of them went through a fresh security review, because from a procurement standpoint nothing was purchased.

Now add the identity layer. Akamai's State of the Internet: Enterprise AI Usage Risk Report 2026, published August 5, put telemetry behind the thing everyone suspected: 47.11% of enterprise AI conversations run through personal rather than corporate-managed identities, and 16.31% of AI browser and IDE extensions carry known CVEs. Roughly half of the AI activity on corporate devices is happening in accounts your IdP cannot see, cannot log, and — critically for this story — cannot revoke.

Put the two together and the shape of the exposure is clear. An employee signs into a consumer AI assistant with a personal account, connects it to their work Google Drive, work calendar, or work Salesforce through an OAuth consent screen, and creates a standing, long-lived, MFA-bypassing grant into corporate data that exists in no inventory you maintain. It is exactly the object ShinyHunters has spent eighteen months harvesting — except this one was created voluntarily, by a helpful person, for a good reason.

We argued three weeks ago that the ban-it strategy had failed on IBM's numbers. This is the mechanism underneath that failure. A ban does not remove a consent grant. It just removes your ability to ask about it.

What to actually do this week

  • Enumerate connected apps, not just users. In Salesforce, Google Workspace, Microsoft 365, Slack and Snowflake, pull the list of authorised third-party applications and the scopes they hold. Most teams have never looked at this list. Almost every team is surprised by it.
  • Sort that list by "when did we last verify this vendor exists." Salesloft, Gainsight and Klue were all legitimate vendors with legitimate integrations right up until they were the intrusion path.
  • Treat AI features in existing SaaS as new apps. An AI assistant bolted onto a tool you approved in 2023 is a new data flow that no one reviewed. Reviewing it is a half-day of work.
  • Rehearse the help desk call. The control that would have stopped McKesson, if the claim is accurate, is a verification procedure for credential and MFA-reset requests that does not depend on the caller sounding legitimate. Test it by having someone try.
  • Assume SSO is a revocation tool, not a phishing defence. Okta did not fail here; a person did. What SSO buys you is that disabling one identity actually cuts off everything downstream — which is worth exactly nothing for the AI accounts that never went through it.
  • Know what a token can reach before it is stolen. Scope review is cheap in advance and impossible during an incident.

Where Obiguard fits: Obichat is the AI account your IdP can actually turn off

Obiguard did not stop the McKesson call and does not claim to. What it addresses is the half of this problem that is growing fastest and is currently unmanaged: the AI surface that keeps generating new connected identities outside your control.

Obichat is a governed multi-model chat workspace built on LibreChat, and the argument for it here is narrower than the usual one. It is not that employees will stop wanting an assistant — they will not. It is that one AI front door your administrators own is a smaller and more revocable surface than several hundred personal accounts holding OAuth grants nobody enumerated.

Concretely, the properties that matter against this specific failure mode:

  • It sits behind your existing identity provider. SAML 2.0 and OIDC sign-in, so Okta, Entra ID or whatever you already run is the source of truth. When an account is disabled, AI access goes with it — which is precisely what does not happen when the AI account was created with a personal email and a credit card.
  • Model and provider connections are set per workspace, by an admin. Each team's workspace has its own provider connections and its own model allow-list, with workspace settings admin-gated. There is no path by which an individual quietly attaches a new endpoint to corporate data.
  • It runs where you choose. SaaS on Obiguard-managed infrastructure, or a private deployment in your own AWS, Azure or GCP tenant, working with any OpenAI-compatible endpoint including self-hosted models. The connected-app question becomes an internal configuration question.
  • There is a record. A per-workspace activity log of conversations and events, exportable to CSV, with controls mapped to NIST AI RMF and ISO/IEC 42001. When counsel asks what staff sent to an AI between August 21 and 25, that is a query. Against a personal Plus account, it is a guess.
  • Policy runs before the prompt leaves. Every message passes the inspection layer under the workspace's policy set — PII and PCI redaction, block-lists, jailbreak and prompt-injection detection.

For the other half of the estate — where AI reaches your applications rather than your people — Governance AI carries the same logic into the machine layer. Allow-lists bind each credential to specific model IDs, tools, external domains and invoking identities, which is a positive-permission answer to the standing-grant problem rather than a monitoring answer. The audit ledger keeps an immutable per-call record of prompt, response, tool calls, model and initiating identity. That is the same argument we made about agents acting outside their authorisation and about moving the inference boundary somewhere you administer: the useful control is not the one that predicts the compromise, it is the one that bounds and records what the compromised thing could reach.

The uncomfortable part

Read the McKesson 8-K again. "Third-party applications." Not our systems. Not our network. The company is describing an incident that happened in the space between its vendors, its identities and its data — the space that appears on no architecture diagram and belongs to no team.

The 284 million figure will move. ShinyHunters itself concedes it is a raw record count and that the number of distinct people is unknown; deduplication will bring it down, and history says it will still be very large. But the number is not the lesson.

The lesson is that the most consequential healthcare data event of the month required no vulnerability at all. It required a phone call to a person who wanted to be helpful, and a set of standing permissions that had been granted long ago and never reviewed. Your AI estate is currently manufacturing more of the second thing every week, and most of it is being created with credentials you do not manage.

Explore Obichat or talk to us about which AI applications currently hold a live grant into your SaaS — and who would have to be called to revoke them.

How Obiguard helps

Turn this into enforced policy, not just awareness.

Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.

See how it works →