Fleet runs its frontier-model security tests in temporary cloud accounts on synthetic data

The exercise starts from outside. Heath said the model approaches the temporary deployment without application credentials and proposes possible attack paths ^[15]. Inside that deployment it can execute test steps and probe the running system ^[10]. Credentials are limited to that environment, a Fleet security engineer supervises the session, and anything extending beyond the environment requires that engineer's approval ^[11]. The environment is removed afterward ^[12].

Then a person has to reproduce it. Lets Data Science described the workflow this way: "The approval step sits in the middle: a security engineer decides what the model may try, then reproduces each candidate finding by hand before anyone treats it as real" ^[16]. Confirmed findings enter Fleet's existing remediation and disclosure process, Heath said ^[17]. Sometimes the model identifies a problem the team already knows about. That can help check a capability without turning up a new vulnerability ^[18].

Heath states eight controls separately. There is the synthetic-data test environment ^[6] and the exclusion of customer endpoint data ^[7]. There are credentials scoped to that environment, engineer supervision of the session, engineer approval to reach past it ^[11], and teardown ^[12]. Model access is restricted to named security team members with phishing-resistant multifactor authentication ^[13], and manual reproduction is required before a finding counts ^[16][23]. Most of that is ordinary access control applied to a new kind of client. Heath described those safeguards as already in place, and said broader coverage across the release process remains planned ^[14].

The value for a buyer is that each item is a question with a checkable answer. Which cloud account did the test run in? What data was in it? Did the model hold application credentials? Who approved an action that reached outside the environment, and who reproduced the finding? The answers have limits. Heath told LDS that "Customer endpoint data is not used in this work" ^[7] and added that no data from customer environments is shared with the model or Anthropic ^[8]. LDS notes that this describes the research workflow and should not be generalized into a claim about every AI integration a Fleet customer might separately use ^[9]. Heath also said the September 15 announcement does not introduce a new Mythos-powered feature for customers ^[4]. He separately described the endpoint-management functions Fleet already provides, including checking device state, deploying changes and reporting patch status ^[24].

Heath did not disclose an individual Glasswing finding, a reproducible test result or a measured performance improvement. He said detailed findings would follow after fixes have shipped and the material has been reviewed for safe disclosure ^[20]. Fleet's published engineering handbook covers an engineer's initial review of security reports and staging fixes while limiting disclosure of unresolved vulnerabilities, and its security handbook covers severity-based remediation and exceptions. LDS says those documents are background; they do not report results from the Glasswing work ^[19]. LDS also says its account does not establish that it has independently audited Fleet's implementation of these controls ^[22].