Five links, four of them outside the perimeter
The disclosure was unusually clear about the route. An attacker compromised a small, single-purpose AI tool. Through that tool’s authorisation grant, they took over one employee’s personal workspace account. From the personal account they reached the employee’s corporate account on the platform. From there they moved into a platform environment, enumerated stored configuration values and decrypted the ones that were stored decryptable. A limited set of customers had values exposed; a wider review found a handful more compromised accounts, and a separate cluster that did not appear to originate from the same incident at all.
Read the chain again and count the links the company controlled. The AI tool was a third party. The personal account was the employee’s. The authorisation between them was granted by the employee, not the company. Only at the corporate account did the organisation’s own controls come into play, and by then the attacker was holding a legitimate credential.
The company did the right things afterwards — external forensics, coordination with the ecosystem, a published indicator that let other organisations check whether the same rogue application had been authorised in their own environments. The indicator was the sobering part: hundreds of users across many organisations, most of whom had no idea the tool was connected to anything of theirs.
AI tools are access paths
Strip the incident to its pattern and it is the one we have been describing all year from different angles. An AI tool that reads from a mailbox, a document store, a calendar or a code repository does so through an authorisation grant. The grant is a standing credential, held by a third party, into enterprise data — and it is typically created by an individual, in seconds, with a consent screen nobody reads, on whichever account happened to be signed in.
The “shadow AI” problem is usually described as a policy failure. It is more useful to describe it as an inventory failure. Every organisation has an identity provider that knows exactly which applications have been authorised against its accounts, by whom, with what scopes. Almost nobody reads that list. Fewer still enforce it — restricting which applications may be authorised at all, and refusing the rest at the point of consent rather than discovering them in an incident report.
That enforcement is the control. Not a policy document, not training, but an allow-list at the identity layer that means an unapproved AI tool cannot obtain a grant into corporate data, and a personal account cannot become a bridge to a corporate one.
Secrets that can be read will be read
The second lesson is about what the attacker found. Stored configuration values that decrypt back to plain text were decrypted; values marked sensitive — the kind that can be used but never retrieved — were not. The company’s advice afterwards was to move every credential into the second category.
Data platforms have the same distinction and often make the same mistake. Connection strings in configuration files, service-account keys in pipeline definitions, warehouse credentials in a notebook’s environment: all readable by anyone who reaches the environment. The pattern that holds is credentials that are injected at runtime, short-lived, scoped to the job, and never retrievable as text — so that reaching the environment does not mean owning the platform.
This matters more with AI in the picture, because agents and tools are precisely the things that reach environments. An agent with access to a deployment environment where credentials are stored readably has, in effect, every credential in it.
What to do this month
- Pull the authorised-applications report from the identity provider and read it. Expect surprises. Revoke what nobody can account for.
- Enforce an allow-list for third-party authorisations, so approval happens before the grant rather than after the breach. Treat every AI tool on that list as a processor — inventoried, minimised, contracted.
- Break the personal-account bridge. Corporate data should not be reachable from an account the organisation does not control, however convenient the sign-in.
- Make secrets unreadable. Audit where warehouse and pipeline credentials live, and move them to injected, short-lived, non-retrievable forms.
- Check for the published indicator. When a vendor publishes the identifier of a compromised application, look for it in your own environment the same day.
None of this prevents an employee from finding an AI tool useful. It prevents the tool from becoming the weakest link in a chain that ends at the customer data — which, on the evidence of this incident, is exactly where such chains end.
