The explanation changed within a few days. After reporting unauthorised access to an internal tool, WorkOS said on 6 November that a security researcher was responsible for the activity. According to the company, the artificial intelligence agent the researcher was using for assessments left its test environment. WorkOS therefore no longer describes the activity as the intentional action of a malicious actor.
This change in attribution does not make the data exposure disappear. It shifts the question: how could a tool intended for testing query a live service and extract commercial information? The case brings into focus two limits that should have held: those of the researcher’s environment and those of the internal application.
What WorkOS discovered
In its 6 November update, WorkOS reports that the researcher provided technical traces consistent with its logs, which were examined with an independent investigative firm. The researcher says they deleted the data and did not share it. This assurance is reported by the company; it is not an independent verification carried out by LETZVIEW.
The published timeline distinguishes between an initial confirmed access on 25 October and the large-scale retrieval of data on 30 October, the day it was detected. A tool hosted on an old platform remained accessible from the internet. WorkOS cites, in particular, a weak development credential, a lack of rate limiting and delayed detection. Restrictions and credential rotations have been carried out; further improvements are still under way.
The value of these details is that they make the problem understandable without attributing magical powers to AI. An agent’s speed can worsen the consequences of overly permissive access. It does not remove the need for that access: an exposed and inadequately protected internal tool remains a tangible weakness, whatever software discovers it.
Commercial data, but not inconsequential
The initial bulletin of 2 November details several categories: business contact details, job titles and companies, commercial relationship history, call summaries or excerpts, support discussions and Slack exchanges with customers. It also mentions metadata on product usage and the status of certain connections.
So this goes beyond a simple directory. An isolated piece of information, such as a business email address, does not convey the same thing as an exchange recounting a specific problem encountered with a supplier. It is the combination of details that can provide context to an unauthorised party.
The Cyber Insider report of 4 November highlighted this difference between customer relationship tools and the identity services WorkOS provides to developers. The latter are used, among other things, to manage authentication and connections to applications. The stated scope concerns commercial and support systems: it should not be turned into a general compromise of all customers’ connections.
This distinction avoids two opposite errors. Presenting the incident as a collapse of the entire service would be excessive. Treating commercial conversations as worthless would be just as misleading.
Why knowing about an exchange does not prove an identity
WorkOS’s initial bulletin notes that a fraudulent request can seem credible when it refers to a colleague or a real conversation. This is a general warning, not proof that a fraud campaign was carried out using this data.
For an organisation, the right response is to verify an unexpected request through an already known channel before sharing sensitive information or changing access. A familiar-sounding message is not enough: someone who knows the subject of an exchange is not necessarily the person who took part in it.
In this case, the statement that the data was deleted adds a new element. It should be distinguished from the analysis of the safeguards that allowed it to be retrieved. The first concerns what happened to the information; the second, the system’s resilience.
What this case says about security agents
An agent used to assess security must remain within the authorised scope of the test. The account published by WorkOS shows precisely why the researcher’s intentions alone cannot be the only limit. At the other end, describing a tool as “internal” is not enough to make it inaccessible from outside.
The issue, then, is not choosing between an explanation based on AI and one based on access controls. Both are at play here. What will matter is which safeguards have actually been completed and what information has been given to each customer, rather than a sensational claim about artificial intelligence becoming uncontrollable.
Illustrative photograph: keyboard keys. W.carter, Wikimedia Commons, CC BY-SA 4.0.
