The Australian Government AI Technical Standard: a security engineer's reading

Most commentary on the Australian Government's AI Technical Standard has come from policy people, which is fair enough, since it is a policy instrument. But the standard is ultimately a set of technical expectations that some engineer, somewhere, has to implement and some assessor has to verify. Read from that seat, it is a more interesting document than its press coverage suggests, and in a few places a more demanding one.

The standard sits inside the Commonwealth's broader responsible-AI machinery. The DTA's Policy for the responsible use of AI in government (now at v2.0) supplies the governance: accountable officials, transparency statements, AI Impact Assessments. The Technical Standard supplies the layer beneath that, the security, testing, monitoring, transparency and data expectations for AI systems in government use. If you sell AI-enabled anything into the Commonwealth, or you are an agency deploying it, this is the baseline your system will be judged against.

What strikes a security engineer on a close read is how much of the standard is only satisfiable with evidence. It is easy to assert that a system resists misuse, that guardrails work, that outputs are monitored for drift and harm. It is harder to show it, and the standard keeps asking you to show it. That is the right instinct, because assurance without testing is an opinion, but it means agencies and vendors need adversarial testing and structured evaluation in their delivery pipelines rather than as a one-off before go-live.

This post walks the standard's requirements from an offensive-security perspective: which clauses are trivially met, which quietly require real engineering, where an LLM penetration test or red team is the only honest way to evidence compliance, and the gaps we would test first if your system landed on Ironbark Cyber's bench.

Where does the Technical Standard sit?

It is easy to conflate the instruments, so it is worth separating them. The DTA Policy for the responsible use of AI in government is the governance layer: it requires agencies to name accountable officials, publish transparency statements about their AI use, and complete AI Impact Assessments for the systems that warrant them. The AI Technical Standard is the engineering layer beneath it, the technical expectations a government AI system is measured against across themes like security, testing and evaluation, transparency, monitoring and logging, accountability and governance, and data governance.

Think of the policy as "who is responsible and what have you told people," and the standard as "and here is how the system must behave." A vendor or agency needs both, and (this is the part teams underestimate) the standard's themes are where the real technical work hides.

Which expectations quietly require real engineering?

Read theme by theme, the standard sorts roughly into requirements you can meet with process and requirements you can only meet by building and proving something. The governance and transparency themes are largely satisfiable with documentation done honestly. The security, testing and monitoring themes are not.

• Security. Resisting misuse and adversarial input is not a checkbox. It is the outcome of testing and hardening. For an LLM system it means prompt injection, data exfiltration, tool and agent abuse, and output-handling flaws are addressed rather than merely disclaimed.
• Testing and evaluation. "Evaluated for accuracy, robustness and safety" implies a structured evaluation harness and adversarial testing, with results you can show. A single pre-launch demo does not meet the spirit of it.
• Monitoring and logging. Detecting drift, misuse and harmful outputs in production requires telemetry that most AI features ship without. If you cannot see what the model is doing, you cannot evidence that you are monitoring it.

The evidence problem

The recurring theme, the one a security engineer notices immediately, is that a large share of the standard cannot be satisfied by a document. You can write that your guardrails resist misuse; an assessor can reasonably ask you to prove it. You can state that outputs are monitored for harm; the follow-up is "show me the logs and the alerts." This is the standard doing its job, pushing agencies and vendors away from assurance theatre and toward demonstrable behaviour.

The practical consequence is that adversarial testing stops being optional. Where a requirement is about how the system behaves under attack or edge conditions, the honest way to evidence it is to attack it and record what happened. A policy paragraph is not evidence; a findings report with reproduction steps and a retest is.

What should "testing" mean for a government AI system?

It should mean more than a scanner, and more than a one-off. For a government AI system, testing should combine a structured evaluation of accuracy and robustness with real adversarial testing: an LLM penetration test for a specific application, or objective-driven red teaming where the concern is whether a motivated adversary could achieve a harmful objective against the system as deployed. Both produce the kind of evidence the standard's security and testing themes ask for, mapped to recognised references like the OWASP Top 10 for LLM Applications and MITRE ATLAS so an assessor can follow the reasoning.

It should also be repeatable. AI systems change as models are updated, prompts are tuned and data shifts, so evidence has a shelf life. Testing belongs in the delivery pipeline, not only in the week before go-live.

Reading it as a vendor versus as an agency

The obligations land differently depending on which seat you are in. An agency owns the whole picture: the impact assessment, the transparency statement, the accountable official, and the assurance that the system it deploys behaves as the standard expects, including systems it buys. A vendor selling into the Commonwealth needs to make the agency's compliance easy, and arriving with evidence that the security, testing and monitoring themes are already met is a competitive advantage, because it removes work and risk from the buyer. Either way, the party that can show its testing wins.

How does it interact with the ISM, PSPF and IRAP?

The AI Technical Standard does not replace the Commonwealth's existing security machinery. It layers on top of it. The ISM and PSPF still govern the security of the system and the environment it runs in, and IRAP assessment still applies where the system handles sensitive or classified information. What the AI standard adds is the AI-specific behaviour layer: a system can be ISM-aligned and IRAP-assessed and still fail the AI standard if its model can be trivially steered into leaking data or taking unauthorised actions. For agencies, the cleanest approach is to fold AI-specific testing into the same assurance cycle as their ISM and IRAP-readiness work rather than running it separately.

The first five things we would test

1. Prompt injection to action. Can untrusted input (documents, tickets, web content) steer the system into a consequential action or disclosure?
2. Cross-tenant and data-boundary leakage. Can one user or context reach data they should not, through the retrieval layer or shared state?
3. Guardrail bypass that matters. Not whether it will say something rude, but whether it will approve the thing, leak the record, or execute the action.
4. Output handling. Where downstream systems trust model output, what injection or SSRF does that open?
5. Monitoring efficacy. If we do all of the above, does anything detect it? A control you cannot see working is a control you cannot evidence.

The Australian Government's AI Technical Standard rewards organisations that were already doing the engineering and punishes those hoping to document their way through. Read as an offensive-security practitioner, it is a reasonable and testable set of expectations, which is why the honest path to meeting it runs through adversarial testing. Ironbark Cyber works with agencies and their suppliers to turn the standard's "show me" requirements into evidence that stands up, rather than assurances that do not.