Compliance
AIControls maps your active policies to five AI security and regulatory frameworks and reports, control by control, which ones a policy covers. The Compliance page turns that into an actionable gap list for security reviews, vendor questionnaires, and audits.
The five frameworks
Coverage is reported against all five at once. Each has its own tab on the Compliance page:
| Framework | Version | Controls | What it covers |
|---|---|---|---|
| OWASP LLM Top 10 | 2025 | 10 | The application-security risks specific to LLMs — prompt injection, sensitive information disclosure, excessive agency, unbounded consumption. |
| OWASP MCP Top 10 | 2025-beta | 10 | The risks specific to the Model Context Protocol — token mismanagement, tool poisoning, intent flow subversion, unapproved MCP deployments. |
| MITRE ATLAS | 2024 | 5 | Adversary techniques against AI systems, expressed as ATLAS technique IDs. |
| NIST AI RMF | 1.0 | 8 | The US risk-management standard, organized under the Govern, Map, Measure, and Manage functions. |
| EU AI Act | 2024 | 5 | The obligations for high-risk AI systems — risk management, data governance, transparency, human oversight, and robustness. |
That is 38 controls in total. For the full list with the identifier and description of each, see Compliance Controls.
Coverage comes from your policies
A control is covered when an enabled policy declares that it covers it. Nothing is inferred from which capabilities you have switched on — a policy has to name the control.
Policies declare their framework mapping in an annotation, proxy.nirmata.io/frameworks, whose value is a comma-separated list of framework:control pairs:
metadata:
annotations:
proxy.nirmata.io/frameworks: "owasp:LLM07,nist:GV-1.2,eu-ai-act:Art.14"
The framework identifiers are owasp, owasp-mcp, mitre, nist, and eu-ai-act. The control identifier is the one in the reference table — LLM07, GV-1.2, Art.14, AML.T0012, MCP-03.
One policy names at most one control per framework. The annotation is read as a framework-to-control map, so a value such as nist:GV-1.2,nist:MG-3.1 keeps only the last nist entry. To cover two controls in the same framework, annotate two policies.
The policy packs AIControls ships already carry these annotations, so installing a pack raises coverage without your writing anything. A policy you write yourself contributes to coverage only once you annotate it.
A disabled policy contributes nothing. Coverage is recomputed from your loaded policies, so enabling, disabling, or re-annotating a policy changes the numbers immediately.
The three coverage states
The distinction that matters is between a policy that stops something and a policy that merely records it:
| Status | Meaning |
|---|---|
| Covered | At least one enabled policy naming this control is configured in Enforce, Approval, RequireApproval, or WarnApprove mode. This is configuration coverage, not a recorded outcome. |
| Audit only | An enabled policy names this control, but none is configured in one of the covered modes. |
| Not covered | No enabled policy names this control. |
Coverage reports configuration, not operating effectiveness. Neither Covered nor Audit only proves that a request was evaluated, blocked, held or recorded. Verifying those outcomes requires recorded evidence associated with the applicable policy revision and scope.
The page header totals covered and audit-only controls across all five frameworks, and each tab reports its own counts. Within a tab you can filter to just the covered, audit-only, or not-covered controls.
Reading a control
Each control card names the configured policies mapped to it. Select Mapping & evidence to see the mapping source and limitations. Runtime scope, observation period, policy revisions and recorded outcomes are not included in this mapping. Policy names alone do not prove that a control was met.
A control no policy names is not necessarily a risk you are carrying — some controls in these frameworks concern training data, model development, or organizational process that a runtime governance proxy has no visibility into. Read the not-covered list as "AIControls has no evidence for this", not as "this is unmet".
The reverse holds too. Several controls are broader than anything a proxy observes, so a covered verdict is evidence for the aspect AIControls can see rather than a determination on the whole control. The EU AI Act's data governance article is the clearest example: the shipped prompt-scanning policy maps to it because data flowing into a model is a data-governance concern, but the article also covers how training and validation data is managed, which happens well before any request reaches AIControls.
Kyverno policies aren't mapped to frameworks
This mapping covers AIControls policies only. Kubernetes posture has no configurable mapping from Kyverno policies to compliance standards: it groups Kyverno results by policy category, and you choose which Kyverno policies count in Settings → Workloads. See Kubernetes posture.
The one exception is the workload compliance evidence export. It includes one item per Kyverno policy category and cites every such item, whatever its category, as evidence for the same fixed EU AI Act controls: Art. 9 and Art. 15.
See also
- Compliance Controls — every control in all five frameworks.
- Generate a Compliance Report — closing gaps and exporting coverage.
- Export workload compliance evidence — one workload's governance scorecard and posture evidence, mapped to the EU AI Act and the OWASP Top 10 for Agentic Applications.
- Install policy packs — the shipped policies that already carry framework annotations.
- Write a policy — annotating a policy you wrote yourself.