Introduction

Six controls built around the OWASP Top 10 for LLM applications. Unlike the other three packs this one is not derived from a regulation or a management standard — it comes from a community list of how these systems actually get attacked. That gives it a different character: it is the most concrete pack, and the most obviously useful on day one.

Where to find it

AI Governance > Policies > System Policies > OWASP.

The six controls

Note: Packs are maintained content, not fixed product surface. The list above was read from the product and may change as the pack is updated, and the OWASP list itself is revised periodically. The pack's own Controls tab is always the current list.

Six controls, ten risks

The list has ten entries and the pack has six controls, so it does not cover all of them — and the gaps are not arbitrary. Some of the ten are not runtime-detectable at all.

For the full ten with the reasoning on each, see The Ten Risks.

Two controls attack hallucination from opposite ends

This is the most interesting pairing in any of the four packs, and it is worth studying before you write your own output checks:

• Fabricated or unverifiable citations is general. Any claim attributed to a source that does not support it. It applies to any agent that cites anything.

• Fabricated delivery estimates is specific. One domain, one kind of claim, one kind of harm.

The general one has broad reach and, inevitably, more false positives. The specific one is precise and only helps if you are in that business. The pack ships both deliberately — and the lesson for authoring is that the most useful hallucination control you will write is the specific one about your own domain, not another general one.

"You cannot check for 'wrong'. You can check for a claim your business knows how to be wrong about."

This one is a checklist, not a standard

The OWASP Top 10 is an awareness document maintained by a community. There is no certification, no audit scheme, and nobody to be compliant with. It is revised periodically, and entries move.

That makes it the best pack to start with and the wrong one to report with. Start here because the risks are concrete and the controls are immediately meaningful. Report with ISO or the Act, because those are what an auditor or regulator recognises.

Three of the six are shared

Validate tool output before downstream execution is also in ISO 42001, Block financial transaction tools is also in ISO 42001, and Flag jailbreak / role-play override attempts is also in NIST AI RMF — the same control objects. The three custom output checks are unique to this pack.

Adopting it

1. Adopt this one first if you are starting from nothing — Its risks are real, current and easy to explain to an engineering team. It builds the operational habit before you take on a framework with reporting obligations.

2. Replace the two domain-specific controls — Delivery estimates and financial transaction tools are examples. Substitute the equivalent claims and irreversible actions for your own business.

3. Expect the citation control to be noisy at first — A general hallucination check on real traffic finds a lot, and not all of it is wrong. Budget for a tuning period — see Tuning Policy Noise.

4. Do not treat the uncovered risks as absent — Supply chain and data poisoning are not covered because they are not runtime-detectable, not because they do not apply to you.

Operationalizing the OWASP Top 10

• OWASP LLM Top 10 Overview

• The Ten Risks

• Operationalizing in UnifyApps

Related

• ISO 42001 Pack

• Custom (LLM check)

• Prompt Injection check