Faster AI, Older Weaknesses: The Infrastructure Catch-Up

AI Attacks, Familiar Weaknesses

An attacker getting faster is bad news for an organisation that already struggles to fix known weaknesses. The UK's cyber agency expects AI to put that gap under much greater pressure through 2028.

Our main story today is the National Cyber Security Centre's new threat assessment, and the question it raises for infrastructure operators: can repair and recovery keep pace as attacks become more automated?

Published on 3 November, the assessment says AI-powered malware is highly likely to feature in a ransomware attack on UK critical national infrastructure by 2028. That is a striking judgement. The mechanisms it points to include familiar weaknesses in legacy systems, alongside the extra ways into a network that deploying AI can create.

The NCSC is looking ahead. Its three scenarios describe plausible possibilities, and its findings concern the UK. For an Australian operator, the useful application is to examine the same operational pressures locally; the report doesn't put a number on Australia's exposure.

Start with the legacy systems. A known weakness is already something an organisation can investigate and address. The difficult part is getting from knowing about it to changing the system safely. Faster attacks can squeeze the time available for that work, even if the underlying weakness hasn't changed.

That gives patching capacity a very practical meaning. It's the ability to get a repair into service: identify the affected equipment, work out the operational impact, make the change and confirm that it worked. A growing queue of unresolved fixes represents work that still has to happen while an attacker can keep moving.

The agency also calls out unnecessary internet exposure. For an operator, that raises a fairly direct question about which systems need to be reachable from outside the organisation. Every unnecessary connection removed is one fewer route that has to be defended. That's a concrete design decision with a continuing benefit.

Then there's the additional exposure created by AI deployment itself. Connecting a new AI service to existing systems changes what can interact with them. The useful review includes those connections and the access they provide. An organisation can be dealing with old weaknesses and adding new access paths at the same time.

Recovery deserves equal attention. Prevention work reduces opportunities for an attack; recovery work determines how an organisation gets its service back when something goes wrong. Those are different operational jobs, and the NCSC's emphasis on resilience brings both into the conversation.

For example, a recovery plan becomes much more useful when an operator can answer which service comes back first and what that service depends on. Those dependencies affect the order of recovery and the people needed to carry it out. A rehearsal can expose gaps while there's still time to address them.

My reading is that Australian organisations get more value from this assessment by examining their repair and recovery speed than by treating it as a shopping list for an AI security product. Technology can help, but the work described here reaches into maintenance decisions, system design and the ability to restore operations.

There's also a useful way to frame the investment discussion. Addressing a longstanding weakness improves the position against the attacks an organisation already faces. It also reduces the opportunities available to a faster attacker. The same repair can serve both needs.

For people responsible for essential services, that makes the unresolved maintenance queue worth a fresh look. Which fixes are waiting, what is keeping them there, and how quickly could the service recover while those weaknesses remain? Those answers reveal where an organisation's capacity is falling behind.

Government AI Before the Purchase

That leaves operators with a concrete repair agenda. Here in Australia, another development brings control into the design stage.

On 30 October, the Digital Transformation Agency announced its AI Reference Architecture, with companion scenarios for Australian Government agencies. It gives agencies and suppliers a shared reference for designing, buying and governing AI systems.

The useful detail is how it connects those activities. System design sits alongside data controls, assurance and human responsibility. Agencies are asked to consider whether they can pause, change or stop an AI system, as well as what it can do while it's running.

A pause button sounds straightforward until you consider where an AI service fits into a larger workflow. If another system depends on its output, stopping it has an operational consequence. Working that through while the service is being designed makes the control more meaningful. Someone has to know what happens next.

The architecture also asks agencies to consider ongoing costs, interoperability and dependence on outside providers before committing to technology. Interoperability is the ability of systems to work together. In a purchasing decision, that includes how comfortably a proposed AI service fits the systems an agency already operates.

Those considerations can change how an offer looks. A service may suit the immediate task while bringing integration work or continuing costs that sit elsewhere in the agency's budget. Looking at the whole arrangement gives the buyer a better basis for comparing options.

Supplier dependence deserves the same early attention. If an agency later needs to change the service, its room to move depends partly on choices made at purchase. Data controls and integration arrangements become practical questions for the supplier while the agency still has options.

The guidance is voluntary and existing requirements still apply. Its immediate contribution is a common design reference, with scenarios that help agencies relate the architecture to their own work.

