Astra Crosses the Cyber Threshold as AI Control Moves Into the Product

Astra Crosses the Cyber Threshold

A forthcoming AI model found two previously unknown software vulnerabilities and used them in an exploit chain. Its creator responded by slowing development and restricting who’ll receive the strongest version.

That’s why OpenAI’s classification of Astra deserves a closer look. The company says this is its first model to reach the Critical cybersecurity threshold in its Preparedness Framework, a line intended to mark a serious change in what a model can do with computers and networks.

OpenAI defines that threshold quite specifically. With suitable tools and access, a model at this level can find unknown flaws and develop exploits against many hardened systems without a person guiding it step by step. This isn’t merely producing plausible-looking code or explaining a known vulnerability. The claim is that Astra can carry out substantial parts of original vulnerability research and exploitation with greater independence.

The threshold describes capability under enabling conditions, not something every user can reproduce from an ordinary chat window. Tools, system access and the configuration supplied by OpenAI all affect what the model can accomplish. That distinction helps explain why the release plan focuses so heavily on capability tiers rather than treating Astra as a single identical product for everyone.

The strongest evidence OpenAI has disclosed is its own testing. Astra reportedly discovered two previously unknown vulnerabilities and combined them in an exploit chain. OpenAI says disclosure to the relevant maintainers is under way. That’s a consequential result, but the limits around the evidence matter: Astra isn’t generally available, its system card hasn’t been published, and independent researchers haven’t yet tested the model in production. For now, both the capability assessment and the effectiveness of the safeguards are primarily company-reported.

OpenAI says it delayed parts of Astra’s development and release while adding protections. The most advanced cybersecurity capabilities are initially going to a small group, with broader access managed through a program called Daybreak Blue. Most users are expected to receive a more restricted configuration. Monitoring can cause the system to pause or stop work when activity is flagged as risky.

There’s an obvious defensive opportunity here. A model that can locate difficult vulnerabilities may help security teams find weaknesses before attackers do, particularly across large codebases and complex systems where human attention is scarce. But the same capability makes a simple all-or-nothing release increasingly difficult to justify. Access level, tool permissions, monitoring and intervention become part of the product itself.

For organisations, my read is that frontier-model governance is moving into architecture and operations. Approving a model from a policy document and treating every deployment identically no longer fits the technology. The important operational details are the capability tier being supplied, the tools within reach, the monitoring that remains active and what happens when the system interrupts a task. Developers also benefit from knowing whether an apparently failed run reflects a technical fault or a safeguard doing exactly what it was designed to do.

Astra could eventually make serious vulnerability discovery more accessible to defenders. It also shows why the most capable models may arrive through graduated access, constrained tools and active supervision rather than one uniform public release.

Australia’s Privacy Rights Proposal

The model lab isn’t the only place where control is being redrawn. In Australia, the immediate question is who gets a say over personal data.

The Australian Government released exposure-draft privacy legislation on 31 August, with consultation open until 18 September 2026. The proposal addresses data practices that have expanded alongside AI systems, connected devices and large digital platforms. It isn’t law, and its final wording, commencement dates and parliamentary prospects may all change.

One proposed measure is a fair-and-reasonable test for collecting and using personal information. That could require organisations to justify a data practice as more than something disclosed deep in a privacy notice. The draft also proposes stronger consent standards and a right to ask large digital platforms to erase personal information.

Another provision would restrict businesses from trading information such as a person’s location, shopping habits or online interests without clear permission. Those categories can be especially revealing when combined, even if each individual data point seems ordinary. They can shape advertising, pricing, recommendations and automated assessments without the person seeing the underlying profile.

The combination of these proposals is significant. Stronger consent concerns the point at which permission is obtained, while a fairness test examines the collection or use itself. An erasure request then reaches what happens after data has already entered a platform. That gives the draft a wider scope than a single change to privacy notices.

For Australians, the potential gain is more practical control over where personal information travels and whether it remains on major platforms. The important word is potential. Nobody has acquired a new erasure right from this announcement, and businesses don’t yet face a new legal duty under the draft.

Organisations handling Australian data do have a near-term decision. They can use the consultation period to map where information is collected, inferred, shared and sold, then test how the proposed consent and fairness standards would affect those flows. That work may expose gaps before the legislation is settled, particularly where data gathered for one purpose is later reused for analytics or AI.

My assessment is that stronger limits could improve individual control while creating substantial implementation work behind the scenes. Consent screens alone won’t solve it. The proposal points towards better data inventories, workable deletion pathways and records showing why a particular use was considered reasonable. The consultation is therefore more than a legal drafting exercise; it’s an early view of the operational systems businesses may face if the reforms survive.

ChatGPT Connects to Epic Records

Here’s a more contained example of access controls shaping whether an AI feature is useful or unsafe.

