sovereign-ai ·ism ·asd ·supply-chain

What The ASD Asked. What We Built.

The Australian Signals Directorate published its AI cyber defence brief this week. Every recommendation in it lines up with the way we've been building Quant from the start.

Stuart Rowlands 29 May 2026 9 min read

Australian AI grew up this week. The ASD just wrote the brief. We’ve been building it.

Preamble

The Australian Signals Directorate published a piece this week called Opportunities for AI in cyber defence. It’s a guidance paper aimed at CISOs and senior security leaders. I read it on a Thursday morning over coffee. I stopped reading twice — once at how plainly the ASD has named the threat (“malicious actors are using AI to deliver cyber threats at greater scale and speed”), said with the calm of a weather report. The second time because every recommendation in it lines up with the way we’ve been building Quant from the start.

We’ve been pointed this way since we founded Quant in 2019 — sovereign AU infrastructure, static-first attack-surface arguments, audit-everything as a posture. The AI work that addresses this specific brief has been our last two years. Seeing it become official ASD guidance changes the conversation.

Late May 2026 was when AI-for-cyber-defence stopped being a vendor’s slide and became official ASD guidance. That matters.

What’s actually new

The threat side first, because it’s shorter. Malicious actors are using frontier AI to industrialise reconnaissance, write evasive malware, and run social engineering at a scale that didn’t exist eighteen months ago. The ASD’s framing: “the time between vulnerability discovery and exploitation” is shrinking. The plain version: attackers are getting faster. You are not.

You can read entire books on what’s different. The short version is that less skill is now required to do more damage, faster, by more people.

The defender side is more interesting. The ASD lays out a spectrum, from “embedded AI features in security tools” through general-purpose LLMs to frontier models with agentic capability. It then maps AI use cases to each of the six ISM cyber security functions — Govern, Identify, Protect, Detect, Respond, Recover — and walks through what AI can do for you under each.

Some of it is familiar territory (AI-assisted alert triage, anomaly baselining). Some of it is genuinely sharp — AI identifying chains of low-severity findings that combine into real risk, the kind humans rarely have the patience for. And there’s an entire section called Supply chain, which we’ll come back to.

Sovereign isn’t a vibe

Read the ASD piece closely and a single theme runs through it under several names: control. Who can see your prompts; who logs your actions; who can pull the plug; whose laws apply when something goes wrong. The vendor-questions appendix asks the sovereignty question explicitly; the rest of the document is shot through with it.

Appendix A — “Cyber security questions for AI vendors” — eventually asks the question explicitly:

Which jurisdictions process or store customer data, including through third-party AI services?

This is the only question on that list where, if your answer involves a different country, you are quietly out of the running for the regulated buyer. The rest of the appendix is about explainability, oversight, traceability, supply chain. All important. But this one is decisive.

We were the first company through Australia’s new ISM controls for AI. Every prompt our customers send goes to Bedrock in Melbourne or Sydney, full stop. No third-party providers. No US-routed fallback. No “we cache in Singapore for performance.” It either happens here or it doesn’t happen.

Sovereignty cuts both ways: the data stays here, and so does the platform. Quant is Australian-owned and Australian-operated. QuantGov Cloud — the sovereign infrastructure layer underneath everything in this article — is administered exclusively by staff physically in Australia, subject to Australian law. No US-based SRE rotation poking at production. No follow-the-sun support chain routing a 3am incident through Manila or Bangalore. When something goes wrong at 3am, the people debugging it sit under the same legal jurisdiction as the data they’re touching.

I have been asked, more than once, why we bothered. Sovereign-AU was hard. It cost money. It cost speed-to-market. The honest answer is that I think the next decade of regulated AI procurement will hinge on this question, and not many will be able to answer it the way we can.

The ASD just made the question official.

Govern — the bit they put first

The ASD piece leads with Govern. Six ISM functions, but Govern comes first because the rest fall over without it.

