Anthropic Cyber Mission, Sophos MDR agents, and the StackAI browser agent
Issue date:
This issue covers Anthropic’s programs for critical infrastructure and open-source security, Sophos’s use of agents in managed detection and response, and Asana’s StackAI browser-agent changes. The Sophos and Asana figures appear in OpenAI publications based on the companies’ accounts; they should not be assumed to hold in other settings.
This issue may include important events published earlier.
Anthropic introduces Cyber Mission for critical infrastructure and open source
Previously published event ·
Anthropic introduced Cyber Mission as a long-term effort with two initial areas. Its Critical Infrastructure Defense Program (CIDP) brings Claude models, on-site engineers, and threat research to providers that secure operational technology: the equipment controls and networks used in industrial operations. Its second offering, OSS Scanner, provides free scans to open-source projects that opt in. Models generate the reports, which are sent without human review.
Key facts
CIDP work is already under way with some partners. Anthropic is starting with a small group of critical-infrastructure security and equipment providers, not opening the program to every operator at once.
OSS Scanner periodically sends enrolled projects reports with an explanation, a proof of concept for exploitation, and a suggested fix where available. It is intended for maintainers with the capacity to process findings.
Anthropic expects OSS Scanner’s true-positive rate to exceed 90%, but warns that its unreviewed reports may be wrong, including in their severity ratings.
For projects that cannot handle a stream of unreviewed reports, Anthropic says it will continue human-verified disclosures under its coordinated vulnerability disclosure policy.
An objective look at what matters
The two efforts address different bottlenecks. In critical infrastructure, vulnerable equipment may not be safely taken offline for a patch; specialists need to assess the risk and plan changes. In open source, more scanning may surface possible bugs sooner but also increase the triage queue. Anthropic itself notes that verifying, prioritizing, and fixing findings is harder than finding them.
Business processes
Industrial equipment vulnerability management — CIDP partners may prepare information on weaknesses more quickly for specialists deciding when and how to change a running system safely.
Open-source project maintenance — Periodic reports may add candidates for validation and repair. Maintainer workload could fall with effective filtering or rise with the volume of findings.
Automation opportunities
Scanning and initial sorting of vulnerability reports: Enroll a suitable project in OSS Scanner, route reports into a review queue, and pass confirmed issues to maintainers. Automated patching is not a stated capability of the service; Anthropic describes it as a future goal. Conditions: Enrollment is optional, and the team needs the capacity to process findings.; Validate model reports before remediation or disclosure, including severity and whether a suggested patch works.
Preparing critical-infrastructure vulnerability reviews: CIDP providers may use Claude and threat research to identify weaknesses and prepare repair options. Specialists must decide whether changes are safe. Conditions: Anthropic is working with a small initial cohort of partners.; Changes to running equipment need safety checks; a model recommendation must not be applied automatically.
Impact on manual work
Scanning may reduce manual searching for potential bugs. People still need to validate, prioritize, disclose, and safely repair findings; a reduction in that work has not been measured.
Limitations and risks
A true-positive rate above 90% is Anthropic’s expectation, not a published, independently verified result.
OSS Scanner reports are sent without human review and may contain incorrect severity ratings or other errors.
Report volume could overwhelm a small maintainer team; the service is aimed at projects able to triage findings.
Finding a flaw in operational technology does not mean it can be fixed quickly without disrupting a running facility.
Sophos reports results from OpenAI Daybreak agents in MDR
Sophos uses agents built through OpenAI Daybreak in its managed detection and response service, or MDR. One agent gathers customer context, detections, and threat information. A planning model creates an investigation plan, carries out its steps, and prepares a summary with recommendations for an analyst; other agents can perform parts of the response. Sophos reports an average response time of about 89 seconds for cases using agents, compared with roughly 38 minutes in its earlier process.
Key facts
According to OpenAI’s account, Sophos draws on its own products and more than 500 third-party integrations to produce cases investigated across nine security operations centers.
Sophos compares the roughly 38-minute average of its previous process with about 89 seconds for cases using agents. The publication does not describe a controlled comparison of like-for-like case groups.
Sophos says AI resolves 52% of MDR cases end to end within boundaries calibrated by its analysts. That is a share of cases, not a response-time figure for the whole queue.
Customers can choose Notify, Collaborate, or Authorise: from receiving a recommendation to allowing Sophos to act on their behalf. The same authority boundaries apply to people and agents.
An objective look at what matters
This automates a sequence of investigation work, not just drafting text: collecting context, planning, completing steps, and passing on a recommendation. It could leave analysts more time for complex threats and exceptions. Speed, however, does not establish that conclusions are correct or actions safe. An agent can act for a customer only within the chosen service mode, and potentially destructive actions still require appropriate human oversight.
Business processes
MDR and security operations center investigations — Agents can gather scattered evidence and prepare a reviewable summary before analyst intervention. Sophos reports faster handling for cases that use them.
Response to detected threats — Some permitted steps may be completed sooner when customer authority and conditions for handing a case to a person are clear.
Automation opportunities
Context gathering and investigation preparation: Collect alerts, indicators of compromise, and threat intelligence, then present completed investigation steps and recommended actions to an analyst. The reported deployment is Sophos’s, not an off-the-shelf workflow for every security team. Conditions: Useful data, integrations, and approved investigation playbooks are needed.; Route recommendations and unusual cases for review according to risk and customer policy.
Authorized MDR response actions: Assign agents only the response steps the customer permits under the chosen service mode; leave other decisions to people. Conditions: Under Notify the customer acts; Collaborate involves joint action; Authorise lets Sophos act on the customer’s behalf.; Potentially destructive actions and cases outside permitted boundaries need specialist oversight or judgment.
Impact on manual work
Sophos describes a deployment in use and says agents resolve 52% of MDR cases end to end. This is vendor evidence of reduced manual work in its process; the OpenAI publication does not independently measure the effect.
Limitations and risks
The 89-second and 52% figures come from Sophos in an OpenAI publication; no independent validation is provided.
The time comparison uses an earlier process and agent-handled cases; it does not establish the same gain for every threat type.
Sophos hands work it does not consider suitable for an agent to people. Authority to act depends on the customer’s mode.
Agents do not replace security basics such as patching, multifactor authentication, and network segmentation.
Asana releases changes to the StackAI browser agent
Asana released changes to browser navigation in StackAI: the agent retains more browsing history, caches that history, and removes screenshots in batches rather than after nearly every step. According to the published account, StackAI’s CTO directed experiments with GPT-6 Astra in Codex. In the tests, a GPT-6.1 Sol configuration completed the test task in about four minutes on average, at an estimated model cost of $0.47 per run.
Key facts
Asana released StackAI browser-agent changes after testing history caching, how much text the agent retains, and when it removes screenshots.
Asana reports 144 runs across four models. Every configuration performed one task: collecting six fields for each of 32 books in a public demo catalog.
Asana puts the optimized GPT-6.1 Sol workflow at an estimated $0.47 in model cost and roughly four minutes per run: 76 times cheaper and five times faster than its original production setup on Model B.
Asana also reports that with a larger browsing-history allowance, all 18 relevant GPT-6.1 Sol runs returned the correct answer; with the smaller allowance, only three of 18 returned an answer.
An objective look at what matters
If a browser agent repeatedly sends accumulated page text and screenshots to a model, successive steps can become expensive. Frequently deleting old material also changes the history, undermines caching, and may remove information the agent needs. Asana’s test illustrates why cost, speed, and task completion belong in the same evaluation. The overall comparison cannot be credited to caching alone: both the workflow and the model changed.
Business processes
Web application tasks and data collection — Better history management may cut cost and delay in navigation and information-gathering tasks if they resemble the tested workload.
Software experimentation and testing — An agent can run configuration variants and prepare results for engineers. Asana also uses GPT-6 Astra to look for bugs before features are released.
Automation opportunities
Tuning browser-agent cost and answer quality: Test history limits, caching, and screenshot removal on the team’s actual workflows, comparing successful task completion as well as request cost. Conditions: Validate results on relevant sites and data; the published figures come from one book-catalog task.; Track model cost, runtime, answer correctness, and the risk of losing useful context together.
Agent-assisted feature testing before release: Run agent sessions with varied inputs to navigate an interface and send suspected bugs to human quality-assurance reviewers. Conditions: Asana says it uses this approach but is still developing tools to repeat similar experiments more easily.; People must review reported bugs; the browser-optimization test did not measure this testing workflow’s quality.
Impact on manual work
StackAI’s CTO estimates that work taking about a week with GPT-6 Astra would have taken one to two months by hand. This is a participant’s estimate, not an independent measurement of labor saved.
Limitations and risks
The 144 runs tested variations of one task; comparable savings or speed on other sites have not been shown.
The 76-fold cost comparison combines a model switch with workflow changes, so it does not isolate either factor’s contribution.
Some original Model B runs hit a step limit before completion, making the published average baseline cost a lower bound.
The $0.47 figure is estimated model cost, not verified total operating cost; interested parties published the results.
