Skip to content
◆Service

AI Security, Risk & Governance

Governance and assurance for AI systems, securing the models, the data, and the agentic workflows around them.

An AI system is a stack, and each layer fails differently. The trust boundary runs down the whole of it, because in a language model the instruction and the untrusted input arrive through the same channel. Securing the model alone leaves the data, the tools, and the agency you granted it untouched.

AI systems fail in ways the rest of your security programme was not built for. The model is not the whole system: the risk lives in the data it was trained and grounded on, the tools it can call, and the amount of agency it has been granted. The assumption that underpins most application security, that instructions come from your code and data comes from the user, does not hold. In a language model both arrive through the same channel, which is why prompt injection has proved so stubborn.

The governance half of the work establishes what you actually have. Most organisations discover during an inventory that AI is already in use in more places than anyone had recorded, often embedded in tools procured for something else. From there, an AI management system aligned to ISO/IEC 42001 and a risk assessment against the NIST AI Risk Management Framework give you accountability, an approval path for new use cases, and something defensible to show a customer or regulator who asks.

The assurance half is technical. Threat modelling for LLM and agentic systems against the OWASP LLM Top 10, review of the supply chain across models, datasets and third-party dependencies, and guardrails with evaluation and monitoring that continue after launch. I will be straightforward about the limits here: the controls in this field are less mature than those we rely on elsewhere, and some risks are currently mitigated rather than solved. Knowing which is which is most of the value.

You might need this if

  • Teams are shipping AI features and nobody can produce a list of where models are in use
  • An assistant has been given tools or write access and the threat model has not been revisited since
  • Procurement or legal has been asked whether an AI deployment is defensible, and the answer is a shrug
  • A customer, insurer, or regulator has asked how you govern AI
  • Sensitive data is being pasted into services whose retention terms nobody has read

Who it's for

Organisations deploying LLMs or agentic systems that need to demonstrate the AI is governed, safe, and defensible.

How the engagement runs

  1. 01

    Inventory and use-case triage

    Find where AI is actually in use, including the instances embedded in tools bought for another purpose, and sort use cases by consequence rather than by novelty.

  2. 02

    Governance baseline

    An AI management system aligned to ISO/IEC 42001 and a risk assessment against the NIST AI RMF: accountability, approval paths, and the records that make a deployment defensible.

  3. 03

    Threat modelling and assurance

    Technical review of the high-consequence systems against the OWASP LLM Top 10, covering prompt injection, data leakage, excessive agency, and the model and dataset supply chain.

  4. 04

    Guardrails and monitoring

    Controls that survive contact with production: input and output handling, least-privilege tool access, evaluation sets, and monitoring that catches drift and misuse after launch.

What's delivered

  • AI management system aligned to ISO/IEC 42001
  • Risk assessment against the NIST AI Risk Management Framework
  • Threat modelling for LLM and agentic systems using the OWASP LLM Top 10
  • AI supply-chain risk review across models, datasets, and third-party dependencies
  • Guardrails, evaluation, and monitoring for production AI

Proof point

Active contributor to the New Zealand discussion on securing AI systems, bridging applied engineering and governance.

Common questions

Do we need ISO/IEC 42001 certification?
Usually not, at least not yet. Most organisations need the structure the standard describes rather than the certificate itself. Aligning to it gives you the governance and the evidence; certification is a separate commercial decision, normally driven by a customer requirement.
Isn't prompt injection just solved with a better system prompt?
No, and treating it that way is the common mistake. Instructions and untrusted data share a channel, so the model cannot reliably tell them apart. The practical defences are architectural: constrain what the model is allowed to do, keep a human in the loop for consequential actions, and treat every output as untrusted input to whatever consumes it.
We only use vendor AI, not our own models. Does this apply?
Yes, and often more urgently. You inherit the vendor's risk without visibility into it, and the integration you built around it is entirely yours. The inventory and the tool-permission review matter just as much when the model belongs to someone else.
How is this different from normal application security?
It builds on it rather than replacing it. The difference is that the system is non-deterministic, the trust boundary between instruction and data is blurred, and the supply chain now includes model weights and training data. Standard appsec remains necessary and stops being sufficient.

Other services

Get in touch

Let's talk about your security programme

Considering a vCISO, a security strategy and architecture, a SOC uplift, an AI assurance review, or a secure web build? Tell me where you are and where you need to get to.

Discuss an engagementaspera@antan.co.nzLinkedIn (opens in a new tab)