Notifications
Clear all
Topic starter
25/08/2026 9:13 am
TL;DR: The AI security maturity model problem is not the framework itself but the reliance on self-report, because visibility is the first thing being scored and survey data shows 90% of organizations claim AI visibility while 59% still confirm or suspect shadow AI, according to Cycode. The practical fix is to bind every maturity claim to a retrievable artifact, then score only after discovery, baselining, and enforcement.
NHIMG editorial — based on content published by Cycode: 5 AI Security Maturity Models Compared (2026)
By the numbers:
- In Cycode's research, every one of 400 surveyed organizations confirmed AI-generated code in its codebase, while only 19% claimed complete visibility into where and how AI was being used.
Questions worth separating out
Q: How should security teams govern AI adoption when maturity scores look better than reality?
A: Security teams should anchor AI governance in identity and access controls, not self-assessed maturity.
Q: Why do AI maturity models fail when they rely on self-assessment?
A: Self-assessment fails because the first thing being measured is visibility, and AI environments are often only partially visible.
Q: What do organisations get wrong about AI-generated code as a control signal?
A: They often assume that clean-looking code or a passed review means the code is safe.
Practitioner guidance
- Bind each maturity claim to an artifact Require a retrievable artifact for every scored statement, such as an AIBOM export, agent attribution report, or blocked-policy log.
- Score only after discovery and baselining Run a 90-day sequence that starts with discovery of assistants, models, MCP servers, packages, and AI secrets, then establishes your own repository baseline, and only then applies a maturity score.
- Treat AI-connected identities as governed assets Inventory non-human identities, delegated tool permissions, and secret-bearing workflows alongside AI systems so that access ownership, authorisation state, and revocation paths are explicit.
What's in the full article
Cycode's full analysis covers the operational detail this post intentionally leaves for the source:
- The comparison logic between the five AI security maturity models and the specific questions each one is best suited to answer.
- The artifact-by-artifact scoring method, including the evidence expected for inventories, attribution baselines, and enforcement claims.
- The 90-day discovery, baselining, and enforcement sequence for turning a maturity rubric into something auditable.
- The vendor's own research context, including codebase visibility data and the implications for product security teams.
👉 Read Cycode's analysis of why AI security maturity models need evidence, not self-report →
AI security maturity models: what evidence should teams score?
Explore further
25/08/2026 9:14 am
AI maturity models are increasingly measuring governance theatre, not security maturity. When a scoring model relies on self-report, it rewards confidence and documentation quality more than actual control strength. That is tolerable in stable environments, but AI changes quickly and visibility is often partial, so the score becomes a summary of optimism. Practitioners should treat any maturity model as a hypothesis until it is backed by artifacts.
A question worth separating out:
Q: Who should own AI governance when AI touches identity and access?
A: Ownership should sit with the team that can explain the AI system’s access, purpose, and operating boundaries end to end. In practice, that means AI governance must connect security, IAM, data, and engineering accountability so the system is not treated as a floating experiment. If ownership is unclear, lifecycle control will be inconsistent.
👉 Read our full editorial: AI security maturity models are grading the wrong evidence
