The AI Harness Becomes the Security Boundary

The Harness Is the Security Boundary

The dangerous part of an AI agent may not be the model at all. It may be the software around it that remembers, connects, grants permission and acts.

That’s the development worth spending time on today, because it changes where an organisation needs to look when an agent goes from answering questions to doing work. On 11 September, the Australian Signals Directorate published guidance focused on the agentic AI harness: the layer that supplies context and memory, connects a model to tools and data, enforces permissions, executes actions and coordinates the overall job.

The language is useful because people often talk about an agent as though the model is the whole system. It isn’t. A model might interpret the request, but the harness decides whether it can read a customer record, query an internal database, send a message, run code or change something in production. ASD’s point is that many of the highest-impact organisational risks come from those connections and permissions. The model can be capable and the surrounding system can still be dangerously loose.

Prompt injection is the clearest example. An attacker, or even an untrusted document, can place instructions in data the agent reads. ASD says there is no fully reliable mitigation at the model level. A clever system prompt cannot carry the entire security load. The controls have to extend through the harness, the connected systems and the organisation operating them.

That means strong identity controls and least privilege, so an agent gets only the access needed for its task. It means restricting tools and data, validating outputs before another system consumes them, and placing human approval around consequential actions. Logging and incident response matter as well, because an organisation needs to reconstruct what the agent saw, chose and did. ASD also recommends phased deployment rather than handing a new agent broad reach on day one.

There’s an important warning for anyone designing multi-agent workflows. For security purposes, ASD says to treat the group as one agent. If several agents share context or rely on one another’s output, a compromise can travel through those trust relationships. Splitting a workflow into five named agents doesn’t create five clean security boundaries.

That framing changes an audit from a model review into a system review. A security reviewer has to follow the path from identity to connector, from retrieved data to generated output, and from output to execution. A permission that looks narrow in one component may become powerful when another component can combine it with shared memory or a second tool.

My read is that the durable advantage here sits in a harness that remains well governed when the model changes. Models can be swapped, upgraded or routed according to the task. Permissions, approval gates, execution environments, connector design and audit history are the operating system around them. If that layer is weak, a more capable model can enlarge the liability because it becomes better at using the access it has been given.

This is advisory guidance, not a certification scheme or a mandatory standard. Its value depends on how carefully organisations implement and enforce it. But it gives security reviewers a practical question to ask now: not only what the model can say, but what the whole agent system can reach and cause.

A Digital Duty of Care

That’s the big structural shift. A proposed Australian law is applying similar scrutiny to the products people already use.

The Australian Government released an exposure draft of the Online Safety Amendment, or Digital Duty of Care, Bill on 8 September. It’s under consultation, so none of these measures is in force yet, and the text can still change.

One visible proposal concerns social feeds. Platforms would have to give users a choice between the personalised feed offered by default and a feed made from accounts they follow. That could give Australians a more direct way to step away from recommendation systems, although the available detail does not establish exactly how each service would implement the choice.

The proposal also reaches beyond social media. AI chatbots, apps and online games would be required to protect people under eighteen from specified harmful content and from design features with negative behavioural effects. Platforms would have to document their risk controls, creating an evidence trail for how they identify and reduce foreseeable harm. Proposed maximum penalties for duty-of-care breaches reach one hundred and nine point two million Australian dollars.

The consultation closes at noon on 22 September, and the government says it intends to introduce legislation in 2026. Until Parliament considers a bill, Australians do not have the proposed feed choice, and services do not yet face these new duties.

The notable policy change is the unit of scrutiny. Regulators have often been drawn into arguments over individual posts after harm occurs. The proposal looks more directly at product design: how a recommender selects content, how a chatbot interacts with a young person, and whether engagement features create predictable risks. That’s my interpretation of its significance, not a claim that the draft already settles those questions.

For digital services operating in Australia, the sensible preparation is concrete: map the recommender settings users can control, identify child-safety risks across chatbots and games, and make sure risk decisions can be evidenced. The final obligations are unknown, but organisations that cannot explain their present controls may find the compliance work much harder if the proposal becomes law.

Australia’s Two-Gigawatt AI Ambition

Now take that software layer and give it a physical footprint. Australia’s planned AI buildout is being measured in gigawatts.