I think the strongest use is in the conversation between the buyer and the people who will operate the system. They can make control, running costs and provider dependence explicit before agreeing to the purchase. A design question answered there could save an expensive retrofit once the service is embedded in day-to-day work.

Coding Agents Put Pressure on Git

There's a developer version of the capacity problem, too: the code can arrive faster than the infrastructure can handle it.

On 2 November, OpenAI published the design of Pando, the Git-compatible backend now serving its main code repository. Parallel coding agents had put pressure on its previous source-control infrastructure. Pando began serving production traffic in April.

Git is the version-control system that records code changes and lets developers work on separate branches. A branch gives a person, or an agent, a separate line of development. When lots of agents are working at once, the repository has to handle their reads and updates alongside everyone else's.

OpenAI reports that median code-push latency fell by nearly eighty per cent with Pando. That's the time involved in sending changes into the repository, and it's a useful result for a workflow with many contributors trying to move work through the same backend.

Two design choices help explain the change. Pando processes unrelated branches independently, so work on one branch can progress separately from work on another. It also reuses packaged repository data across readers, reducing repeated work when multiple clients need that data.

Both choices fit a workload with many parallel agents. The source-control service can avoid tying unrelated activity together, while sharing preparation work where the same repository content is useful to several readers.

There is a specific consistency trade-off. Reads across multiple branches don't necessarily represent one simultaneous snapshot of the repository. A tool looking at several branches could therefore see states from different moments. That's relevant if its job depends on comparing those branches as a single, coordinated view.

Pando's announcement is an engineering disclosure. OpenAI is still exploring how to share the technology with users, so developers can examine the architecture now; there's no generally available hosted Pando service announced here.

For development organisations, the interesting implication is where to look when adding agents stops producing proportional gains. A model can finish an edit quickly while the wider workflow still spends time moving that edit, testing it and integrating it. Measuring only the model's response misses those waits.

My takeaway is that agent throughput is becoming a systems problem. The nearly eighty per cent figure describes OpenAI's code-push improvement. Getting more finished software out of a team depends on finding the slow step in that team's own path from a proposed change to working code.

Finding the First Fault

Once a large AI job fails, the awkward question is often which of the many errors came first.

NVIDIA has opened up Attribution, its system for diagnosing failures across distributed AI infrastructure. The 2 November release combines workload logs, metrics and scheduler information to help operators connect what happened across a cluster.

A distributed job runs across multiple machines. That creates a diagnosis problem: one initiating fault can produce symptoms in several places. An operator looking at each error separately has to work out which events belong together and where the trouble began.

Attribution uses deterministic rules to make those connections. In plain language, it applies defined logic to the evidence it receives. It distinguishes an initiating fault from downstream symptoms and returns the affected nodes, meaning the machines involved, with supporting evidence.

That distinction is useful because the most visible failure can be some distance from its cause. If one part of a job can't continue, other parts may report problems as a consequence. Treating every symptom as a separate incident makes the investigation longer and can pull attention away from the original fault.

The released components include a self-hosted analysis service and a reference integration layer. There are connectors for systems including Slurm and Kubernetes-related tooling, giving cluster operators something they can adapt to their existing monitoring and incident systems.

Scheduler information adds context about where work was running. Logs describe events, while metrics show measured behaviour. Bringing those views together gives an operator more to work with than a single failure message, provided the necessary information was collected.

That's the important operating limit: incomplete telemetry can leave the diagnosis ambiguous. Attribution can report that ambiguity. Its role is analysis; hardware repair and workload restarts remain with the surrounding operational systems and the people running them.

For an organisation paying for expensive AI jobs, I see the potential value in shortening the investigation after a failure. The open-source release offers a starting point for that correlation work. How useful it becomes on a particular cluster depends on whether the monitoring captures enough detail to connect the initiating fault to everything that followed.

Publishers Challenge Brave's Content Supply

The path from a publisher's page into an AI product is now at the centre of another legal dispute.

On 2 November, the New York Times and, separately, the publishers of the New York Daily News, Chicago Tribune and Orlando Sentinel filed lawsuits against Brave Software in Manhattan federal court.

The publishers allege unauthorised copying and distribution through Brave's search and AI products, along with paywall circumvention. The three-newspaper complaint seeks damages and an injunction. TheWrap, which reported both lawsuits, said Brave didn't immediately respond to its request for comment.

The important business detail is Brave's position in the supply chain. Search can be an intermediary between the publisher that produces material and an AI system that uses web content. These proceedings challenge what happens at that intermediate layer, including how content is obtained and supplied.

