Australia's cyber resilience test, AI agent controls and cheaper Terra access

Australia's cyber resilience test

Taking a service offline to secure it can be a difficult call. Australia's latest cyber threat report puts that decision squarely in front of organisations already trying to bring more AI into their operations.

Our main story today is Australia's cyber resilience: how organisations keep essential work going while replacing the exposed systems they still depend on. The Australian Signals Directorate released its annual cyber threat report on 27 October, covering the 2025–26 financial year. It warns that AI is accelerating malicious activity and calls for stronger defensive capabilities.

The Australian Cyber Security Centre responded to more than fifteen hundred cyber security incidents during that period, an increase of more than twenty per cent. It also issued more than forty-four hundred notifications about potentially malicious activity, almost eighty per cent more than the previous year. Those are separate workloads: responding to incidents and notifying organisations about activity that may need attention. The figures don't isolate AI's contribution to the increase.

The most concrete response came from Defence Minister Richard Marles in an interview on 27 October. He urged organisations to replace exposed legacy systems and accept temporary service interruptions where necessary to secure them. He also pointed to the use of defensive AI.

Accepting an interruption sounds straightforward until the affected service is something your organisation uses every day. A system can be old, exposed and still deeply useful. Replacing it means dealing with the work that runs through it, the people who rely on it and the period when its replacement is being put in place.

That's why the shutdown point deserves attention. Planning a service interruption creates room to decide which work can wait and which essential operations need another way to continue. An interruption during an incident leaves much less room to make those choices. That's the operational consequence I take from Marles's comments: security maintenance needs a place in the organisation's service planning.

Consider an organisation deciding whether to pause a service for replacement. The immediate cost is visible: staff time, delayed work and inconvenience for customers. The benefit is harder to put on the same page, because it involves reducing exposure and improving the organisation's ability to recover. A decision based entirely on keeping today's service running can leave the underlying replacement work permanently deferred.

For leaders, this puts a practical question alongside every AI adoption proposal. If a system becomes unavailable, how much of the surrounding operation stops with it? More automation can make a service more useful while also making more work dependent on its availability. The value of a replacement plan includes knowing which of those dependencies can be interrupted safely.

Defensive AI belongs in that discussion too. An organisation considering it still has choices to make about the systems being protected, the work needed to modernise them and how people respond when something needs attention. Those operational decisions shape what a defensive tool can usefully contribute.

My takeaway is that resilience deserves to be assessed as an ability the organisation can demonstrate. Can it contain an incident? Can essential work continue while a service is secured or replaced? The report gives Australian organisations a strong reason to put those questions into the same conversation as their plans for new AI capabilities. Someone has to be able to authorise the maintenance window, and the business has to be ready to use it.

Oracle puts agent limits in the database

That's the wider resilience challenge. Oracle's latest announcement tackles a more specific question: what can an agent change?

On 26 October, Oracle announced its Deep Trust AI Architecture. It's a blueprint combining controls across the software platform, database, data access and application runtime. The central idea is to enforce user permissions and business rules inside the database, including spending limits, when requests come from applications or AI agents.

An agent can be told what it's allowed to do in its instructions. A database can also check whether the requested action fits the user's permissions and the organisation's rules. Oracle's proposal puts those rules beneath the model, at the point where the request reaches business data.

Its Deep Trust Data APIs expose controlled business objects, such as purchase orders, in place of unrestricted SQL access. SQL is the language used to query and change database records. A business-object interface gives the agent a more defined thing to work with: a purchase order carrying the rules associated with that business operation.

Take the spending-limit example in Oracle's announcement. The useful question becomes whether a requested purchase is permitted for that user and within the configured limit. That decision can be enforced through the database architecture even when an agent has generated the request. The model can help work out what to request; the configured rules determine what can proceed.

For an organisation already using Oracle, that could make it easier to give agents access to useful business functions without exposing a broad database interface. It also puts more weight on defining permissions and business rules accurately. The architecture needs a clear answer to whose authority a request carries.

The blueprint brings together Oracle products, including AI Database and APEX. It's tied to that platform, and complete availability and pricing for every component weren't supplied in the announcement.

I can see the appeal for existing Oracle customers: enforce the spending rule close to the records it governs, and let applications and agents encounter the same boundary. The trade-off is deeper dependence on Oracle's database and application stack. That becomes part of the architecture decision alongside the amount of useful access an organisation wants its agents to have.

