
An AI security checklist for Australian organisations needs two layers: the ISM and Essential Eight hygiene you already run for identity, patching and logging, plus AI-specific controls for prompt injection, excessive agency, output handling, model supply chain and vendor data use. The 50 controls below are grouped into six families and mapped to OWASP, NIST, ISO and ASD frameworks.
Key takeaways
- AI changes the threat model. The OWASP Top 10 for LLM Applications lists risks classical application security never covered.
- Ten controls do most of the work: privacy impact assessments, data minimisation, tool scoping, untrusted-content handling, output sanitisation, human approval on consequential actions, version pinning, full logging, an AI incident playbook and a contractual training-data ban.
- Essential Eight remains the floor. Each strategy needs an AI extension to stay credible.
- Most public AI incidents came from missing operational controls, not exotic attacks.
How has AI changed the security threat model?
Generic checklists recycle cloud hardening advice. Theoretical ones list OWASP categories without mapping them to a control you can implement. Both miss what matters.
The OWASP Top 10 for Large Language Model Applications 2025 lists ten risks every CISO should know:
| OWASP ID | Risk | What it looks like in production |
|---|---|---|
| LLM01 | Prompt injection (direct and indirect) | A document the agent reads contains instructions that hijack its behaviour |
| LLM02 | Sensitive information disclosure | The model echoes API keys or another customer's record |
| LLM03 | Supply chain | A poisoned base model, embedding library or prompt template enters your stack |
| LLM04 | Data and model poisoning | Adversaries corrupt fine-tuning or retrieval data to alter outputs |
| LLM05 | Improper output handling | Model output flows unsanitised into shell, SQL or another system |
| LLM06 | Excessive agency | An agent has more tools, scopes or write access than its task needs |
| LLM07 | System prompt leakage | The system prompt, with its business rules, is exfiltrated |
| LLM08 | Vector and embedding weaknesses | Retrieval pipelines leak data across tenants or surface poisoned chunks |
| LLM09 | Misinformation | Confident, plausible, wrong answers reach customers or staff |
| LLM10 | Unbounded consumption | Token, compute or API spend runs away through abuse or loops |
The NIST AI Risk Management Framework and its Generative AI Profile (NIST AI 600-1) add governance and lifecycle functions. MITRE ATLAS catalogues adversarial techniques against AI systems.
For Australia, the ASD Information Security Manual (ISM) is the baseline regulated buyers expect, and the Essential Eight Maturity Model is the hygiene floor. Neither was written for AI, which is why this checklist exists.
What are the 50 AI security controls?
Six families, each item tied to a framework so you can defend it in an audit or board paper.
Family 1: Data governance and classification (8 items)
- Maintain a written data classification scheme and apply it before any data set is approved for an AI use case (ISO/IEC 27001:2022 Annex A 5.12; ISM data classification guidance).
- Complete a Privacy Impact Assessment before any AI system processes personal information, in line with OAIC guidance on privacy and commercially available AI and APP 1.
- Check APP 6 alignment for every personal information input. Secondary use for AI is the most common APP 6 trip-wire.
- Minimise data. Send the agent only the fields its task needs (NIST AI 600-1; APP 3).
- Block sensitive information (health, financial, biometric, criminal record) from public consumer AI tools, consistent with OAIC guidance.
- Encrypt training, fine-tuning and retrieval corpus data at rest to ISM-approved standards.
- Encrypt all data in transit, including traffic between agents, vector stores and tool endpoints.
- Document an erasure procedure for decommissioned models, embeddings and adapters. Deleting source data is not enough if a model has memorised it (LLM02).
Family 2: Identity, access and tool scope (8 items)
- Enforce role-based access across model endpoints, vector stores, orchestrators and observability tooling.
- Require phishing-resistant MFA for all admin, developer and prompt-engineering access (Essential Eight).
- Issue a dedicated machine identity per agent. No shared service accounts or personal credentials in pipelines.
- Scope every tool and API key to the minimum action the agent needs. An agent that reads invoices does not get write access to the AP ledger (LLM06).
- Use just-in-time elevation for retraining, prompt updates or tool-scope changes, with expiry and approval logging.
- Keep an authoritative inventory of every model, agent, prompt, tool, vector store and integration, each with a business owner (NIST AI RMF Map function).
- Recertify access and tool scopes quarterly. Access creep on agentic systems is easy to miss.
- Segment development, test and production agent environments. Production data does not enter non-production without de-identification.
Family 3: Prompt and output safety (10 items)
- Validate, normalise and length-bound every prompt input (LLM01, LLM10).
- Treat all third-party content (web pages, PDFs, emails, tickets) as untrusted. In 2023 a Chevrolet dealership chatbot in Watsonville, California was talked into "agreeing" to sell a vehicle for one dollar.
- Run a separate guardrail layer for prompt-injection detection: patterns, classifiers and known jailbreak signatures (MITRE ATLAS prompt injection techniques).
- Enforce output policies: no personal information echo, no system prompt disclosure, no executable code in plain channels (LLM02, LLM07).
- Treat the system prompt as a secret. Store it in a secrets manager and never expose it through a tool the agent can read.
- Sanitise output before it is rendered, executed or sent downstream. In January 2024, parcel company DPD's chatbot publicly swore at a customer and criticised the company (LLM05).
- Apply contextual escaping before output reaches HTML, SQL, shell or email.
- Rate-limit per user, session and tenant, and bound token spend in the application.
- Require a person to approve any agent action that writes, deletes, moves money or contacts a customer. See AI agent governance and human override.
- Red-team every new agent against the OWASP LLM Top 10 and relevant MITRE ATLAS techniques before go-live and after any prompt or tool change.
Family 4: Model, embedding and supply chain (7 items)
- Pin model versions in production. A silent provider update can change behaviour overnight.
- Verify provenance for every base model, fine-tune, adapter and embedding model: checksums for open weights, attestations for hosted models (LLM03).
- Vet third-party prompt templates and tool definitions like third-party code.
- Scan vector stores for poisoning: anomalous chunks, unexpected language, embedded instructions (LLM04, LLM08).
- Isolate tenant data in retrieval pipelines with per-tenant indexes and access checks. Cross-tenant leaks are usually configuration errors, not model flaws.
- Test models against adversarial inputs before deployment with a toolkit such as the Adversarial Robustness Toolbox.
- Keep rollback capability for models, prompts and tool definitions as versioned artefacts with immutable history.
Family 5: Logging, monitoring and incident response (10 items)
- Log every prompt, tool call, retrieved document, output and refusal for high-risk agents. Without it you cannot reconstruct an incident.
- Centralise AI logs in a SIEM with retention aligned to record-keeping obligations. The ATO generally requires business records to be kept for five years.
- Use tamper-evident, append-only log storage for high-risk pipelines.
- Baseline token use, latency, refusals and errors per agent, and alert on deviation (LLM10).
- Detect anomalous tool-call patterns by frequency, sequence and target.
- Detect prompt-injection signatures and known jailbreak families in inbound traffic.
- Run quarterly tabletop exercises covering prompt injection, an irreversible action from excessive agency, and a vector store leak.
- Keep a written AI incident playbook covering model rollback, prompt invalidation and tool-scope revocation, which generic runbooks miss.
- Classify AI incidents by severity and define what triggers a Notifiable Data Breach assessment. Under the OAIC NDB scheme, you have 30 days to assess a suspected eligible breach.
- Pre-draft customer, regulator and media holding statements for those scenarios.
Family 6: Vendor and contractual controls (7 items)
- Require SOC 2 Type II or ISO/IEC 27001:2022 from every vendor in the AI stack, and read the actual report.
- Ask vendors handling personal information at scale for ISO/IEC 27701 and, ideally, ISO/IEC 42001, the AI management system standard.
- For regulated government workloads, require IRAP assessment at the right classification level.
- Contractually prohibit vendors from training shared models on your data. In 2023 Samsung restricted staff use of consumer generative AI after employees pasted source code into ChatGPT.
- Require breach notification fast enough for you to meet your own 30-day assessment window. Seven days from detection is a reasonable floor.
- Confirm data residency for data at rest, processing and logs. Hosting in Australia is a legitimate procurement requirement.
- Require a published list of model providers, sub-processors and data flows. If a vendor cannot name the foundation model behind its product, you cannot assess risk.
Where to start: items 2, 4, 12, 18, 22, 25, 27, 34, 41 and 47 reduce the most real risk. If you can only fund a first wave, fund those.
How do AI controls extend the Essential Eight?
| Essential Eight expectation | AI extension required | Impact | |
|---|---|---|---|
| Application control | Allowlist executables, scripts, installers | Allowlist models, prompts, tool integrations and embedding models as governed artefacts (items 14, 28) | + supply chain |
| Patch applications | Patch internet-facing applications promptly | Pin model versions and review provider release notes before adopting (item 27) | + model drift control |
| Configure Office macro settings | Block macros from the internet | Quarantine untrusted document content before agents ingest it (item 18) | + indirect prompt injection |
| User application hardening | Harden browsers and office apps | Disable autonomous browsing, code execution and email send unless scoped and approved (items 12, 25) | + excessive agency |
| Restrict admin privileges | Separate, validated privileged accounts | Quarterly tool-scope reviews, just-in-time access for prompt and model changes (items 13, 15) | + agentic privilege |
| Patch operating systems | Patch internet-facing systems promptly | Track vulnerabilities across model-serving frameworks, vector databases and orchestrators | + AI stack patching |
| Multi-factor authentication | MFA for privileged, remote and important data access | Phishing-resistant MFA across prompt, vector store and orchestrator admin (item 10) | + AI admin surface |
| Regular backups | Tested backups, separated from production | Versioned, immutable storage of models, prompts and tools with tested rollback (item 33) | + AI artefact recovery |
Which public AI incidents show the missing controls?
- Samsung 2023Staff paste source code into ChatGPT. Missing: items 5 and 47, consumer AI policy and training-data block (LLM02)
- Chevrolet of Watsonville 2023Chatbot manipulated into a one-dollar car offer. Missing: items 17, 19, 25, input validation, guardrails, human approval on commercial terms (LLM01)
- DPD January 2024Chatbot swears and criticises its own company. Missing: items 22, 23, output policy and sanitisation (LLM05)
- Replit July 2025Coding agent deletes a production database during a code freeze. Missing: items 12, 25, 33, tool scoping, human approval, rollback (LLM06)
Each was a missing operational control that could have been implemented at modest cost. See also how the wrong AI tools leak business data into training.
What does a 90-day AI security plan look like?
- Days 0-30Assess and triageInventory every model, agent, prompt, tool and data flow (item 14). Run PIAs on high-risk use cases (item 2). Lock down items 5, 10, 12 and 25. Publish an AI use policy.
- Days 31-60Vendor controls and loggingIssue vendor questionnaires, collect SOC 2 and ISO reports, amend agreements for items 47 to 49. Stand up central logging for prompts, tool calls and outputs (items 34 to 37).
- Days 61-90Monitoring and exercisesTune detections for injection and anomalous tool calls (items 38, 39). Run tabletop exercises (item 40). Publish the AI incident playbook (item 41). Brief the board.
After 90 days it is continuous improvement: quarterly access recertification, quarterly red-teaming and annual third-party assessment for high-risk systems.
- Internal security and engineering effortUsually the largest line
- AI-aware SIEM tooling and log retentionScales with log volume
- Prompt-injection and output guardrail layerPlatform or build
- External red-team and assessmentAnnual, plus after major change
- Vendor contract remediationLegal and procurement time
Weigh that against breach exposure. Under the Privacy Act, penalties for serious interferences with privacy can reach the greater of $50 million, three times the benefit obtained, or 30 per cent of adjusted turnover.
Should you run AI security in-house or with a partner?
Do you have the depth to run an AI security program in-house?
- AppSec team of 3+, IRAP not required, low data sensitivityBuild in-house with an annual external red-team
- AppSec team of 1-2, regulated industry (APRA, healthcare, government supply chain)Hybrid: keep governance in-house, partner for assessments and monitoring
- No dedicated security function, high-sensitivity data, IRAP or APRA exposureEngage a partner with relevant assessment experience from day one
- Lean AppSec team, low-risk internal AI use casesPhase it: in-house foundation now, partner for red-team and incident retainer
Governance and accountability stay with you. A partner can deliver controls; they cannot answer the regulator for you.
Eight questions every CISO should ask before sign-off
- Which OWASP LLM risks are mitigated by design, and which are accepted? Show the control mapping.
- What is the blast radius if this agent is fully compromised? List what it can read and write.
- Where does the data go, in plain English: provider, region, sub-processors, training use, retention?
- Show the last prompt-injection red-team report. Who ran it and what changed?
- What is the rollback time for a bad model, prompt or tool definition, and when was it last tested?
- Which logs would reconstruct a worst-case incident, and how long are they kept?
- Which clauses cover training-data use, breach notification and sub-processor changes?
- If the OAIC called this morning about this system, what would the first eight hours look like?
If the team cannot answer all eight quickly, the system is not ready to ship.
How Solve8 can help
We build AI systems that run on your infrastructure in Australia, with scoped tool access, full logging and a person approving any action that reaches a customer or system of record. Our own products, Carbonly and RootCauseAI, use these controls. See our private AI infrastructure service, or talk to us for a walkthrough against your environment.
