Priya is a senior developer at a Wellington legal firm. Eight years of secure application development — patching dependencies, sanitising inputs, enforcing authentication on every route. Her team ships an AI integration. Within six weeks, a security researcher finds a vulnerability. None of her existing instincts helped her see it coming.
This is the gap that matters in 2026. Not whether NZ developers can write secure code — most can. The question is whether they understand what changes when they add a language model.
LLMs Are Not Rules Engines
Traditional application security works because code is deterministic. An input validation rule either accepts or rejects an input. An authentication check either passes or fails. You can reason about it in advance and test every branch.
A language model is a next-token predictor. It has no concept of trusted versus untrusted text. It cannot distinguish between your system prompt and an attacker's injected instruction — both are just tokens in a context window. When an attacker submits a document that contains hidden instructions, the model processes those instructions the same way it processes your prompt.
This is not a bug. It is the fundamental nature of how language models work. And it means that every input validation technique you apply at the application layer does nothing to stop an attacker from influencing model behaviour through content the model reads.
The Four New Attack Surfaces
Building with AI introduces attack surfaces that did not exist before:
The context window. Every field you pull into the model's context is a field that can be exfiltrated if the model is prompted to return it. Pulling everything from a database record because it is convenient means an attacker who can influence model output can retrieve fields you never intended to expose.
Model outputs. If you render model output as HTML without sanitisation, a single prompt injection becomes stored XSS attacking every user who views the response. The model generates the payload; your rendering layer delivers it.
Agentic tool permissions. An AI agent's blast radius equals the permissions its tools carry. If an agent can send email, delete records, and call external APIs, a successful prompt injection reaches all of those capabilities. Least-privilege is not optional — it defines the worst case.
Your dependencies. The SDKs, model providers, and third-party packages your AI stack depends on each carry supply chain risk. A malicious transitive dependency can log model inputs for weeks before detection.
What Existing Instincts Miss
Most developers' security instincts are input-focused: validate what comes in, sanitise what goes out. This is correct and necessary — but it does not address the AI-specific threat.
Indirect prompt injection arrives through content the model reads, not through direct user input. A malicious instruction embedded in a PDF the user uploads, a database record the model queries, or a webpage the model fetches can redirect model behaviour without the attacker ever touching the user input layer. Your input validation never sees it.
Output handling for AI applications requires schema validation — defining the exact structure a model response must conform to and rejecting anything that does not match — plus text-only rendering for any field that users can view. Neither of these is standard practice in most teams.
The NCSC Baseline Does Not Cover AI
The NCSC's minimum cyber security standards cover authentication, patching, logging, and access control. These remain necessary when you add AI. But they do not address injection resistance, context scoping, model output validation, or agent tool governance — all of which are AI-specific controls layered on top of the baseline.
According to CERT NZ's 2025 Cyber Security Insights report, the number of reported incidents involving AI-related vulnerabilities increased significantly in the past year. The attack patterns are new. The controls are not yet instinct. See our post on the NCSC minimum cyber security standards for the baseline — AI extends it, it does not replace it.
What Secure AI Development Actually Looks Like
The principles map to concepts experienced developers already know — least privilege, input validation, output validation, rate limiting — applied to AI-specific surfaces:
- Scope context windows to named field allowlists per query type. Never pull the full record into a model's context.
- Treat model output as untrusted input. Validate against a schema before using it. Render text only.
- Design agent tool sets using least-privilege. Require human approval before any consequential action — send, delete, pay.
- Apply tenant metadata filters to vector stores before similarity search. Similarity search does not understand access control.
- Pin exact dependency versions. Log which model version processed each request.
- Set per-user rate limits, input token caps, and daily token budgets. Unbounded consumption is an exploit vector.
The developers who learn these patterns before they ship will produce AI features that survive real-world attacks. The developers who learn them after have already given attackers a head start.
Build It Secure From the Start
SecureAZ's Developer Track — now live in the platform — covers all six of these areas in two focused modules. Module A builds the foundation: how LLMs actually work, where the new attack surfaces are, and how to apply existing security principles to them. Module B covers the OWASP LLM Top 10, with vulnerable code patterns, the real exploit for each, and the architectural fix.
If your team is shipping AI features in 2026, this is the training that closes the gap Priya had.