Shared AI serving gets operational controls

There's another kind of boundary to manage when several workloads share the machines running a model.

The llm-d project released version one point zero on 20 October, adding multi-tenant traffic controls, router high availability and coordinated upgrades for distributed model serving. This is infrastructure for teams running models on Kubernetes, the platform used to manage containerised applications.

Multi-tenant means different users or workloads are sharing the service. That creates a familiar problem: one customer or application sends a burst of requests, while everyone else still expects a response. A server's ability to process a large amount of work says relatively little about how fairly that capacity gets divided during a busy period.

The new priority and fairness controls can queue excess requests or shed them. Queuing makes work wait for capacity. Shedding declines work the service can't accommodate under its configured policy. Both give operators a way to manage demand before one tenant's burst overwhelms other workloads.

There's a consequential default here. Traffic remains first-come-first-served until operators configure the new multi-tenant policies. Installing the release gives them the mechanisms; deciding which workloads get priority and how excess demand is treated remains an operating decision.

For example, an organisation sharing infrastructure between several applications has to decide what happens when they all become busy together. A fairness policy can protect each workload's access to capacity. A priority policy can favour work the organisation considers more important. Those are different goals, and the configuration expresses the choice.

The release also adds router hot standby and coordinated updates across separate model-processing stages. The router directs requests through the serving system. A standby addresses router failure, while coordinated updates address the difficulty of changing a service whose processing is distributed across multiple parts.

For organisations hosting their own models, I think predictable behaviour under load is the most useful part of this release. A customer experiences the wait, the rejected request or the interruption during maintenance. These controls give operators more influence over those experiences. The practical work is choosing policies that match the service they've promised and operating the system accordingly.

Dagger sharpens test feedback for agents

Back at the developer's desk, a coding agent's next useful clue may be the name of one failed test.

Dagger's one point zero beta arrived on 22 October, followed by its explanatory launch post on 23 October. The release adds test-level reporting, maintained tool integrations and workspaces for running development and continuous-integration checks.

The specific change for coding-agent workflows is that official modules can identify and report individual tests. A failed test can then be rerun separately. That gives a developer or agent a smaller, clearer piece of feedback to work from after a change.

A check reported only as a failed job leaves the next step fairly open. The person investigating has to find the relevant failure inside that job's output. Identifying the individual test makes the starting point more precise: this behaviour was checked, and this particular check failed. The agent can use that information when deciding what to inspect or change.

A separate rerun also narrows the immediate feedback loop. After making a correction, the developer can check the affected behaviour directly. Wider checks still answer wider questions about the change. The benefit is having a useful unit of work during investigation, when repeatedly running everything can make each attempt slower to evaluate.

Dagger's workspaces and maintained integrations are intended to support checks across development and continuous-integration environments. CI is the automated checking that runs as code moves through a project's delivery process. Making a check reproducible in both places helps the developer connect a failure in automation with something they can investigate in their working environment.

Existing Dagger users have migration work to account for. This release is beta, some commands change meaning or disappear, and workspace and module configuration move into separate files. Those changes can affect scripts that already run reliably, so adoption involves reviewing the existing automation.

My read is that more precise feedback is becoming increasingly valuable as agents generate more code. A named failing test gives the next attempt a concrete target and gives the developer a clearer basis for judging the result. For a repository with substantial existing Dagger automation, the immediate calculation includes the migration effort needed to get that tighter loop.

US investment controls enter rulemaking

For technology businesses raising money, the next change is in the proposed rules around who can invest.

A US Treasury proposal announced on 22 October was published in the Federal Register on 26 October. It sets out an expansion of outbound technology-investment controls under the Comprehensive Outbound Investment National Security Act, known as the COINS Act.

The proposal concerns specified transactions by US persons involving covered foreign entities. Some activities would carry notification requirements; others would be prohibited. Its technology scope includes AI, semiconductors and quantum technologies, along with high-performance computing, hypersonic systems and biotechnology.

For a technology investor, that creates several questions around the same deal. Who is making the investment? What entity receives it? Which technology activities does that entity carry out? The proposed framework makes the relationship between those answers important to how a transaction is treated.

A notification requirement and a prohibition also lead to different decisions. One requires reporting a covered activity; the other prevents a covered transaction from proceeding. Understanding which category applies depends on the proposal's definitions and the details of the investment. The broad label of an AI business isn't enough to describe that relationship.

