Standards, verification & maturity

Testing tells you what’s broken; standards tell you what “good” looks like, scoring tells you how bad a finding is, and maturity models tell you where an organization sits overall. An accredited assessor frames every finding against these - so this section closes the gap between “I ran a red-team” and “here is your verified posture, scored and benchmarked.”

The OWASP AI standards stack (2026)

AISVS requirement (concrete, testable)

AISVS C6 - Agentic security:
  6.1 Agent actions are constrained to an allowlist of tools and destinations.   [test]
  6.2 Irreversible / outbound actions require human approval.                    [test]
  6.3 Retrieved content is delimited and cannot enter the instruction channel.   [test]
# each line is verifiable -> feeds the engagement (II.20) and the maturity score (AIMA)

Standard	What it is / answers	Use it to
AISVS - AI Security Verification Standard	A catalogue of testable security requirements across the AI lifecycle (data → training → deployment → retirement), each at Level 1/2/3 of assurance. Modeled on ASVS; founded by Jim Manico.	Use as the verification checklist for a pen-test/audit, a CI/CD gate, and a procurement spec. The “what good looks like” layer.
AIVSS - AI Vulnerability Scoring System (v0.8)	A standardized way to score AI/agentic vulnerabilities - the CVSS-equivalent for AI, focused on agentic architectures.	Quantify and prioritize each finding’s severity so the report ranks risk, not just lists it.
AIMA - AI Maturity Assessment	A maturity-model lens for an org’s overall AI assurance posture; aligns to NIST/ISO/EU AI Act. V1.1 targeted Spring 2026.	Tell leadership where they sit and what the next level requires - the board conversation.
GenAI Red Teaming Guide	OWASP’s canonical six-phase red-team methodology for GenAI.	The named methodology the II.17 playbook follows; cite it for credibility.

How they fit together

Think of it as a chain an assessor walks: AISVS sets the requirements you verify against → an engagement (II.20) finds gaps → AIVSS scores each gap’s severity → AIMA rolls the picture up into a maturity level for leadership. For MCP specifically, pair these with the OWASP MCP Top 10 (II.6) - the protocol-level risk list. AISVS is explicitly not a governance or risk framework - it’s the technical control catalogue that NIST AI RMF, ISO/IEC 42001, and the EU AI Act (IV.1, IV.3) point to. Note these three (AISVS, AIVSS, AIMA) are fast-moving community projects at differing maturity, draft to early release, not settled standards - check each for current status before citing a version or date.

Maturity, concretely

A widely-used practitioner ladder runs Level 0 Unaware (no AI inventory - no one knows which models run in prod or what they can touch) → 1 Reactive (basic prompt filtering, incident-driven; reportedly where most organizations sit) → 2 Defined (AI asset inventory, written policy, quarterly red-teaming, human oversight before autonomous action) → 3 Managed (runtime monitoring of inputs/outputs/tool-calls, audited agent-to-agent interactions). Locating a client on this ladder, and naming the one move that raises them a level, is the highest-leverage advisory output you can give (IV.4).

The open-source red-team toolkit

Beyond Project Moonshot (II.20), the field standardized on two tools worth knowing by name: garak (a vulnerability scanner for LLMs - run it in CI for breadth) and PyRIT (Microsoft’s Python Risk Identification Toolkit - for adversarial depth). The 2026 pattern: garak in the pipeline for regression, PyRIT for deep adaptive probing, Moonshot for benchmarking and the Singapore Starter Kit, every finding mapped to OWASP + ATLAS and scored with AIVSS.

Where the regulators are heading

Two trajectories to track: NIST’s COSAiS (Control Overlays for Securing AI Systems - extending SP 800-53 to single- and multi-agent deployments, a likely basis for future FedRAMP AI requirements) and the agent-identity work (CAISI’s AI Agent Standards Initiative; the NCCoE concept pairing OAuth 2.0 + SPIFFE/SPIRE + MCP - III.2). The convergent deliverable that the EU AI Act, NIST AI RMF, and the GPAI Code of Practice all push toward is a single artifact: a Safety & Security Model Report documenting evaluation methodology, red-team conditions (who tested, with what access, for how long), and incident-reporting procedures. Build it as you go (II.20), not the week before the audit.

Cross-reference

Governance frameworks: IV.1. Singapore & EU: IV.3. The engagement that feeds these: II.20. The advisory roll-up: IV.4.

Running a maturity assessment (not just placing a dot on the ladder)

The ladder above (Unaware → Reactive → Defined → Managed) is the headline; a usable assessment scores it across dimensions so the output is a profile, not a single number, and the gap-to-next-level is concrete per area. Score each at L0-L3 with evidence, then name the one move that raises the weakest dimension:

Dimension	L0 Unaware → L3 Managed (what “good” looks like)
Governance & policy	No owner / no policy → named accountable owner, acceptable-use & data-classification policy, lifecycle gates
Risk management	Ad hoc → a repeatable AI risk assessment (§32), a risk register, a stated risk appetite
Data	Unknown sources → vetted, classified, provenance-tracked training/RAG data (§6, §17)
Model & development	Unscanned third-party models → signed provenance, model scanning in CI, MLBOM (§5, §16)
Deployment & monitoring	No agent telemetry → guardrails + tool-call logging in the SIEM, ATLAS-mapped detections (§26, §28)
Incident response	Treated as an IT outage → an AI-specific IR playbook, an agent-compromise tabletop (§28)
Third-party / vendor	No diligence → vendor AI due-diligence, contractual evidence, inherited-risk tracking

How to run it: gather evidence per dimension (artifacts, not assertions - a policy document, a populated risk register, a SIEM query that actually returns agent tool-calls), score conservatively (no evidence = the lower level), and produce a one-page profile plus a single prioritized move per dimension. That profile, the gaps scored with AIVSS (above), and the one next move per area is the board-ready output (§32).