For a company building an AI product, using a search supplier can make access to web material technically simpler. It concentrates part of that work in a service the company can connect to. The legal dispute follows the content through that arrangement, so the choice of intermediary becomes relevant alongside the choice of model.

The requested injunction also gives the case an operational dimension. The publishers are seeking a court order as well as money. Whether any order is granted, and what it might cover, remains for the proceedings to determine; the filings haven't required a service shutdown.

An organisation assessing a content supplier has several distinct things to understand: what the service delivers, how that material is obtained and what the supplier's terms cover. A functioning technical connection answers the first of those only in part. The dispute concerns the underlying rights to the material being supplied.

My reading for AI businesses is that content sourcing belongs in supplier evaluation from the beginning. A search intermediary can simplify retrieval while leaving a product dependent on that supplier's legal and commercial arrangements. Here, that dependency is being contested directly, and the eventual outcome could affect how buyers assess the service.

Optical Links Reach Early Production

Down at chip level, there's a smaller manufacturing milestone worth keeping in view.

Tower Semiconductor and Innolight said on 3 November that Innolight's first near-package optics device has entered early production. It uses Tower's PH18M silicon-photonics process in California.

Optical interconnects move data using light. Near-package optics brings that approach close to the chip package, making it relevant to the connections that move data around AI infrastructure. Computation is only part of the job; data also has to reach the places doing the work.

The companies have also completed chip designs for manufacture on Tower's three-hundred-millimetre silicon-photonics platform for later product generations. Those designs sit further back in the development process than the device now entering production.

For infrastructure buyers, the useful signal is manufacturing progress. Production volumes, customer availability and realised cost or energy benefits haven't been disclosed, so this remains an early-production milestone. I'd watch how that progresses towards available products: moving data efficiently becomes increasingly valuable when the surrounding investment is in more computation.

Salesforce Plans to Buy Cresta

Back in customer service, a proposed acquisition could bring voice agents closer to customer records.

Salesforce announced on 2 November that it has signed a definitive agreement to acquire Cresta. The plan is to connect Cresta's voice-agent and human-agent assistance technology with Service Cloud.

That pairing covers both automated voice interactions and technology that helps a person handling a customer conversation. Bringing those capabilities closer to the customer-service platform could reduce the integration work needed to make them useful together.

Salesforce expects the deal to close in the first quarter of its fiscal year twenty twenty-eight, subject to regulatory approvals and customary conditions. That's Salesforce's financial-year timetable. The announcement doesn't disclose a purchase price.

It also says Cresta will continue supporting customers' existing contact-centre and telephony platforms after closing. That commitment is particularly relevant to buyers with established phone systems who are assessing how the proposed ownership change affects them.

There's no combined product available from this announcement. For contact-centre buyers, I see a potential trade-off between easier integration with Service Cloud and concentrating more of their service technology with one supplier. The details of the eventual integration will determine how attractive that balance is for an organisation's existing setup.

What Changes for You

If you're building an agent that keeps a long conversation going, there's a practical change you can use now.

Anthropic launched message threads in public beta on 2 November. After the first request, an application can send only the new messages, instead of uploading the agent's entire conversation again each time.

That tackles a growing overhead in an active session. As the conversation gets longer, repeatedly sending the same history means transferring more material before the next response can begin. Threads let the service temporarily retain that history while the application sends additions.

Access is available through the native Claude Platform, Claude Platform on AWS, Microsoft Foundry and Anthropic-managed Claude Models on Google Cloud. Anthropic says the feature is already enabled for most Claude Code users.

The company reports about thirty-five per cent lower median time to first token for requests containing five hundred thousand to one million tokens. That's how soon the reply starts. The measurement covers very long requests, so it's most relevant to builders working at that scale.

Claude still processes the full conversation. Token usage and standard token rates stay the same, making this a responsiveness improvement with unchanged inference pricing. The smaller upload reduces the material travelling back to the service on each request.

There are two practical design details. A thread expires after five minutes without a request, so the application needs its own conversation history and a way to replay it when the temporary thread disappears. That makes threads particularly suited to sessions that keep actively exchanging messages.

Thread contents are encrypted in server memory and deleted within one hour of last use. The feature isn't eligible for zero data retention. That gives builders a specific privacy boundary to assess against their application's requirements.

For coding, computer-use and document agents with long, active conversations, this could make the next response feel more immediate. The useful design is to keep the application's own history as the durable record, then use the temporary thread to avoid sending that record over the network again and again.