Blog

The thinking behind AI security review.

Threat models, governance evidence, and the decisions that hold up under scrutiny. Written for security architects and the committees they report to.

Newsletter

New posts in your inbox,
when they publish.

Threat modeling, governance evidence, and what AI Committees actually need — written for security architects and AI governance leads. No cadence promises.

No spam. Unsubscribe anytime.

Technical11 min

Access control for RAG — keeping retrieval inside the line

RAG pipelines retrieve documents and pass them into a model context that the user then queries. Access control must operate at retrieval time, not just at query time — or users can extract documents they would not be permitted to read directly.

Reference13 min

The ISO 42001 Annex A controls, in plain language

ISO 42001 Annex A defines the controls for an AI management system. This walkthrough takes each control domain, explains what it means in practice, and maps the evidence that demonstrates conformance.

Technical11 min

Tool-use permissions for agentic AI — least privilege for agents

The tool manifest of an agentic AI system defines what the agent can do in the world. Most manifests are over-provisioned. Least privilege for agents means auditing the tool manifest for each deployment scope and removing capabilities the task does not require.

Regulation12 min

High-risk AI obligations under the EU AI Act

High-risk AI systems under the EU AI Act face a set of specific obligations: risk management, technical documentation, data governance, transparency, human oversight, and accuracy. This piece maps each obligation to the evidence that satisfies it.

Technical11 min

Insecure output handling — the LLM risk teams underrate

Teams spend significant effort hardening the input to an LLM and very little hardening what the LLM outputs. Insecure output handling is how prompt injection becomes code execution, data exfiltration, or stored injection.

Foundations9 min

When to run an AI security review — the four trigger points

Not every change to an AI system warrants a full review, but some changes that seem minor do. This piece defines the four trigger points that should initiate a review: initial deployment, model change, scope expansion, and incident.

Regulation11 min

A DPO's guide to AI systems in the organisation

Data Protection Officers are increasingly asked to sign off on AI systems. This guide maps the data-protection risks specific to AI — training data, inference data, model outputs, and retention — and the review questions a DPO should ask.

Reference12 min

Govern, Map, Measure, Manage — the NIST AI RMF functions in practice

The four functions of the NIST AI RMF are well defined in the framework document but underspecified in practice. This piece walks through each function with examples from AI security reviews — what evidence each function produces and how they connect.

Reference10 min

Assessing the AI feature inside SaaS you already bought

Enterprise SaaS vendors are adding AI features to products organisations already trust. Those features introduce new AI risks that the original vendor assessment did not cover. This piece defines the supplemental review for embedded AI.

Governance10 min

AI risk acceptance — who actually signs

Risk acceptance for AI systems is often attributed to a committee rather than a named individual. When something goes wrong, no one is accountable. This piece defines who should sign risk acceptance for AI systems and what that signature requires.

Reference11 min

ISO 42001 vs ISO 27001 — what is new for AI

Organisations that already hold ISO 27001 certification often ask how much ISO 42001 adds. The answer depends on how much AI the organisation operates. This piece maps the new requirements and the areas where 27001 controls can be extended rather than replaced.

Technical11 min

Tool poisoning in MCP servers

MCP tool poisoning is the attack where a malicious tool description manipulates the model into invoking tools or revealing data outside its intended scope. The attack surface is the tool manifest — every tool description is untrusted input.