Gemini 4 Carbon puts cyber defenders first

Carbon reaches cyber defenders first

Google's newest frontier model can hunt for software vulnerabilities, but most developers can't use it yet. Cyber defenders are getting the first turn with Gemini 4 Carbon.

Our main story today is Carbon's arrival, and the question for organisations is how stronger AI bug-finding could translate into faster repairs. Google announced the model on 28 October, targeting sustained software engineering and cybersecurity work. Initial access starts this week for selected defenders, with expansion through Google's Fairwind programme. There's no date for broad developer or consumer access.

That gives this launch a particular shape. The first people putting Carbon to work will be testing it against defensive problems. For everyone planning an ordinary application or choosing a coding assistant, it remains a model to watch rather than an option to build around today.

There are two useful results to understand. Independent evaluator Artificial Analysis puts Carbon first on its Intelligence Index version five, with a score of 59. On the evaluator's coding-agent index, though, Carbon sits behind Claude Opus 5.5. Those results describe different strengths. A broad intelligence measure combines capabilities; a coding-agent evaluation asks how effectively a system carries out software tasks. For a developer, that second measure is closer to the job sitting in the editor.

Google reports 88.2 per cent on SEC-bench Pro, a vulnerability-finding benchmark. Its published external cybersecurity evaluations ran without guardrails, a condition that matters when comparing those results with a deployed service. The access programme gives selected defenders a way to explore how the capability behaves in their actual work.

The interesting engineering challenge is what happens after a model spots something suspicious. A useful finding needs enough detail for a maintainer to reproduce the problem and understand which code causes it. A repair then needs testing against the original failure and the behaviour the software is supposed to preserve. That's where an extended software task can involve much more than generating a patch.

Consider the difference between pointing to a risky function and working through a repair. The first gives an engineer somewhere to investigate. The second involves following how the function is called, understanding the assumptions around it and checking what changes when the code is altered. Sustained work is valuable if the model can carry that context through the investigation without leaving the engineer to reconstruct it at each step.

That is the practical attraction of Google's emphasis on long-running tasks. If Carbon helps defenders move from an initial finding to a reproducible test and a usable fix, the benefit could be less time spent joining those steps together. An organisation could put more of its engineering effort into resolving the issues it already knows about.

I'd judge the early rollout by the quality of those completed repairs and the time maintainers spend getting them ready. A particularly useful result would be a finding that arrives with a clear reproduction, a focused explanation and a repair that holds up under testing. That gives the person responsible for the system something concrete to act on.

AI findings reach a scientific software fix

That repair question already has a concrete example. The shorter news starts with software used to control scientific equipment.

On 27 October, the US Cybersecurity and Infrastructure Security Agency, CISA, disclosed four vulnerabilities in EPICS Base. EPICS supports control systems at major scientific facilities. Versions 7.0.10 and earlier are affected, and CISA recommends updating to 7.0.11.

Causal Security says its autonomous Cipher system found the four issues in three hours and 49 minutes. The discoveries have now progressed through coordinated work with maintainers to a public advisory and a released fix. For an operator, that last step makes the finding actionable: there's a specific software version to move to.

The most severe vulnerability has a severity score of 9.8 out of ten under the CVSS system. It can cause memory corruption, denial of service or potentially remote code execution. The demonstrated effects were memory corruption and crashes; remote code execution wasn't demonstrated, and CISA reports no known public exploitation.

A crash is consequential in this setting. Control software helps scientific equipment carry out a process, so interrupting that software can interrupt the work depending on it. A facility operator has to account for availability as well as the possibility of someone gaining access. The released update addresses a concrete problem even without an observed attack.

There are two practical pieces to the response: identifying installations running the affected versions, and reviewing their network exposure while arranging the update. An operator needs to know where the software is in use before deciding how a change fits around ongoing work. The version boundary in the advisory is useful because it gives that assessment a clear starting point.

What interests me here is that the researcher-to-maintainer handoff has produced something usable. The discovery speed is striking, but the repair is what changes the operator's options. For organisations considering AI-assisted security work, this is a more useful outcome to look for: findings that can be reproduced, accepted by maintainers and delivered as a fixed release. It also shows why the people maintaining the software remain central to the process. They turn a discovered failure into an update that other people can deploy.

Apple opens documents to agents

Let's leave the control room and come back to the documents on your desk.

