On 28 September 2026 the Australian Signals Directorate published an advisory titled Protect your organisation's AI services. It is short, plain and, in my view, one of the most important pieces of guidance ASD has issued this year. You can read it in full here: https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/protect-your-organisations-ai-services
The opening position is clear. ASD says it is aware that malicious cyber actors are gaining unauthorised access to organisations' AI services through compromised API keys, stolen authentication tokens, compromised user sessions, vulnerable applications and third-party access arrangements. Once inside, they can create harmful material, distil model capabilities, exhaust credits and disrupt legitimate work. ASD then asks organisations to treat access to advanced AI services as a security-sensitive asset, and states that protecting that access requires more than relying on the AI developer's own controls.
I agree with every word of that. I want to explain why from an engineering point of view, why it matters more for the legal profession than almost anyone else, and how my team at Keytech Intelligence intends to put these exact controls under pressure in front of a live audience.
Why ASD is right
For two years the conversation about AI risk has focused on the model. Will it hallucinate? Will it leak training data? Those are fair questions, but they draw attention away from the more ordinary and more dangerous problem. The model sits at the end of a chain of keys, tokens, sessions, integrations and suppliers. If any link in that chain is weak, the strength of the model provider's security is irrelevant.
I spent twelve years in the Royal Australian Air Force and later qualified as a mechanical fitter. In both worlds you learn the same lesson. A system fails at its connections, not in the middle of a well engineered part. A bolt is rated, a bracket is rated, a lifting point is rated, and the failure still happens where someone assumed the joining piece was somebody else's problem. AI services are no different. The API key in a config file, the browser session on an unmanaged laptop, the supplier with standing access nobody reviews: those are the joints.
ASD's own guidance on the related risk of AI misalignment, published four days earlier, makes the same point from another angle: https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories
What ASD actually asks organisations to do
The advisory sets out a small number of control areas. Each one is practical, and each one is checkable.
Assign ownership and apply least privilege. Keep an inventory of AI accounts, service identities and credentials. Give each one an accountable owner. Grant only the access required and remove what is no longer needed.
Protect accounts and credentials. Require phishing-resistant multi-factor authentication. Use managed and patched devices. Watch for suspicious session activity. Store API keys in approved secrets management services and stop them appearing in code, documents, logs or prompts.
Separate restricted access and third-party use. Keep restricted model access and sensitive data apart from routine and experimental use. Review applications before exposing them externally. Give suppliers limited and auditable access.
Monitor activity and enforce limits. Monitor model access, credential creation, permission changes and unusual usage. Protect audit logs from tampering. Configure and test spending, rate and consumption limits so a stolen key cannot run unchecked.
None of this is exotic. It is the Essential Eight mindset applied to a new class of asset, and it lines up with ASD's broader AI publications: https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence and with the Essential Eight itself: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight
Why law firms should read this twice
A law firm's AI service is not a productivity toy. It is a pipe that carries privileged communications, client identities, litigation strategy, settlement positions and in many matters health, family and criminal history information. A compromised AI session in a firm is not just a billing problem. It is a potential breach of legal professional privilege and a notifiable data breach under the Privacy Act.
The Office of the Australian Information Commissioner sets out those obligations here: https://www.oaic.gov.au/privacy/notifiable-data-breaches and from 10 December 2026 the new automated decision transparency requirements also apply, which I covered in detail here: https://ausdeeptech.org/insights/privacy-act-10-december-2026-automated-decision-ai-transparency
The Law Council of Australia has also published guidance for practitioners using AI, and the state regulators and law societies have followed: https://lawcouncil.au/ Professional obligations of confidentiality do not pause because the work passed through a model.
Firms are adopting AI quickly, often tool by tool and partner by partner. That is exactly the pattern ASD warns against: credentials nobody owns, sessions on devices nobody manages, and suppliers with access nobody audits.
Keytech Core and the LawTech: AI Summit
This is where I move from agreeing with ASD to testing the advice in public.
Keytech Intelligence will be presenting at the Lawyers Weekly LawTech: AI Summit in Sydney, the first event of its kind run by Lawyers Weekly for managing partners, legal operations leaders and practice heads: https://www.lawyersweekly.com.au/lawtech-ai/ The full agenda and speaker list are published here: https://www.lawyersweekly.com.au/lawtech-ai/agenda and here: https://www.lawyersweekly.com.au/lawtech-ai/speakers
We will give a live demonstration of Keytech Core, our platform and application built for the legal industry. We are not bringing slides about security. We are bringing the platform, and we will stress test it on stage against the controls ASD has set out.
That means showing, in real time, how Keytech Core handles the things the advisory warns about. Who owns each AI identity and what it is allowed to touch. What happens when a session is presented from an unmanaged device. How keys are held in secrets management and kept out of prompts, documents and logs. How a matter's data stays separated from routine and experimental use. How a supplier is given narrow, logged and time-bound access. How usage and spend limits behave when we deliberately push past them. And how the audit trail looks afterwards, with no way to quietly edit it.
We will pressure test it the way I was taught to test anything that carries load. You do not prove a lifting point by admiring it. You load it past working limits under controlled conditions, you watch where it deforms, and you write down what you saw. If something on stage does not hold, the audience will see it, and so will we. That is the point.
Why sovereignty matters to this test
Keytech Core runs on Australian sovereign infrastructure through our partnership with Macquarie Cloud Services, part of Macquarie Technology Group: https://macquariecloudservices.com and https://macquarietechnology.com The details of that partnership are here: https://ausdeeptech.org/insights/keytech-intelligence-macquarie-cloud-partnership
ASD asks organisations to look beyond the model provider. Sovereign hosting is part of that answer, because it lets a firm know which jurisdiction holds its data, who can be compelled to hand it over, and who operates the systems underneath. It is not the whole answer. Ownership, identity, separation and monitoring still have to be engineered on top. That is why we built Keytech Core as a governed platform rather than a wrapper around someone else's chat window.
What I would ask any firm to do this week
Read the ASD advisory. Then answer five questions honestly.
Do we have a list of every AI account, key and service identity in the firm, with a named owner for each?
Is every one of them behind phishing-resistant MFA on a managed device?
Can any key appear in a document, a log, an email or a prompt?
Do our suppliers have standing access to client data through an AI tool, and when did anyone last review it?
If a key was stolen tonight, what limit would stop it, and who would be alerted?
If any answer is uncertain, you have your priority list. Our MSP veteran data sovereignty checklist covers many of the same controls and is free to download: https://ausdeeptech.org/resources/msp-veteran-data-sovereignty-checklist
Further reading
ASD advisory, Protect your organisation's AI services: https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/protect-your-organisations-ai-services ASD artificial intelligence publications: https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence ASD Essential Eight: https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight OAIC Notifiable Data Breaches scheme: https://www.oaic.gov.au/privacy/notifiable-data-breaches Lawyers Weekly LawTech: AI Summit: https://www.lawyersweekly.com.au/lawtech-ai/ The Agent Would Not Take No, on the Medicare portal breach and AI incidents: https://ausdeeptech.org/insights/ai-agents-tens-of-thousands-incidents-medicare-portal-breach Privacy Act changes from 10 December 2026: https://ausdeeptech.org/insights/privacy-act-10-december-2026-automated-decision-ai-transparency MSP reference architecture for veteran data sovereignty: https://ausdeeptech.org/insights/msp-reference-architecture-veteran-data-sovereignty
About the author
Shaune Irving is Chief Technology Officer of Keytech Intelligence: https://www.keytechintelligence.com He is a twelve year veteran of the Royal Australian Air Force: https://www.airforce.gov.au a qualified Queensland Ambulance Service paramedic: https://www.ambulance.qld.gov.au and a qualified mechanical fitter. His full profile and credentials are at https://ausdeeptech.org/author/shaune-irving and https://ausdeeptech.org/cto/shaune-irving and he can be found on LinkedIn at https://www.linkedin.com/in/shaune-i-148159418/