NVIDIA announced collaborations with eight Australian cloud and data-centre partners on 9 September. The company says the projects could support up to two gigawatts of AI-related capacity by 2027. That is a ceiling for projects that might reach that scale. It is not two gigawatts already operating, a guaranteed construction schedule or proof of customer demand.

The division of work is also worth separating. The Australian providers are expected to operate the facilities. NVIDIA supplies its DSX platform, accelerated computing, networking, software and ecosystem support. The stated aim is to make more local computing capacity available to startups, universities, researchers, enterprises and developers. Delivery is therefore spread across partners and projects rather than resting on one newly commissioned national facility.

If the projects materialise, local capacity could make data residency and access to large AI systems easier for Australian organisations. It could also reduce some dependence on distant regions for workloads where latency, regulation or control over data location matters. None of that removes the ordinary difficulty of delivering a data centre. Sites need power, construction, networking, cooling, hardware procurement and enough paying work to justify the investment.

That is where I think the constraint starts to move. The early AI infrastructure conversation centred on whether organisations could get enough advanced chips. A buildout on this scale makes electricity, site delivery and utilisation just as important. Expensive accelerators sitting idle are not useful national capacity; they are expensive equipment in an expensive building.

For Australian buyers, the announcement is a reason to track which facilities actually reach commissioning and what services become available, not a reason to treat the headline number as present supply. Procurement teams still have to compare price, data location, workload portability and capacity guarantees. The strategic opportunity is real if delivery follows, but the two-gigawatt figure remains a forward-looking company target with utilisation and customer commitments still unproven.

Nine Billion DNA Variant Predictions

From data centres, let’s narrow the scale all the way down to a single letter of DNA. The search space is still enormous.

Google DeepMind released AlphaGenome Atlas on 8 September, providing precomputed predictions for the molecular effects of every possible single-letter change in the human genome. These changes are called single-nucleotide variants: one DNA letter differs at one position. The catalogue covers nine billion of them.

The practical attraction is that researchers do not have to run the model from scratch for every candidate. Academic researchers can access the atlas free through a website and an API, then use its predictions to help decide which variants deserve scarce laboratory time. A new Variant Impact score combines model predictions into a ranking signal for further investigation.

DeepMind also reports that collaborators experimentally validated a rare-disease splicing result identified with the system. Splicing is the process that edits an initial RNA copy into the instructions a cell uses, so a variant that disrupts it can alter the resulting biological product. The example shows the sort of lead the atlas can generate. It does not establish that every high-ranking prediction is correct, or that the system can diagnose disease.

The company is explicit about that boundary: the resource is not validated or approved for clinical use, and it is not medical advice. Diagnosis and treatment still depend on independent experimental and clinical validation. Broader performance across diseases and research settings also remains to be established outside the examples reported by DeepMind and its collaborators.

The useful interpretation is research triage. Nine billion possibilities are too many to investigate experimentally one by one. A credible prediction layer can narrow the list, help a scientist choose an assay and bring promising variants forward sooner. Research groups gain a map for deciding where to look; they do not gain an automated clinical verdict. That distinction is likely to determine whether tools like this save expert time without creating misplaced confidence.

Google Cloud Arrives as an Agent Plugin

A smaller release points to how developers may package all those agent connections without rebuilding them for every coding tool.

Google Cloud released its google-cloud-developer plugin on 10 September. It is an installable bundle of Cloud skills, operational guidance and access to current documentation for compatible AI coding agents. The package follows the open, vendor-neutral Agent Plugins specification, which provides a common way to distribute agent skills and Model Context Protocol servers. MCP is the connection layer an agent can use to reach tools or information through a defined interface.

The plugin includes guidance for authentication, authorisation and project management, along with guardrails for programmatic Cloud operations. It also carries configuration for Google’s Developer Knowledge MCP server, giving an agent a route to current official developer documentation rather than depending only on knowledge embedded during model training. That matters most when a service, command or permission has changed since the model was trained.

For a developer who uses more than one supported coding agent, the immediate benefit is less duplicated setup. One package can carry the Cloud-specific instructions and documentation connector that otherwise have to be maintained separately in each environment. Consistency is useful when an agent is generating commands, configuring a service or working out which identity can reach a resource.

The first release is described as foundational. It needs a compatible agent environment, and the developer still needs the right Google Cloud identities and permissions. Google’s launch material does not establish how reliably the package interoperates across different clients in production.