If your AI sits inside your governance perimeter, your CISO needs to know — and prove — that they can lean on actual switches. Not “vendor cooperation in good faith.” Switches.

Quant ships them. Each org carries a master aiEnabled kill, a model allowlist (so a developer can’t quietly route a prompt through a model the policy says is off-limits), spend caps (daily, monthly, per user, with warning thresholds), and a mandatory guardrail preset that every request is forced through. The presets are named for the Australian government’s own Protective Security Policy Framework — OFFICIAL, OFFICIAL:Sensitive, PROTECTED. Pick one for your org, and every prompt and output is filtered against it, including AU-specific PII like Tax File Numbers and Medicare numbers with checksum-grade detection. Not generic NER. The actual numbers, properly verified.

The audit log sits in Australia, written to S3 with Object Lock in COMPLIANCE mode. Compliance mode is the strictest setting AWS offers — write-once, read-many, immutable. Not even AWS root can delete the records inside the retention window. That’s the immutable evidence pack the ISM has been asking for.

Code, agentic, and the question of trust

The ASD has a whole section on agentic AI — systems that don’t just answer prompts but plan, decide, take actions. They define it carefully and then immediately warn about it. The key sentences:

Limit autonomous actions to those that are narrowly scoped, preapproved and reversible. Use human-in-the-loop approval for high-impact or state-changing actions.

— ASD — Opportunities for AI in cyber defence, May 2026

That’s the line I’ve been holding since we founded Quant. It’s the entire design philosophy behind the autonomous coding agents we ship.

Take the supply-chain agent we run for customers — it audits a repo for CVEs and pinning gaps, then optionally opens a PR fixing the pinning. Default-off. Read-only against your code unless you say otherwise. When it does open a fix PR, the scope is strictly pinning — no version bumps, no adjacent edits. The PR is Remediates #N-linked to the audit issue. It is never auto-merged. A human reviews and merges.

There’s a thing we built in called the honesty rule: if the agent can’t resolve a tag-to-SHA from a primary authority — the action repo’s git/refs/tags/<tag> endpoint for GitHub Actions, the Docker registry digest API for images — it omits that line from the PR. The unpinned warning still appears in the audit issue. We just don’t guess. The honesty rule is our take on the ASD’s principle: don’t let your agent make stuff up.

For chat — including Slack — there’s a propose-then-confirm flow. “Resolve the pinning in quantcdn/foo is a perfectly reasonable thing to type, and the agent will investigate, produce a plan, cite each authority, and then stop. Ask you to confirm. Only on explicit yes does it dispatch the work.

Narrowly scoped. Preapproved. Reversible. Human-in-the-loop.

We shipped the first version of this against a real customer repo two days ago. It opened a real PR pinning four GitHub Actions to authoritatively-resolved SHAs. We sent the PR URL back to Slack and went and made tea. The PR is still sitting there waiting for a human to merge it. Which is exactly the point.

customer-org/internal-portal · #2

fix: pin supply-chain dependencies #2

Open quantcode-agent wants to merge into main from supply-chain/remediate-pin-1

Summary

  • Supply-chain audit completed (osv-scanner + npm audit)
  • Remediation patch provided for pinning 5 GitHub Actions to immutable commit SHAs
  • Full scan results in .supply-chain/ for audit trail

Unpinned GitHub Actions (Remediation in this PR)

LineActionCurrent RefPinned To
24actions/checkout@v4@11bd71901bbe… (v4.2.2)
27actions/setup-node@v4@49933ea52888… (v4.4.0)
39actions/cache@v5@27d5ce7f107f… (v5.0.5)
45quantcdn/deploy-action@v6@d25293fb60ff… (v6.1.0)
55quantcdn/purge-action@v6@9bab37759d3c… (v6.0.1)

Every to_sha resolved live during the run against the action repo’s git/refs/tags/<tag> endpoint. None were guessed.

Anonymised structural recreation of a real PR opened by the Quant supply-chain agent on 29 May 2026. Org and repo names redacted; structure, title, branch and pin contents are verbatim.

