Traffic went to Google Sheets via a legitimate API. The workload using it was a backdoor.

On 25 February 2026, Google Threat Intelligence Group and Mandiant described their disruption of a long-running espionage operation attributed to UNC2814, which Google assesses to be a suspected PRC-nexus group.

The Google report said UNC2814 had confirmed intrusions in 42 countries and had affected 53 victims as of 18 February, primarily in telecommunications and government. The campaign used GRIDTIDE, a C-based backdoor that treated a Google spreadsheet as a command channel.

Google was explicit about the boundary: this was not a vulnerability in Google products. The attackers used the Google Sheets API as designed, so their command-and-control traffic resembled ordinary cloud activity.

This was conventional cyber espionage, rather than a uniquely AI incident. It deserves attention because agents, automations and ordinary applications increasingly rely on the same sanctioned APIs. A permitted destination establishes where a request goes. It does not establish that the workload making the request belongs there.

The Spreadsheet Was the Control Channel

GRIDTIDE used an attacker-controlled Google service account and private key to authenticate to a Google spreadsheet. The backdoor cleared part of the sheet at the beginning of a session, fingerprinted the compromised host and wrote system information into one cell.

It then polled cell A1 for commands. The commands could run shell instructions, upload a file to the infected machine or download a file from it. Other cells carried command output and transferred data in fragments.

From a network rule's perspective, the destination was familiar: sheets.googleapis.com. From the infected host's perspective, a privileged process read instructions, executed them, and returned results.

Google said it did not directly observe UNC2814 exfiltrating sensitive data during this campaign. That limit should stay attached to the story. The backdoor supported file transfer, and Google observed it on an endpoint containing personal information, but capability and likely intent are not direct observations of a completed theft.

The same discipline applies to attribution. UNC2814 is Google's tracking label, and the PRC connection is its assessment. The report is strong provider and incident-response evidence, rather than a court finding.

Google Could See what Customers Could not

The disruption shows why incident evidence has to cross the provider boundary.

Google terminated attacker-controlled Cloud projects, disabled accounts and access to the Sheets API, worked with partners to disable and sinkhole infrastructure, notified affected organisations and published indicators.

Those actions depended on visibility and authority available to the provider. An affected organisation might see encrypted traffic to a permitted Google domain, a suspicious process or an unexpected pattern of API methods. Google could connect that activity to attacker-controlled projects and accounts across its own services.

Neither view is complete. Internal evidence can tie a connection to a host, process, service identity, business task and resulting change. Provider evidence can reveal ownership and relationships beyond the customer's boundary.

The incident plan for a consequential connector should therefore name the records retained on both sides, the route for requesting provider evidence and the owner who can revoke one compromised workload without disabling the service for everyone.

Google's own hunting guidance offers a concrete starting point for this case: look for non-browser processes calling particular Google Sheets methods, alongside suspicious executables, configuration files and service creation on the host. The sanctioned domain remains useful. It simply cannot carry the whole trust decision.

Third-party Concentration Raised the Cost of Coarse Controls

GRIDTIDE was one campaign. A separate IBM report showed why precise containment matters across the broader software and service supply chain.

On 25 February, IBM released its 2026 X-Force Threat Intelligence Index. Within incidents observed by X-Force, large supply-chain and third-party compromises had nearly quadrupled since 2020. IBM said the rise was driven mainly by attacks on software build and deployment environments and SaaS integrations.

Its significance is operational. A shared integration or build service connects many workloads. If they reuse one credential and one undifferentiated allowlist rule, a suspicious call leaves defenders with a poor choice: disable an essential provider for everyone or leave the questionable path open.

Distinct workload identities and narrow credentials allow a smaller response. They let an organisation suspend one integration, preserve its evidence and keep unrelated uses of the same provider operating.

This differs from GRIDTIDE. IBM described a change in its observed incident population; Google described the mechanics and disruption of one espionage operation. Together they make a practical case for containment below the provider name.

Final Perspective

GRIDTIDE would make me wary of treating an allowed destination as the control. A customer could connect Sheets traffic to the infected host and process, then isolate that workload. Only Google could disable the attacker's projects, accounts and access to its API. The response crossed two authority domains because the evidence did too.

That division matters when the provider also supports legitimate work. Blocking Google Sheets for everyone may stop the suspicious route and the business processes beside it. Distinct workload identities give the customer a narrower action on its side; a working provider channel supplies the action on the other. Neither can substitute for the other.