When Open Models Learn Advanced Cyber Exploitation

Open Models and Cyber Capability

An open-weight AI model has completed an advanced cyber-exploitation task in a Japanese safety evaluation, without refusing any of the 41 tests it was given. Access to model weights doesn't tell a security team how capable, or how cautious, that model will be.

Our main story today looks at that result and what organisations need to test before putting powerful models near sensitive systems. Japan's AI Safety Institute, or AISI, compared the open-weight GLM-5.2 model with Claude Opus 4.7 and 4.8 on ExploitBench. The benchmark uses tasks based on known vulnerabilities in Google's V8 JavaScript engine. Each model had one attempt at each of 41 tasks, with a ceiling of 300 turns or five hours.

Claude Opus 4.8 recorded the highest average score at 5.22. Opus 4.7 averaged 3.63, while GLM-5.2 averaged 2.80. That ranking is useful, but the striking detail sits beneath it: GLM-5.2 completed a T3 task, the benchmark's highest tier. An open-weight model scoring below both closed models overall still demonstrated an advanced exploitation capability on at least one task. Average performance and peak demonstrated capability answer different risk questions. A model that succeeds less often may still be consequential if one successful run is enough to expose a system.

AISI also saw a difference in refusal behaviour. GLM-5.2 didn't refuse any task in this test environment. The Claude models sometimes did. AISI says that may point to different default safeguards, but it isn't a universal finding about either model family. The evaluation covered known vulnerabilities, specific model versions and one run per model per task. Changes to the prompt, model, system instructions or agent harness could produce materially different results. These are probabilistic systems, and a single pass can't establish their general offensive capability or safety. Repeating the evaluation could shift the scores, while a different set of vulnerabilities could change the relative ranking.

The distinction between capability and refusal is important. A model may have enough technical ability to complete a task yet decline it under one set of safeguards. Another deployment of the same underlying model may use different instructions or controls. Security testing therefore has to examine both layers: whether the model can perform the work and whether the deployed system prevents or contains misuse.

Even with those limits, the evaluation makes a neat label-based risk assessment hard to defend. Open weights can make inspection and local control easier, but openness doesn't guarantee weak offensive capability. A closed service may apply default refusals, yet those safeguards can vary by task and deployment. Neither category gives a security reviewer the answer on its own.

For an organisation considering a model for vulnerability research, code review or an agent with access to internal systems, the practical question is what that exact deployment can do. That means testing realistic exploitation tasks, refusal behaviour and the permissions around the model, using the prompts and tools it will actually receive. The review should also distinguish a model running in an isolated test environment from one that can reach source code, credentials or production tooling. My read is that procurement categories now need to give way to task-level evidence. The model licence and hosting arrangement still matter, but they can't substitute for testing capability and safeguards together.

A New US AI Coordination Point

That benchmark leaves organisations with operational questions, while the United States is trying to settle who coordinates the federal response.

On 4 October, the US announced a federal AI task force led by Director of National Intelligence Jay Clayton. Reported members include chairs or senior leaders from the intelligence community, the Federal Trade Commission, the Pentagon's technology office and the federal personnel agency. The group is expected to report to the President and the White House chief of staff.

Its remit reaches beyond government departments. The task force is expected to engage AI companies, consumers, critical-infrastructure operators and public-interest groups. That could give companies and infrastructure providers a more central place to raise issues that currently cross security, competition, defence and workforce policy. A shared table can speed up a decision when several agencies have a piece of the problem. It can also expose conflicts earlier, before one part of government approaches AI as a security issue while another treats the same deployment as a competition or workforce question.

At this point, though, the announcement describes a coordination body rather than a new regulatory regime. It doesn't specify a budget, statutory powers, milestones, binding decisions or concrete deliverables. There is no immediate compliance obligation in the material announced, and it remains unclear how the task force will interact with agencies that already have their own mandates. Coordination only becomes operational when someone can set a priority, resolve a disagreement and follow through. The announcement doesn't yet say who has those powers.

The membership also makes the priority order difficult to predict. National security, market competition, defence technology and the federal workforce can pull an AI policy discussion in different directions. My assessment is that affected organisations should treat this as a potentially important route into federal decision-making, but not yet as a rule change. The first useful signal will be a defined work program: which problems it takes on, who owns the decisions and whether its recommendations carry authority beyond the room.

Anthropic Trains Enterprise AI Engineers