OpenAI has launched a connection between approved ChatGPT workspaces and Epic electronic health records. It’s available to approved ChatGPT for Healthcare customers and eligible enterprise workspaces, alongside a separate Healthcare Public Data plugin. The integration can also be used from Codex where the organisation has enabled it.

The Epic connection is deliberately read-only. It can retrieve information a user is already authorised to see, but it can’t change the patient record, place an order or override the clinician’s existing chart permissions. Access requires an approved organisational workspace, administrator configuration, individual authentication to Epic and the appropriate agreements. It isn’t available to individual ChatGPT for Clinicians accounts.

That distinction is important. A clinician asking for help synthesising a long chart is very different from allowing a model to write into the record or initiate treatment. Keeping the first release read-only limits the possible actions while still placing sensitive clinical context close to the model.

The separate public-data plugin searches nine official sources. They cover areas including research, clinical trials, medicines, Medicare information and provider records. That gives healthcare teams a route to current reference material without treating a general web search as equivalent to an approved clinical source.

These are two different information boundaries inside the same workspace. The Epic connection follows the clinician’s existing access to patient records. The public-data plugin searches approved external sources. Keeping those paths distinct may make it easier to understand whether an answer came from a patient chart, public reference material or a combination of both.

For hospitals and other healthcare organisations, this may reduce the time spent gathering patient context and checking separate public databases. Clinical review remains essential. OpenAI reports favourable controlled evaluations, but the briefing doesn’t include independent evidence about real-world clinical outcomes or error rates.

The practical challenge shifts towards institutional design: which workspaces are approved, which users have access, what the audit trail shows, and how staff verify the resulting synthesis. A read-only connection narrows the danger, but it doesn’t make an incorrect summary harmless. Missing or misunderstood information can still affect a clinical decision.

My take is that this is a sensible boundary for bringing generative AI closer to health records. The immediate value is information synthesis, not autonomous care. The best results depend on permission design, traceability and human verification being treated as core clinical infrastructure rather than setup details.

Europe Funds LUMI-AI

Now zoom out from one organisation’s records to the physical infrastructure behind advanced AI.

The EuroHPC Joint Undertaking has signed a €387.8 million contract with Bull to deploy the LUMI-AI supercomputer in Finland. The acquisition, delivery, installation and maintenance budget is split equally between EuroHPC and a consortium of participating countries.

LUMI-AI is intended to become the computing backbone of the LUMI AI Factory. The planned system uses AMD Instinct MI430X accelerators and sixth-generation EPYC processors with 256 cores. EuroHPC projects that it can provide ten times the AI capacity of the current system and nearly twice its conventional high-performance-computing capacity.

Those are projections rather than delivered performance numbers. User access is planned for 2027, so the system doesn’t relieve current compute shortages. The delivery schedule, real performance and allocation pressure become clearer only after the machine is installed and researchers begin competing for time on it.

The intended users include European researchers, startups and smaller companies. That matters because access to large pools of accelerators can determine which experiments are even possible. A small team may have the expertise and data for ambitious model work but still be constrained by cloud cost, accelerator availability or procurement rules.

The funding arrangement also spreads the project across European and participating-country interests rather than leaving the entire acquisition with one institution. That can broaden the pool the machine is intended to serve. It can also make allocation demand especially important, because projected capacity says little about how much compute each eligible user can obtain in practice.

Publicly supported compute offers a different route. It can give qualified users access to infrastructure that would be difficult to buy independently, and it may support work that doesn’t fit the commercial priorities of a hyperscale cloud provider. Its value also depends on fair allocation, capable technical support and enough capacity to meet demand.

For European organisations, I’d treat LUMI-AI as a medium-term expansion of research options, not an immediate substitute for existing cloud or on-premises plans. The more interesting strategic point is that governments are treating shared AI compute as research infrastructure in its own right. If the project meets its schedule and capacity targets, advanced model development in Europe could depend a little less on whether an individual lab can secure a very large commercial cloud budget.

Microsoft Reworks Agent Governance

Compute gives an agent reach; permissions determine what it can do with that reach.

Microsoft’s third Responsible AI Transparency Report says the company has re-engineered its internal standard around models, platform services and applications, with added attention to agentic systems. The shift reflects a basic technical difference between a chatbot that returns text and an agent that can remember context, invoke tools and take actions across other systems.

The revised approach emphasises identities for agents, permissions for their tools, monitoring of their actions and controls that operate throughout the system lifecycle. Microsoft also described expanded evaluation and red-team tooling, including agent evaluators, RAMPART, ASSERT and an Agent Control Specification.

The names are less important than the operating model behind them. A pre-release assessment captures how a system behaves under a set of tests at a particular point in time. An agent’s risk also depends on what credentials it receives, which tools are connected, how its environment changes and whether operators can observe and interrupt its actions after deployment.