Comments close on 7 December 2026, and final regulations would establish the new programme's effective date. This publication is the proposed rule, so the new prohibitions described in it are not yet in force. Scope, exceptions and commencement remain part of the rulemaking process.

That gives US-linked investors and companies a published text against which to assess planned transactions while the rules are being developed. For a business preparing to raise capital, the relevant detail may sit in the ownership and transaction structure as well as in the product it sells.

The commercial consequence I see is more work connecting technical descriptions with financing decisions. An investor needs to understand what a company does at a level that maps to the proposed categories. A founder may need to explain the same technology differently to an investment partner and to a potential customer. Those definitions can affect which funding arrangements remain available as the proposal moves towards a final rule.

Anthropic opens its financial books

There's a more immediate view of AI financing in Anthropic's newly public stock-market filing.

On 26 October, Anthropic filed an S-1 registration statement for a proposed US initial public offering. It intends to list on Nasdaq under the ticker ANT. The size of the offering and its price range haven't been determined.

The Associated Press reports first-half revenue above sixteen billion US dollars and a net loss of eighty point seven billion US dollars. Within that loss is a seventy-two point four billion dollar financing-related accounting charge. That charge is essential to understanding the headline number.

A net-loss figure that includes such a large accounting item gives an incomplete picture of the cash consumed by day-to-day operations. It would take more detail about cash flows and the rest of the accounts to describe that spending properly. The useful development for customers and partners is the greater financial visibility created by a public filing.

For organisations building around Anthropic's products, that visibility offers more substance for assessing a long-term supplier relationship. They can examine financial information alongside the capabilities they're buying and the commercial terms they're offered.

The offering's timing, proceeds and valuation remain unsettled. At this stage, my interest is in what the filing makes possible to examine: how a major AI supplier's revenue, financing and financial commitments fit together.

AI-generated research gets academic examination

A very different kind of AI result has landed in front of academic researchers.

OpenAI published new AI-generated mathematical and computer-science research on 26 October and announced collaborations with academic researchers. Among the results is a claimed refutation of the Exponential Time Hypothesis, a hypothesis about the difficulty of certain computational problems.

OpenAI says that result was generated on 16 October and formalised in Lean on 17 October. Lean is a system for expressing and checking mathematical proofs. The company names Russell Impagliazzo, Ramamohan Paturi and Ryan Williams as leaders of the group examining and explaining the result.

The academic work is particularly interesting because a result of this kind needs interpretation as well as examination. Researchers want to understand what the argument establishes, which assumptions it uses and what follows from it. A formal expression of an argument can support that work; explaining its significance makes it useful to a wider research community.

The immediate output for other researchers is material they can examine. OpenAI also says that translating the theoretical result into practical algorithmic improvements requires further research. Developers therefore have no established practical speed-up from this announcement to adopt today.

I find the collaboration the most useful development here. It creates a path from an AI-generated candidate result to detailed examination by people working in the field. The eventual value could include a better understanding of computational limits, even before anyone has software that runs a familiar task faster. For builders, a concrete algorithm with demonstrated practical advantages would be the next development that changes an engineering choice.

What Changes for You

If your work involves reading documents or navigating screens with AI, there's a cheaper model option available now.

OpenAI released GPT-6.1 Terra on 26 October for visual reasoning, computer use and writing. It's available in ChatGPT Work and Codex for Plus, Pro, Enterprise and Edu users, and developers can access it through the API.

Standard API pricing is one US dollar per million input tokens and five US dollars per million output tokens. That's half the standard prices of GPT-5.6 Terra and GPT-6.1 Sol. Tokens are the units used to meter the model's input and generated output. For repeated document or screen-based work, that lower rate changes the cost of each model interaction.

Terra accepts text and images. It doesn't directly accept audio or video, and API tool calling requires the Responses API. That last point affects how a developer connects the model to tools used in a workflow. Eligible subscribers can select it in the supported products without building that integration themselves.

There are two pricing details worth carrying into a comparison. Requests above two hundred and seventy-two thousand input tokens attract higher rates across the entire request. Tool charges and premium processing options can also add to the bill. A large document-heavy workflow may therefore land in a different pricing bracket from a shorter task.

For developers already paying to run these workflows repeatedly, I'd compare the cost of a correctly completed job. That includes the model interactions, any retries and the tools used along the way. A lower token rate gives Terra a useful starting advantage; the number of interactions needed to finish the work determines how much of that advantage reaches the final bill.