Supply chain — the bit they spend the most ink on

The Supply chain section of the ASD piece is interesting because it doesn’t read like an aspiration. It reads like a description of something they’ve already decided is going to happen. It lists what a supply-chain risk management programme for AI should do:

  • Maintain visibility across components (SBOMs, AIBOMs, third-party services).
  • Assess AI-specific supply chain risks.
  • Integrate supply chain into incident response.
  • Conduct due diligence on AI vendors.
  • Understand how data is accessed across the chain.

If you’ve ever run a Dependabot or Renovate stream and tried to keep up, the ASD’s checklist will read as familiar territory. Yes, you know what to do. Knowing has never been the problem. Finding the budget, the discipline, and the operational headroom to actually do it — consistently, on every repo, every week, forever — that’s been the problem. So: who does the work?

Our answer is a specialist agent that does real research on every dependency PR. It pulls CVSS scores, but also fetches the upstream registry to check whether a release is less than five days old (the prime supply-chain-attack window), web-searches for compromise reports, greps the repo to see if a dependency is actually in the prod request path or just a dev tool, and always — always — reports floating Action refs and unpinned image tags. It self-filters: it reviews only dep PRs, no spam on application PRs. Where Essential Eight ML2 thresholds apply, it calls out blockers with the 48-hour patch window in plain English.

The same run found 6 HIGH-severity CVEs alongside the pinning gaps, including a CVSS 9.1. The fifth Action pin couldn’t be applied because the GitHub App installation lacked the workflows: write scope, so the agent produced a patch file instead and embedded the apply command in the PR body. Graceful degradation. The honesty rule, again.

That’s the software supply chain — dependencies, CI/CD, container images, package registries. There’s another supply chain less directly named in the brief: the third-party scripts your end-users load in their browsers. Analytics tags, payment SDKs, font loaders, tag managers. Each is code from a domain you don’t own, executing inside the context of your site. We ship a product for that one too — ScriptAttest generates automatic Content Security Policy from observed traffic, then attests script integrity at load time. If a trusted vendor gets compromised and starts serving different bytes, it sees the change and blocks. Different layer of supply chain. Same thesis.

ISM, encoded

The ASD’s AI guidance sits on top of the ISM. The ISM is a moving target — the controls evolve as the threat surface evolves. That’s a feature, not a bug.

We didn’t summarise it. We didn’t paraphrase it. We embedded it. The current ISM ships as part of every specialist agent’s working knowledge — not a static checklist someone hand-wrote a year ago that nobody updated, but a living set of controls that gets updated when the ISM does. When the security agent flags an auth flow as failing the relevant control, it cites the control because the control is in its prompt. When the ISM publishes a revision, our skills publish one too. Same for the Essential Eight, WCAG 2.2 AA, and the Australian Privacy Principles — encoded, not appendixed.

That posture matters more than any single control. We’ve been treating the ISM as ground truth since we founded Quant in 2019 — long before this week’s brief — and we’ll keep doing it as the ISM evolves and the next brief comes around.

Same idea, new surface

I wrote a piece five years ago called Back To The Static — the argument was that the web had gone off in search of dynamic-everything and got too complicated, too expensive, and too vulnerable, and that the right move was to collapse the surface back down. Static where you can, dynamic where you must.

The same idea applies to AI. We’ve spent two years watching enterprise AI strategies sprawl across half a dozen US-based providers, with prompts and customer data spraying across jurisdictions, audit logs in three places (or nowhere), and “governance” implemented as a Slack channel where someone occasionally posts an OpenAI status page link. The result is identical to what the dynamic-web era produced: more complex, more expensive, more prone to break, harder to defend.

The collapse-the-surface move for AI is sovereign. One provider, in your country, on your audit log, with your humans on the off-ramp.

