# The government just told CISOs to govern their AI's data > Canonical: https://roblinton.com/writing/asd-ai-guidance-govern-the-data/ > Author: Rob Linton ยท Published 2026-09-07 **TL;DR:** In May 2026 ASD's ACSC, with its Canadian, NZ and UK counterparts, told security leaders to adopt AI for cyber defence and to govern the data they give it. The second instruction is the one that matters: least-privilege access for AI, enforced policies on what AI tools may read, auditable AI-assisted actions, and a vendor question list that asks exactly where your data goes. That checklist is now the procurement script for every security-mature buyer in the country. --- In May 2026 the Australian Government told every CISO in the country two things at once: use AI in your cyber defence, and govern the data you give it. The publication is "Opportunities for AI in cyber defence", from ASD's Australian Cyber Security Centre, co-sealed by the national cyber centres of Canada, New Zealand and the United Kingdom. Most of the commentary focused on the first instruction. The second one is the story. I have spent thirty years on [one question](/writing/thirty-years-one-problem/): who is allowed to read this? This paper is the first time I have watched four governments ask it about AI, in writing, for the exact audience that signs the purchase orders. ## What does the ASD guidance actually say? Adopt AI, carefully, with the emphasis on carefully. The 23-page paper maps AI onto the six functions of the Information Security Manual (Govern, Identify, Protect, Detect, Respond, Recover), then spends its strongest sections on what has to be true of the data underneath. The lines worth reading twice, quoted exactly: - Organisations should be "enforcing least privilege access, restricting data exposure to AI systems" and "maintaining auditability of AI-assisted actions" (p. 7). - They should "define and enforce policies governing what data AI tools may access, how data may be used and where outputs may be transmitted" (p. 15). - Integrations should "use controlled and auditable integration methods, such as purpose-built security platforms or secured API integrations" (p. 14). - And the framing that holds it together: "Data readiness is a core prerequisite for AI adoption." Least privilege is thirty-year-old language (every one of those sentences would sit comfortably in a mainframe security manual). What is new is who it applies to: the paper points them at AI tools, including agentic AI, which it says needs bounded autonomy, sandboxing, traceable actions and human approval for anything high-impact. An agent is a user now, and the government just said so. ## Why is Appendix A the part worth printing? Because it is a procurement script, and your next AI vendor will be marked against it. Appendix A is a question list for AI vendors: measurable outcomes, scope and limits, human oversight, transparency, and a block on data protection that includes this one, quoted exactly: "Which jurisdictions process or store customer data, including through third-party AI services?" (p. 19). Read that question the way a vendor will have to answer it. Most AI products route data through a frontier-model API, which routes it through whatever infrastructure sits behind that. Answering the jurisdiction question honestly, for every hop, is going to be an uncomfortable exercise for a lot of sales teams. My read: within a year, fluency in Appendix A will separate the AI vendors who sell to government and defence from the ones who do not. The economics point the same way. I have written before about [the repatriation pattern](/writing/cloud-repatriation-ai-parallel/): enterprises pulling steady-state workloads back onto infrastructure they control, and the same turn now starting in AI. This paper adds the compliance half of that argument. Cost pushes the workload home; now the government's own question list asks where home is. ## What would I actually do with this? I work on products at Senetas that live in exactly this territory, so read my enthusiasm with that in mind (the opinions here are mine, not the company's). The design principle I keep coming back to is the one the paper circles without naming: an AI agent should see only what the person behind it is cleared to see. No separate, softer rulebook for machines; the same rules, enforced at the data, with an audit trail you can actually point at afterwards. For a CISO, the paper converts to a short list: 1. **Inventory what your AI tools can currently read.** Not what they are supposed to read. What they can reach. This number is usually a surprise. 2. **Run Appendix A against your existing AI estate**, not just new purchases. The retrofit findings are where the risk is. 3. **Treat agents as users.** Least privilege, scoped credentials, an audit trail. The paper says this plainly; most current deployments do not do it. 4. **Ask the jurisdiction question of every vendor, every hop.** If the answer takes more than a paragraph, that is the answer. ## The honest caveat Guidance is not regulation. Nothing in this paper compels anyone, and ASD does not endorse vendors or products, mine included. It is also fair to note the paper spends most of its pages on the opportunities, not the governance; I am quoting its spine, not its word count. And I am not a neutral reader. The reason I find this paper persuasive is that I spent years building for the position it takes, which is either corroboration or confirmation bias, and a sceptic should hold both hypotheses. But the direction is hard to argue with. Four allied governments have now put in writing, for the people who own security budgets, that AI adoption starts with deciding what the AI is allowed to read. Rob Linton has been asking that question since the nineties; it is pleasant to have company. Net: data readiness first, AI second. Print Appendix A and take it to your next vendor meeting ([the annotated walkthrough](/asd-appendix-a-annotated/) is on this site).