If your development team is building features that use a language model, the question is not whether they know how to write secure code. They almost certainly do. The question is whether they understand what changes when an AI model joins the architecture.
Most do not — and it is not their fault. AI security is a new discipline. University curricula have not caught up. Most secure coding courses and frameworks were written before language models were a standard part of application stacks. The gap is not a skills failure. It is a training lag.
That lag is becoming expensive.
What the Breach Data Shows
Verizon's 2026 Data Breach Investigations Report found that AI-assisted attacks are now present in the majority of social engineering incidents. AI is also expanding the attack surface inside applications: systems that accept AI-generated content or pass user input to a model are exposed to categories of attack that traditional security testing does not cover.
The NZ Privacy Commissioner received a record number of breach notifications in 2025. A growing proportion involved AI or automation elements — systems that processed data through external APIs, generated content from user inputs, or took automated actions based on model outputs.
The cost of a notifiable data breach for a NZ SME averages NZ$200,000 when you include incident response, notification costs, regulatory engagement, and reputational impact — as covered in our post on the real cost of a data breach for NZ SMEs. For a breach that traces back to an AI vulnerability your dev team could have been trained to prevent, that cost is difficult to justify.
What AI Security Training Actually Covers
Secure AI development training is not a repeat of OWASP Top 10 content with different labels. The risks are genuinely different.
Language models cannot enforce security rules internally. A model cannot be instructed to "never reveal sensitive data" in a way that holds against a determined attacker — because the model processes all text the same way and cannot distinguish instruction from adversarial input. Your application layer has to do the work.
The attack surface includes content the model reads, not just inputs the user types. An attacker who can get a malicious PDF, database record, or webpage in front of a model that has privileged tool access has a viable attack vector — regardless of how well you sanitise direct user input.
Agent architecture changes the blast radius calculation. A model that can send email, modify records, and call APIs gives a successful attacker all of those capabilities at once. Least-privilege design and human approval gates are the controls — but most developers have never applied these concepts to AI agents specifically.
The Business Case Is Straightforward
Developer training for AI security costs a fraction of an incident. More importantly, it produces durable capability: developers who understand these risks will apply that understanding across every AI feature they ship.
The SecureAZ Developer Track covers this in two focused modules — approximately 30 minutes each. Module A covers foundations: 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 actual exploit for each, and the fix.
Both include knowledge gates that require demonstrated understanding before progressing. Both are built specifically for developers who already know how to write secure code and need to understand what changes with AI.
For NZ organisations subject to the Privacy Act 2020, having a trained development team contributes to demonstrating that you took reasonable steps to protect personal information — a relevant consideration if the Privacy Commissioner asks what controls were in place.
Who Should Complete the Training
Any developer who has integrated or is planning to integrate an LLM API. The risks apply from the first API call. Understanding context scoping, output handling, and injection patterns before shipping is materially cheaper than learning about them from a security researcher's disclosure.
Technical leads setting AI standards for their team. Module B's quick reference card covers all ten OWASP LLM risks and their primary controls — ready to use in threat modelling sessions and code reviews.
Security engineers extending threat model coverage. The Developer Track covers the attack patterns, not just the controls. Understanding what an attacker actually does with a prompt injection or a vector store cross-tenant query makes threat modelling AI features significantly more accurate.
DevOps and platform engineers managing AI pipelines. Supply chain risk and unbounded consumption are infrastructure-layer risks — the module covers both with practical controls: version pinning, committed lockfiles, per-user rate limits, token budgets, and circuit breakers.
Start With the Developer Track
The SecureAZ Developer Track is now live in the platform. Module A builds the foundation. Module B covers the OWASP LLM Top 10, risk by risk. Both are interactive articles with embedded knowledge gates — not passive video. Completion is tracked and exportable for audit evidence.
Your team is already building with AI. The training that closes the security gap is available now.