Policy coordination is one bottleneck. Inside large organisations, the shortage of people who can turn a promising demo into a working system is another.

Anthropic has announced Claude Frontier Academy, backed by a stated commitment of 100 million US dollars. The target is to prepare 10,000 engineers to deploy Claude in large organisations by the end of 2027. Initial cohorts are already running in San Francisco, New York and London, with the first graduates expected in early 2027.

The program combines intensive in-person training with a graded practical assessment and a 12-week residency. During that residency, each participant is meant to deliver a Claude project inside their own organisation. That structure aims at the difficult part of enterprise AI work: connecting a model to real data and workflows, then getting the result through the organisation's technical and operational constraints.

Access is narrow. Engineers need to be nominated through participating organisations, so this isn't an open course that any developer can join. Anthropic also hasn't published a spending breakdown, a completion target, an independent assessment framework or evidence from finished deployments. The scale and benefits are company claims until cohorts graduate and their projects can be assessed.

There is a genuine skills gap here. Many businesses have people who can call a model API and build a prototype; fewer have enough engineers who understand evaluation, integration and the messy work of operating that system inside a large business. A residency tied to an internal project could make that knowledge useful quickly.

It also concentrates learning around one supplier's models and tooling. For participating organisations, my practical reading is that the academy could accelerate delivery, provided they separate durable engineering skills from vendor-specific habits. If the result is a stronger internal capability that can evaluate architecture and model choices, the investment has broader value. If expertise becomes inseparable from Claude, switching costs rise along with competence.

Project Suncatcher Reaches Orbit

The infrastructure problem is pushing in a much stranger direction: Google has now put part of an AI-computing experiment into orbit.

Google and Planet launched a prototype satellite for Project Suncatcher aboard SpaceX's Transporter-18 mission on 1 October. Google says it has established contact and the satellite is operating as expected. Over several weeks, the companies plan to test how hardware intended for AI computation handles radiation, temperature extremes and the physical stresses of orbit, with a focus on Google's TPU-related hardware.

This is an experiment in hardware survival, not the opening of a space data centre. Project Suncatcher remains a research project. The launch hasn't demonstrated a large orbital AI cluster, and it doesn't offer a commercial computing service. It should provide physical measurements that simulations and ground tests can't fully reproduce, which is a sensible early question to answer before anyone talks seriously about deploying compute at scale. Early contact confirms the satellite is alive; it doesn't yet tell Google how the hardware behaves after repeated exposure to orbital conditions.

The attraction is understandable. AI systems are increasing demand for power and data-centre capacity, so researchers are examining infrastructure well beyond a conventional server hall. But a processor continuing to work in orbit clears only the first gate. Useful orbital computing would still need workable networking, cooling, maintenance and economics. None of those has been demonstrated by this launch. Even moving data to and from a cluster becomes part of the architecture rather than an ordinary network assumption. A design also has to cope with failures in a place where replacing a board is nothing like swapping a server in a rack.

For infrastructure planners, the near-term consequence is evidence, not capacity. Google's test may show which components fail, degrade or survive, and that can shape later prototypes. My view is that the project deserves attention as a measure of how far compute research is being pushed, while remaining outside any current purchasing plan. A successful hardware experiment would make the next engineering questions worth funding; it wouldn't prove the overall system viable.

Aurora Queries the Data Lake

Back on the ground, AWS is trying to remove a more familiar infrastructure headache: copying data before an application can query it.

Aurora PostgreSQL can now directly query Apache Iceberg tables and Parquet files stored in Amazon S3. The feature is generally available in Aurora PostgreSQL versions 17.11 and 18.6 or later across commercial and GovCloud regions, with no separate feature charge. Developers expose the external data as PostgreSQL foreign tables, then combine it with operational records through familiar SQL.

That can remove a separate extract, transform and load pipeline for some applications. A service might keep current transactions in Aurora while querying historical or analytical records in a data lake, without first copying those records into the database. AWS has embedded DuckDB to run the external-data queries, and the integration supports S3, S3 Tables, the AWS Glue Data Catalog and federated external Iceberg REST catalogues. Existing PostgreSQL application code can reach that data through a database interface it already understands, rather than introducing another query service into every application path.

Direct access doesn't turn remote object storage into local database pages. AWS recommends materialising frequently used external data for latency-sensitive workloads. In plain terms, if an application needs the same result quickly and often, keeping a prepared local copy may still be the better design. AWS also hasn't supplied independent production comparisons for latency or total cost, so the useful answer will depend on each workload's query pattern, data volume and tolerance for delay. No separate feature charge also doesn't mean every query is cost-free; the surrounding storage and workload still need to be measured.

