\n\n\n\n Two Gigawatts of Australian Compute and Nobody Asked Who Guards the Agents - BotSec \n

Two Gigawatts of Australian Compute and Nobody Asked Who Guards the Agents

📖 5 min read•842 words•Updated Sep 11, 2026

Picture a substation somewhere outside Melbourne at 3 a.m. The transformers are humming at a pitch that vibrates through the concrete pad. Inside the hall behind it, rack after rack of accelerators are running inference for workloads whose owners are asleep on four different continents. No human is in the building. The only things making decisions in that room are software agents: schedulers deciding which tenant gets which slice of silicon, orchestration bots pulling container images, autoscalers spinning capacity up and down based on queue depth. Every one of those agents is a machine identity with credentials, and every one of them is an attack surface.

That is the picture I keep coming back to after NVIDIA’s September 9, 2026 announcement from Melbourne, where the company said it is working with a growing group of Australian NVIDIA Cloud Partners and AI infrastructure partners to expand land, power and shell capacity. The named partners include Firmus, Sharon AI and NEXTDC, and the buildout runs up to 2 gigawatts by 2027. The stated goal is meeting AI compute demand.

Capacity announcements are security announcements in disguise

Press releases about gigawatts read like energy stories. They are actually stories about how many autonomous processes are about to come online, because compute that large does not get managed by hand. You cannot staff a 2GW footprint with humans clicking through consoles. It gets managed by control planes, agents, and API calls made by other agents.

My work at botsec.net centers on the security of AI bots and agents, so this is the part that grabs me. The industry conversation about a buildout this size tends to fixate on chips, power purchase agreements, and cooling. The quieter shift is in identity volume. Scale the physical layer by an order of magnitude and you scale the population of non-human identities right along with it: service accounts, workload identities, signing keys, API tokens, inter-service credentials. Human headcount grows slowly. Machine identity counts grow with the racks.

What worries me about multi-partner buildouts

The detail I find most interesting in the announcement is that this is an ecosystem play, not a single-operator project. Multiple named partners, each with their own operational practices, each contributing land, power and shell capacity. That structure has real advantages for speed. It also means the security model is federated by default, and federated security models fail at the seams.

The questions I would want answered, in order:

  • When an agent in one partner’s environment calls a service in another’s, what proves its identity, and how short-lived is that proof?
  • Who can enumerate the full set of machine identities across the ecosystem, and is that list generated or maintained by hand?
  • If a tenant workload compromises an orchestration agent, does the blast radius stop at one facility or travel across the shared control plane?
  • What does credential rotation look like when the credential holder is a container that lived for ninety seconds?
  • Are agent-to-agent calls logged with enough fidelity that you could reconstruct a decision chain after an incident?

I am not suggesting the partners have ignored any of this. I have no visibility into their internal controls, and the announcement does not discuss security posture. What I can say is that these are the questions that decide whether a large AI footprint is defensible, and they rarely appear in capacity announcements.

The threat model shifts from network to intent

Traditional data center security thinking is perimeter-shaped: segment the network, control physical access, patch the hypervisor. Those still matter. But when the workload is AI inference and the operators are agents, a meaningful class of attack stops looking like intrusion and starts looking like persuasion. Prompt injection against an agent with infrastructure permissions is not a content moderation problem. It is a privilege escalation problem wearing a friendly face. An agent that reads a log file, a support ticket, or a model output and then acts on instructions embedded there has just executed code supplied by an attacker, without a single exploit.

Scale makes this worse in a specific way. At small scale, a compromised agent gets noticed because someone recognizes that the behavior is odd. At 2GW, odd behavior is indistinguishable from normal variance unless you have built the baselines to tell the difference.

What I would want to see by 2027

Australia is getting serious sovereign AI capacity, and that is genuinely useful. Local compute means local data residency options, lower latency for the region, and less dependence on capacity decisions made elsewhere. I would like the security story to arrive on the same timeline as the concrete.

Concretely, that means treating agent identity as first-class infrastructure rather than a configuration afterthought. Short-lived credentials by default. Explicit allowlists for what each agent may call. Injection-resistant boundaries between untrusted content and agents holding permissions. Audit trails built for agent decision chains, not just human logins.

The buildout deadline is 2027. That is not much runway for retrofitting a security model, which is exactly why the design choices being made right now matter more than the gigawatt figure in the headline.

🕒 Published:

✍️
Written by Jake Chen

AI technology writer and researcher.

Learn more →
Browse Topics: AI Security | compliance | guardrails | safety | security
Scroll to Top