Apple has announced direct AI-agent access to Pages, Numbers and Keynote through the Model Context Protocol, or MCP. In its Australian announcement on 28 October, Apple put the capability alongside new document-aware assistants in Creator Studio updates scheduled for November.

MCP gives an external agent a defined way to interact with an application's tools and content. Apple says agents will be able to read documents, make edits and perform automated actions. That creates a more direct connection between a request and the file you're working on. The agent can act inside the document workflow, reducing the copying and pasting involved when an assistant produces text in a separate window.

For a developer building an integration, the document itself becomes part of the task. An instruction to change a passage or work with a spreadsheet can be connected to the relevant application. The practical appeal is continuity: the same file provides the context and receives the changes. How well that works with complex documents will become clearer once people can use the November release.

There are separate access requirements for the two features. MCP support requires macOS 27 or later. The built-in assistants launch in beta, in US English, on Apple Intelligence-capable devices running iOS 27, iPadOS 27 or macOS 27 or later. Apple hasn't given an exact November release date.

The update is included for existing Creator Studio subscribers. Australian pricing is nineteen dollars and ninety-nine cents a month, or one hundred and ninety-nine dollars a year, including GST. That puts the new features inside an ongoing subscription, with hardware and operating-system requirements also shaping who can use them.

My main interest is the change from receiving a suggestion to receiving an edited file. For an organisation building around this, document permissions and an easy way to review changes become part of the product design. The useful experience would let someone see what the agent changed without having to compare the entire document by hand. Direct access could remove a tedious handoff, provided the resulting edits are equally easy to inspect.

Liquid brings compact models closer to the task

There's also a new option for developers who want the model running on their own hardware.

Liquid AI released its LFM3 family on 27 October, offering downloadable weights and hosted access across text, vision, audio, combined modalities and specialised decision tasks. The weights are the learned values that make up a model; downloading them lets a developer run and adapt it in a local environment.

One member of the family, LFM3-1.7B, is a text model with 1.73 billion parameters and a 256,000-token context window. Tokens are the chunks of text a model processes. A context window of that size gives it room to receive a substantial amount of material in one request.

The distinction between model size and context size is useful here. Parameters describe the learned model, while the context window describes how much material can be in view. A compact model can therefore have a large reading window while still being suited to a fairly bounded job. Liquid's own model card advises against using this model for agentic coding or complex multi-step reasoning.

That points towards a different development decision: identify a specific task, then see whether a local model can handle it. For example, a developer could evaluate whether it can extract a small set of details from supplied text. The attraction would be keeping that operation on the developer's chosen hardware and reducing its dependence on cloud inference.

Downloadable formats for local runtimes make that evaluation easier to start. Actual speed will depend on the hardware and workload, so the useful measurement is how quickly and accurately it completes the particular job. A long context window may be helpful, but feeding more material into the model still needs to serve that job.

The commercial terms also deserve a place in the decision. These models use Liquid's custom LFM Open Licence, with a US ten-million-dollar annual-revenue threshold in its free commercial-use terms. Larger organisations need to account for that licence before treating the weights as a deployment option.

For builders, I think the opportunity is a small, well-defined component that can run locally. Success would be a routine piece of work becoming easier to operate without a cloud model call each time.

Google TPUs head to Oracle Cloud

At the other end of the hardware scale, cloud buyers have another future capacity option to consider.

Oracle and Google announced on 27 October that Google's Tensor Processing Units, or TPUs, will be available through Oracle Cloud Infrastructure in calendar 2027. TPUs are specialised processors for machine-learning workloads, including training models and running them to produce results.

The companies describe Oracle as the first hyperscale cloud outside Google to offer Google TPUs. Oracle will provide power, cooling and data-centre networking, with capacity increasing over several years. The arrangement creates another cloud route to Google's accelerator technology.

For an infrastructure buyer, the provider relationship and the processor choice are connected decisions. An organisation using Oracle's cloud could gain a way to obtain TPU capacity through that environment. That could widen the hardware choices available when planning a future AI workload, alongside the practical question of where its data and surrounding services already live.

The physical part of the announcement is worth paying attention to. Providing power, removing heat and connecting the hardware are part of making accelerator capacity usable at scale. Oracle is taking on that infrastructure role. The multi-year ramp also means the announced service and the eventual amount of available capacity are separate planning milestones.