The appealing part for developers is architectural simplification. Fewer copies can mean fewer synchronisation jobs, fewer stale datasets and less pipeline maintenance. The trade-off is tighter coupling to AWS storage and catalogue services, alongside performance that will vary with the query. I would use this feature to simplify occasional joins between operational and lake data, then test the expensive paths with real traffic. It broadens what an Aurora application can reach; it doesn't erase the reason databases cache and materialise data.

Security Advisories Get Private Notes

A smaller change at GitHub could tidy up one awkward part of vulnerability handling.

GitHub has added confidential comments to repository security advisories. Only people with write access to the repository can see those comments. Reporters and invited collaborators without write access aren't notified, and views are recorded in the audit log. That gives maintainers a place inside the advisory for sensitive triage discussion that isn't ready to share with every participant. It also keeps an auditable record of who viewed material that may contain exploit details or internal decisions.

GitHub has also released a public-preview REST API for ordinary, non-confidential advisory comments. It can read, add and edit comments, including on advisories created from private vulnerability reports. It can't delete comments. Confidential comments are available through GraphQL, but they're excluded from this REST API. Both additions apply only to public repositories. An automation can therefore manage the discussion intended for broader participants, but it can't use that REST interface to handle the maintainers' confidential thread.

For maintainers, the useful change is less fragmented coordination. Internal discussion can stay attached to the vulnerability record, while bots and security tooling can automate the shareable part of the conversation. The limits are significant: the split between GraphQL and REST prevents one clean automation path, private repositories aren't covered, and a preview API may change. My take is that this is already useful for public open-source projects with formal triage workflows, but it isn't yet an end-to-end advisory automation system.

AMD Packages AI for Deep Space

Orbit also changes what a processor package has to prove, and AMD is giving aerospace engineers an early part to work with.

AMD has begun sampling its XQRVC1902 Versal AI Core adaptive system-on-chip in an enhanced space-grade package to selected early-access customers. The company is targeting geosynchronous, cislunar, heliocentric and deep-space applications, including onboard AI and signal processing. AMD says the component is intended for missions lasting up to 15 years and is going through Class Y testing under the MIL-PRF-38535 standard.

The package is pin-compatible with the existing VC1902 2197-ball BGA design. That lets a customer begin engineering work without redesigning the board interface around a different pin layout. For a long aerospace development cycle, preserving that interface can bring prototype work forward while qualification continues.

These samples are not flight-qualified production units. AMD expects Class Y flight-qualified parts in the second half of 2027, and it hasn't disclosed independent test results, customer deployments or mission-level performance. Aerospace engineers can explore designs now, but qualified mission hardware is still several quarters away.

The practical lesson is that space AI depends as much on packaging, radiation tolerance and long-duration reliability as it does on raw throughput. My assessment is that early sampling reduces design risk for teams already considering this platform, but it doesn't reduce qualification risk. The important evidence arrives when testing is complete and real mission designs can be matched to the finished part.

What Changes for You

For anyone repeating the same prompts in Gemini, a new reuse option is beginning to appear.

Google started rolling out Gemini Skills on 30 September. A Skill can hold reusable instructions, supporting files and a preferred output, then be invoked by name inside a conversation. Users can combine several Skills, and the supporting material can include text, PDF or image files. The immediate benefit is consistency: a recurring research, writing or analysis workflow doesn't have to be rebuilt from scratch in every chat.

Google says the rollout is global for people aged 18 and over across all Google AI subscription tiers. Access for younger users is planned later. Workspace business, enterprise, nonprofit and education accounts are due in the coming weeks, so not every eligible work account has it yet.

This also starts the replacement of Gems. Google plans to migrate existing Gems before removing Gems support in stages from November 2026 through June 2027. Some sharing, Drive and Notebook features don't yet have equivalent behaviour, and Gems made in Google Labs won't migrate. Existing users therefore need to check what survives the move rather than assuming a Skill is a drop-in copy.

For regular Gemini users and working AI builders, Skills make repeated prompting easier to package and combine. The main limitation is lock-in to Google's workflow format, along with a phased rollout and incomplete feature parity. My read is that Skills are useful now for stable, low-risk routines, while important Gems should stay put until the required files, sharing and integrations are confirmed in the new format.