← SecureAZ Blog

Security Awareness · 8 min read · Published 08 July 2026 · Reviewed 17 August 2026

OWASP LLM Top 10: A Practical Guide for NZ Development Teams

The OWASP LLM Top 10 maps ten AI-specific vulnerabilities every NZ dev team building with LLMs needs to understand and mitigate before going to production.

The OWASP LLM Top 10 exists because the traditional web application security risk list — injection, broken authentication, misconfiguration — does not map cleanly to AI systems. AI introduces a distinct category of vulnerability: probabilistic behaviour that attackers can influence through content rather than code.

The list covers ten AI-specific risks, structured into four areas. NZ development teams building with language models need to understand all ten before they go to production.

Input Attacks: What the Model Reads

LLM01 — Prompt Injection is the top risk on the list. An attacker controls something the model reads — a user message, an uploaded document, a database record, a fetched webpage — and uses that control to change what the model does. Direct injection arrives in the user message. Indirect injection arrives in content the model processes as part of its task.

The defence is architectural: process untrusted documents in a sandboxed context separate from the model that takes privileged actions. No amount of prompt hardening prevents injection reliably — the model cannot distinguish instruction from content.

LLM07 — System Prompt Leakage matters because system prompts often contain table names, field names, file paths, and internal logic never intended to be user-visible. If a user can prompt the model to repeat its system prompt — which is often achievable with simple instruction — that information becomes reconnaissance for further attacks. The rule: put no secrets in prompts. Treat the system prompt as readable by any user who can interact with the model.

Data Risks: What Can Be Accessed or Corrupted

LLM02 — Sensitive Information Disclosure is caused by pulling too much data into the model's context. Every field you pass to the model is a field that can be exfiltrated if the model is influenced to return it. Named field allowlists per query type — only pulling what the model needs for the specific task — is the primary control.

LLM04 — Data and Model Poisoning describes a hidden behaviour triggered by specific inputs rather than general misbehaviour across every query. This applies to fine-tuned models and to RAG systems where attacker-controlled documents can inject false context. Track provenance of all training data. Evaluate models adversarially after training.

LLM08 — Vector and Embedding Weaknesses affect multi-tenant RAG systems specifically. Vector similarity search finds what is close — it does not understand access control. Applying tenant filters after similarity search rather than before means a cross-tenant query can return data from another organisation. Apply metadata filters before the similarity search, not after.

Output and Runtime Risks: What the Model Produces and Does

LLM05 — Improper Output Handling converts a prompt injection into stored XSS when model output is rendered as HTML without sanitisation. Every user who views the injected response is attacked. Validate model output against a defined schema. Render text only — never render raw model output as HTML.

LLM06 — Excessive Agency describes an AI agent whose tool permissions exceed what is required for its task. If an agent can send email, delete records, and call external APIs, a successful prompt injection hands an attacker all of those capabilities. Least-privilege tool design and human confirmation before any consequential action are the controls.

LLM09 — Misinformation and Overreliance matters most in high-stakes domains: legal, medical, financial. A hallucinated citation looks identical to a real one. For outputs where errors carry real consequences, ground the model in verified sources only and require it to cite the provided document identifiers — then validate those citations before returning results.

Infrastructure Risks: What Your AI Stack Depends On

LLM03 — Supply Chain Vulnerabilities affect the SDKs, model providers, and third-party packages your AI architecture depends on. A malicious transitive dependency with over two million weekly downloads logged model inputs for three weeks before detection in a 2024 incident. Pin exact dependency versions. Commit lockfiles. Log which model version processed each request so you can scope the impact of a compromised model.

LLM10 — Unbounded Consumption is an availability and cost attack. Fifty thousand automated requests over a weekend can generate an $11,400 API bill and take a service offline by Monday. Apply per-user rate limits, input token caps, daily token budgets, and a circuit breaker that halts processing when spend spikes beyond expected bounds.

Why This Matters for NZ Teams Specifically

The OWASP LLM Top 10 is now referenced in AI security audits, insurance assessments, and procurement questionnaires. NZ organisations handling personal information under the Privacy Act 2020 have an obligation to take reasonable steps to protect it — and reasonable steps increasingly means demonstrating you have addressed these risks in writing.

CERT NZ and the NCSC are both extending their guidance to cover AI-specific threats. Teams that understand the Top 10 now will be ahead of the curve when these controls become a formal requirement in supplier questionnaires and cyber insurance renewals.

Shadow IT and credential reuse compound AI risk further — as covered in our post on shadow IT and credential reuse in NZ. An AI integration that pulls data from an unmanaged system or authenticates with a shared credential carries compounded exposure.

Getting Your Team Up to Speed

SecureAZ's Developer Track Module B covers all ten risks using the same four-part pattern for each: what it is, the vulnerable code that creates the exposure, the actual exploit step by step, and the fix. Knowledge gates after each risk require demonstrated understanding before the learner can progress. The final page is a quick reference covering all ten risks and their primary controls — ready to use in threat modelling sessions and code reviews.

Start the SecureAZ Developer Track