The timing is still broad: calendar 2027. Customer prices, launch regions and an exact opening date haven't been specified. Those are the details a buyer needs to compare a proposed service with capacity it can procure now. They determine where a workload can run and what the commercial commitment looks like.

I'd treat this as a useful addition to future procurement discussions. A buyer can ask how TPU access might fit a forthcoming training or inference project, while leaving the immediate capacity plan tied to services already available. The agreement could create more room to negotiate and more technical options to compare. Whether it offers a cost advantage will depend on the eventual terms and how the buyer's workload runs on the hardware.

Genie worlds gain sound and live edits

A smaller research preview offers a different kind of interaction: changing a generated world while you're inside it.

Google DeepMind announced Genie 4 on 27 October and began a trusted-tester preview. Its demonstrations combine interactive generated environments with native audio, including ambient sound and character dialogue. Testers can also change scenes using live text instructions.

Sound adds another part of an experience for a creator to explore. A scene can have an atmosphere you hear as well as see, while live editing lets the creator respond to what's happening instead of preparing every change in advance. That could make this kind of system useful for experimenting with the feel of an interactive environment.

The preview supports only a few minutes of continuous interaction. Google also identifies drifting object permanence and imperfect real-world accuracy. Object permanence means that things remain consistent as you move around or look away. If that drifts, an object can fail to persist as expected, which changes how reliably you can build an experience around it.

I'd see the immediate promise in rapid prototyping: exploring a scene, a mood or an interaction before committing to production. Physical-world testing requires dependable behaviour that this preview hasn't established. Access is confined to selected testers for now; wider Project Genie and developer availability are still forthcoming, without a confirmed date.

Anthropic steps into drug research

The next development puts an AI company much closer to the experimental work itself.

On 27 October, Anthropic disclosed that it had acquired Mithril Medicine and was running its own drug-research programmes, alongside partnerships with six life-sciences organisations.

Anthropic says Mithril's founder used Claude to coordinate contracts, logistics and experiments across eleven external laboratories. That is a substantial coordination problem: experiments depend on people and services outside a single organisation, and the paperwork and arrangements connect those pieces of work.

The interesting near-term possibility is reducing the effort spent keeping that network moving. If an assistant helps organise the contracts and logistics around an experiment, researchers could have more time for the scientific work and fewer administrative handoffs to chase. That's an operational benefit worth examining in its own right.

The programmes remain mostly preclinical, meaning the work is largely at the stage before testing in people. No new treatment becomes available through this announcement.

For research organisations, I'd watch how much coordination work these systems can take off a scientist's desk. Anthropic's acquisition puts it directly inside the process of developing potential medicines, where it can encounter the practical demands of experimental work alongside its partners. The earliest useful improvement may be a better-organised experiment, well before a new drug reaches patients.

What Changes for You

If you've been switching models between writing code and reviewing it, GitHub now offers to handle that coordination.

Copilot Fusion became generally available on 28 October. GitHub lists it across all Copilot plans in VS Code, the Copilot app, Copilot CLI and JetBrains IDEs, with the available choices governed by your plan and organisation's policies.

You choose an effort level, and Fusion decides which eligible models to use. It can send the task to one model, check an initial attempt and escalate it, or have another model critique a draft before a revision. That gives the coding tool several ways to allocate effort without asking you to pick every step.

The practical change is that model selection becomes part of executing the task. A developer can stay focused on the requested change while the service manages the sequence of drafting, checking and revision. For someone who already coordinates that manually, it could remove a recurring bit of administration.

Artificial Analysis tested Fusion Max in Copilot CLI and measured five US dollars and fifty-nine cents per task, compared with eleven dollars and forty-two cents for Claude Code using Opus 5.5 Max. Fusion finished two index points behind in that coding-agent evaluation. It's an interesting measured trade-off: a lower cost in that test, with a slightly lower score.

The billing detail to understand is that each model actually used contributes to the charge. One request can trigger several model calls, so cost varies with the work Fusion chooses to perform. Your effort setting, tasks and permitted models shape your usage.

Administrators control the eligible model pool. That setting now influences which providers can participate in drafting and review, even when an individual developer isn't selecting them manually. For working builders, the useful gain is less time managing model handoffs. For the organisation paying for it, the model pool and effort settings become practical controls over how much work happens behind a single request.