I’d treat the packaging standard as the interesting part. Portable plugins can reduce integration work and make capabilities easier to update. They do not make the resulting actions safe by default. The identity behind the agent, the scope of its access and the approval attached to a consequential Cloud change still determine what can go wrong. A neat installation format improves distribution; it does not replace operational control.

Adobe Commerce Patch Window Collapses

There’s also a security job that cannot wait for a longer strategy discussion. Adobe Commerce operators have an actively exploited flaw to handle.

Adobe released a priority-one hotfix on 7 September for CVE-2026-75650, affecting Adobe Commerce and Magento Open Source. The vulnerability can allow arbitrary code execution without authentication and carries a CVSS base score of ten point zero. Adobe has confirmed exploitation in the wild.

Affected releases include Adobe Commerce versions through the August 2026 builds and Magento Open Source through its August 2026 build of version two point four point nine. On 8 September, the US Cybersecurity and Infrastructure Security Agency added the vulnerability to its Known Exploited Vulnerabilities catalogue. Adobe has not said how broad the exploitation is or attributed the activity.

For operators, this is an immediate hotfix and investigation task. Applying the patch closes the known vulnerability, but confirmed exploitation means an internet-facing system may already have been targeted. Security staff need to examine affected environments for evidence of compromise, rather than recording the update as ordinary maintenance and moving on.

The judgement call is unusually straightforward. Unauthenticated remote-code execution gives an attacker a path to run code without first obtaining a user account, and active exploitation removes the comfort of a theoretical risk. The normal patch window has collapsed. Every extra delay extends direct operational exposure on systems running online commerce.

Cheaper ChatGPT Access for US Government

Cost can block adoption long before a model reaches a public servant’s desk. A new US agreement lowers that first barrier.

The US General Services Administration announced a twenty-seven-month procurement agreement on 10 September, expected to take effect on 1 October 2026. It offers eligible federal, state, local and tribal government bodies consumption-based access to qualifying ChatGPT models at a fifty per cent discount on token usage. Eligible offerings in FedRAMP-authorised environments are included.

There is no platform-access fee, minimum order or spending commitment. Participating bodies can buy directly, use resellers or procure through supported cloud marketplaces, with GSA AI terms and conditions incorporated into the arrangement. That structure lets an agency begin with actual usage costs rather than paying a fixed entry charge simply to gain access.

The deal is not active until 1 October, and its effect cannot be measured from the announcement. Uptake, realised savings and service outcomes remain unknown. It is also specific to eligible US government entities, so it is not a general price reduction for other organisations or individual ChatGPT users.

My reading is that this shifts the hard part of adoption. Lower cost and familiar procurement paths can make it easier for an agency to start. The tougher work then sits with authorisation, records, data handling, workforce training and deciding which tasks are appropriate. Cheap tokens do not resolve those questions; they make it more likely that agencies have to answer them in everyday use rather than in a procurement proposal.

What Changes for You

For builders, one release is available to test now, and it makes a familiar voice architecture much less cumbersome.

OpenAI made GPT-Live-1 available through its API on 10 September. It is a front-end voice model that can listen and speak at the same time, handle interruptions, and delegate deeper reasoning or tool use to a separate backend model and agent harness. Access starts at five US cents per minute for that voice layer.

The immediate audience is developers building phone, support and other conversational applications. A common voice front end chains speech-to-text, a language model and text-to-speech. OpenAI says GPT-Live-1 combines incoming and outgoing audio in one model, which can simplify that front part of the system and support more natural turn-taking. The API also supports telephony and prompt-controlled tone, pace and conversational style.

What becomes easier is prototyping a conversation that can cope with a person interrupting without assembling three separate voice components first. The limit is everything beyond that front end. The quoted price does not include the backend reasoning model or the harness. Developers still have to integrate those pieces, control tool permissions, plan escalation, protect private audio and budget for the full system. Custom voices require a separate eligibility process.

Performance claims currently come from OpenAI and early customers. Quality across accents, languages, noisy rooms and long production workloads has not been independently established. I’d evaluate the release on two separate axes: whether the conversation feels fluid, and whether the backend produces correct, appropriately controlled results. Better turn-taking can make a voice agent much more pleasant to use. It cannot make an unsafe action safe, which brings the practical decision straight back to the harness behind the voice.