This is not nostalgia and it is not a “back to basics” pitch. The same way Back To The Static wasn’t “FTP your HTML up again.” It’s the same first-principles move applied to a new surface: minimise the attack surface, own the trust boundary, know where your stuff is, and put humans back in the loop where it counts.

The ASD just spent eighty careful pages on this. We were already running the platform that meets it. Now they line up.

AI is one layer

This piece has been about the AI platform. It’s what the ASD just put on paper, and it’s where the conversation has shifted this week. But it would be misleading to write all of this without acknowledging that the AI work sits on top of the rest of what we ship.

Static-first hosting, edge CDN, WAF. The Back-To-The-Static thesis is still what we sell. Static origins, edge cache, signed deploys, no dynamic backend to compromise. Attack surface collapsed before any AI even gets involved. The ASD asks for “minimising attack surface” across multiple sections of the brief; this is what that looks like in production.

ScriptAttest. Client-side supply chain, complementing the dependency agent above. Automatic CSP generated from real traffic, runtime attestation of every loaded script. The half of the supply chain that lives in your end users’ browsers, where most platforms have a blind spot.

Quant Sentinel. AI pentesting. The ASD piece has a callout titled “Red team scenario: AI-driven attack path analysis”“AI identifies how multiple low- and medium-severity weaknesses can combine into meaningful attack paths that would be difficult and time-consuming for humans to detect manually.” That’s Sentinel verbatim. The thing the brief describes as a scenario in a box — we ship it as a product.

QuantCode. The autonomous coding agents the rest of this article has been talking about. Sits on top of the AI platform; powered by it.

Five products. One platform. All on AU-sovereign infrastructure. The AI work is the newest part of it — and the part the ASD just made official this week. It isn’t the whole answer. It’s the part of the answer everyone is suddenly asking about.

What we built

Quant is the AU-sovereign AI platform: one provider (us), AWS Bedrock in Melbourne and Sydney, IRAP-assessed, first through the new ISM controls for AI in Australia.

What ships with it: nine pre-built specialist agents (code, plan, security, review, debug, supply-chain, two orchestrators, a GitHub-ops agent), thirty-plus models in the catalogue, thirty-plus built-in tools, and a living skills library — current ISM, Essential Eight, WCAG 2.2 AA, Australian Privacy Principles — that updates as those standards evolve.

What orgs build on top of it: their own custom agents (overlay one of ours, or build from scratch — your system prompt, your model, your tools, your skills, your knowledge base), their own callable tools (edge functions hosted by us — a meta-tool can design and deploy the next tool for you), their own skills, their own filter policies for word and topic redaction, and per-org vector-database collections for RAG without bringing in a separate vendor.

A visual workflow editor wires agents, tools, and autonomous jobs into repeatable processes — webhook and scheduled triggers, variable interpolation between steps, draft-and-revision history. It’s the mechanism for keeping AI on rails: define the process once, run it the same way every time, audit every execution.

Reachable from: a dashboard chat, the QuantCode terminal client, multiple Slack bots (each bindable to different agents for different teams), a CI workflow, our REST API, an open-source TypeScript SDK, and a Terraform/Pulumi provider for orgs managing Quant as part of their existing infrastructure-as-code.

Defence in depth at the content layer: three Bedrock guardrail presets — OFFICIAL, OFFICIAL:Sensitive, PROTECTED — sit at the model layer; streaming output redaction runs as tokens arrive; custom filter policies sit post-inference. Three layers, pick your risk tolerance. An autonomous container runtime handles the long-running jobs that need to clone, edit, test, and push — like the supply-chain remediation PR earlier in this article.

Everything — every prompt, every tool call, every workflow execution, every autonomous job, every PR action — lands in that immutable WORM audit log. Your security team gets the evidence pack without having to ask anyone for it.

The ASD piece is at cyber.gov.au. Worth reading in full.

They’ve set the bar — buyers know what to ask, suppliers know what to build, auditors know what to test against. The future of AI in Australian government is sovereign, audited, scoped, reversible. We’re already there.

Share

Share:
More articles