That lifecycle emphasis changes where teams look for failures. A model can perform acceptably in isolation while an application gives its agent excessive permissions or connects it to a risky action. Observation during operation can reveal those system-level problems, while intervention provides a way to limit the consequences after a problematic action begins.

Microsoft’s report doesn’t impose obligations on anyone else, and it’s a company-authored account of its own practices. The cited material doesn’t independently establish how mature or effective every control is. Still, it provides a concrete signal about where a large technology provider believes its internal governance is changing.

For organisations building agents, the useful takeaway is that an output policy isn’t a complete control system. The relevant questions include the identity under which an agent acts, the minimum permissions attached to that identity, which actions require confirmation and what evidence remains available for later review. Continuous evaluation becomes more valuable as tool access and application code change.

My judgment is that this makes agent deployments more operationally demanding, but also easier to reason about when something goes wrong. Runtime controls create places to contain an error instead of relying entirely on the model to avoid one. As agents move from answering questions to touching files, databases and business workflows, that containment becomes part of ordinary system engineering.

BigQuery Adds Native Graph Analytics

There’s also a quieter infrastructure release that could remove an entire data-system boundary for some teams.

Google Cloud has made BigQuery Graph generally available. It adds native graph analytics to BigQuery, allowing connected-data queries to run where relational data may already live. Graph Query Language, an ISO-standard language known as GQL, operates alongside SQL.

Graph analysis focuses on relationships: which accounts share identifiers, which services depend on one another, or which pieces of information connect to an entity an AI agent is investigating. Teams often move that data into a separate graph database, maintain another security model and build an ETL pipeline to keep both systems aligned. BigQuery Graph performs the traversal inside BigQuery instead.

The graph queries inherit BigQuery’s row- and column-level security. They can also call BigQuery ML and AI functions within the same query. For organisations already using the platform, that can simplify fraud analysis, dependency mapping and retrieval of connected context for agents.

Inherited security is more than a convenience here. Connected-data queries can reveal relationships that aren’t obvious in individual rows. Applying existing row and column controls inside BigQuery reduces the chance that a separate graph copy drifts away from the access rules already protecting the source data. It also removes one replication path that teams otherwise have to monitor.

There are boundaries to the announcement. The core graph engine is generally available, but Google says some surrounding agent-oriented capabilities remain in preview or are rolling out over the coming weeks. Performance claims and customer examples are vendor-provided, so results across different graph sizes, query shapes and latency targets remain an open question.

The trade-off includes BigQuery’s cost model and the deeper platform coupling created by consolidating relational, graph and AI workloads. Removing a separate database reduces data movement and operational overhead, but it can make a future move away from the cloud provider more involved.

My read is that BigQuery Graph is most compelling when the data, access policies and engineering skills are already in BigQuery. In that setting, native graph traversal may be cheaper and simpler than operating another specialised system. It’s less persuasive as a reason to migrate an established graph workload without first comparing query performance, cost and portability.

What Changes for You

Two changes land closer to day-to-day work, although each comes with a fairly firm boundary.

Anthropic released Claude Fable 5.1 on 1 September across its own services, major cloud platforms and the Claude API. Developers can use the claude-fable-5-1 model now. Input and output pricing remains US$10 and US$50 per million tokens, while cache reads have fallen to US$0.25 per million.

Anthropic estimates that typical token-billed workloads could cost about 25 per cent less, rising to 45 per cent for highly agentic workloads. Those are vendor estimates based on August usage. Measuring real prompts, cache behaviour and tool loops remains the reliable way to judge the saving for a particular application.

Fable can help find vulnerabilities, but penetration testing, exploit generation and binary vulnerability scanning remain redirected or restricted. Anthropic’s less constrained Mythos 5.1 uses the same underlying model but is limited to vetted cybersecurity and life-sciences programs. For working AI builders, the opportunity is a more capable generally available model with potentially cheaper context-heavy operation; the limitation is that access still depends on the task, not merely the API account.

For students and schools in New South Wales, the immediate change is assessment design. The state has set a limit of one take-home HSC assessment worth no more than 15 per cent of the school-based component, equivalent to 7.5 per cent of the total HSC result.

The rule applies to students beginning HSC studies in Term 4 of 2026 and Year 11 students starting in Term 1 of 2027. Examinations, oral tasks and process diaries remain available. HSC major works and some linked tasks are exempt, while further subject-specific guidance is still being developed.

Students can expect more marked work to happen under supervision or through formats that show how the work was produced. My assessment is that NSW is responding to unreliable AI-authorship detection by redesigning assessment itself. That may make results easier to authenticate, but it reduces some take-home flexibility and leaves schools with substantial course-planning work before the affected cohorts begin.