The ASD just put AI prompt governance in writing. Here is what it expects of your CISO

For Chief Information Security Officers and senior security leaders

The Australian Signals Directorate has published Opportunities for AI in cyber defence (Commonwealth of Australia, 2026). Most of the paper is about defenders using AI inside the security operations centre for detection, response and recovery. That is not the part I want to focus on here.

The part that should change how you brief your board is smaller and more pointed. Under an Australian government masthead, the ASD has now told security leaders, in writing, to govern how their staff use AI, to stop sensitive data flowing to unapproved or consumer AI tools, to capture prompt-level telemetry, and to keep an auditable record of all of it. That is no longer a vendor talking point. It is national guidance written for your role.

I want to be honest about where this lands for us and where it does not, because the value of guidance like this comes from reading it straight.

What the ASD actually said

The guidance is explicit about governing the inputs to AI systems, not just the outputs. On data handling, it asks defenders to:

prevent the sharing of sensitive information with unapproved AI tools, including unmanaged or consumer AI services

and to:

define and enforce policies governing what data AI tools may access, how data may be used and where outputs may be transmitted

That second clause matters. It is not a request to write a policy. It is a request to enforce one, at the point where data is entered.

On visibility, the ASD asks defenders to:

detect AI misuse through AI-specific telemetry, such as model inputs (including prompt manipulation), decision traces, policy checks and confidence signals

On accountability, it asks you to:

ensure transparency and auditability, including the ability to explain inputs, authority and how outputs influenced decisions

And on control posture, it favours keeping a person in the loop, using:

human-in-the-loop approval for high impact or state-changing actions

while limiting autonomous actions to those that are "narrowly scoped, preapproved and reversible". The guidance is written for "Chief Information Security Officers and senior security leaders", which is to say it is written for the people who will be measured against it.

The control surface the ASD is describing

Read those passages together and a specific control surface emerges: monitor what staff send to AI tools, enforce data policy before the prompt leaves the browser, generate telemetry at the prompt layer, and keep an auditable record a board or regulator can stand behind. That surface is what Airentect was built for.

A few of the mappings are close to verbatim.

On the governance and data-handling expectation, Airentect monitors, redacts or blocks sensitive prompts before they leave the browser for ChatGPT, Copilot, Gemini or Claude. The control the ASD now expects is the control we already ship.

On telemetry, we generate exactly the AI-specific signals the guidance describes, at the prompt layer: per-prompt policy checks, the data category that triggered, which LLM carried it, and the outcome. That is the visibility the ASD says defenders need, and most organisations cannot produce it today.

On auditability, every flagged prompt is logged with timestamp, user, category, rule triggered and outcome, whether that was warned, redacted, blocked or accepted with risk. It exports in a form built for boards, regulators and bank-client due diligence.

On human oversight, our Redact, Block or Continue flow keeps the person in the loop rather than silently blocking. Enforcement is policy-driven and reversible, which sits well with the ASD's preference for reversible, narrowly scoped actions over blanket bans that simply invite workarounds.

On integration, Airentect deploys as a managed browser extension through your existing MDM and sits beside the DLP you already run for email, files, cloud and endpoints. There is no proxy and no network redesign. The ASD asks that AI "strengthen existing cyber security practices rather than replace them", and adding the prompt layer without weakening anything else is exactly that.

There is also a procurement angle. The paper introduces AI Secure by Demand, the idea that buyers should hold suppliers to account and protect AI systems from adversarial techniques such as prompt injection. Operationalising acceptable-use policy at the point of risk, with Australian data residency and least-privilege design, is how a buyer demonstrates that bar in practice.

Where Airentect fits, and where it does not

I would rather you trust this post than oversell it, so here is the honest boundary.

Most of Opportunities for AI in cyber defence is about defenders using AI inside the SOC: triage, detection engineering, response and recovery. That is not our lane, and we are not going to pretend otherwise. Those use cases belong to your SOC tooling and your analysts.

Airentect's wedge is the govern, protect and secure-adoption slice: governing how staff use AI day to day and preventing sensitive data from leaving at the prompt. Positioned honestly, we are the control that operationalises the ASD's governance and data-handling expectations. We complement SOC AI tooling rather than compete with it.

For Australian security leaders, the useful thing about this guidance is that it now sits alongside APRA's letter to industry and ISO/IEC 42001 as a third reference point pulling in the same direction. Three different authorities, one consistent expectation: visibility and enforceable control over how AI is used, evidenced over time.

The practical first move

The expectation the ASD lists first under data handling is preventing sensitive information from reaching unapproved AI tools. You cannot evidence that, brief your board on it, or answer a vendor due-diligence questionnaire about it without first knowing what your workforce is actually sending.

That is what our 14-day Exposure Report is for. Over two weeks it:

• Inventories every LLM in use across your workforce, sanctioned and unsanctioned
• Categorises the data being entered into each tool: PII, customer records, source code, financial and board-level material
• Identifies the workflows and teams where exposure is concentrated
• Produces, in regulator-grade form, the evidence a CISO uses to show their board they meet the ASD's expectation to prevent sharing with unapproved AI tools

It is the cheapest and most defensible first step, because it converts the guidance from a statement of intent into measured behaviour you can put in front of a risk committee.

The window is short

National guidance, APRA's enforcement framing, ISO 42001 and a hardening cyber insurance market are now all pointing the same way. Security leaders who can show observable, enforceable control over staff AI use this year are positioned for what comes next. Those who wait will be retrofitting controls under pressure, with less leverage and tighter timelines.

Apply for a 14-day Exposure Report

If the questions in this post are landing for your team, we would be glad to walk you through what the Exposure Report would surface for your environment.

Enquire now for the June cohort on our website.

No charge · Mid-tier regulated organisations prioritised · Outputs map directly to the ASD's govern, detect and protect expectations

Airentect is an AI-native, cross-LLM prompt-layer monitoring and DLP platform built for compliance-heavy sectors. We are headquartered in Sydney and work with regulated mid-market organisations across Australia.

Have a specific question about how Airentect maps to the ASD guidance, APRA CPS 234 or your ISO 42001 program? Email us at info@airentect.com.

This article is general information about emerging regulatory and risk themes, not legal or compliance advice for your organisation.