Adoption percentage shows how widely a tool is used, but not how much sensitive data it handles or what level of privilege it carries. A small number of highly active agentic tools can create more exposure than a larger number of lightly used ones. Security teams need workflow-level metrics, not seat counts alone.
Why adoption percentage misleads AI security decisions
Adoption percentage only tells you how many people or teams can access a tool, not what the tool can reach, automate, or expose. For AI security, that is a poor proxy because risk concentrates in data sensitivity, action scope, integration breadth, and privilege. The same seat count can represent very different exposure depending on whether the system merely drafts text or can retrieve records, call tools, or execute transactions.
That distinction matters because AI systems often create risk through a small number of high-impact workflows rather than broad casual usage. A lightly used agentic assistant with access to production systems, customer records, or secrets can be far more consequential than a widely adopted note-taking assistant. NIST Cybersecurity Framework 2.0 is useful here because it encourages organisations to assess governance, asset context, and control effectiveness rather than rely on simplistic usage metrics alone. In practice, many security teams discover the real exposure only after an AI workflow has already been connected to sensitive systems, not when adoption charts first look reassuring.
What security teams should measure instead of seat counts
The better unit of analysis is the workflow, not the user population. Security teams need to know what data the AI can see, what actions it can take, which systems it can reach, and whether those actions are reversible, logged, and bounded by policy. Adoption percentage is a distribution metric; it says almost nothing about blast radius, privilege, or misuse potential. That is why a tool used by a handful of operators can still be a priority if it sits near production data, financial approvals, or identity systems.
In practice, teams should map AI usage to concrete control questions:
- What categories of data does the tool process, and are any regulated or confidential?
- Does the tool merely generate text, or can it call APIs, create changes, or trigger approvals?
- Are credentials, service accounts, or delegated tokens attached to the workflow?
- Can the workflow be segmented by environment, business function, or sensitivity level?
- Is there an audit trail that shows who used the tool and what it actually did?
For agentic systems, these questions become more important than adoption because autonomy and tool access expand the possible failure modes. A tool with low adoption may still concentrate risk if it is the bridge between an LLM and a privileged backend. CSA MAESTRO agentic AI threat modeling framework is relevant because it pushes teams to examine agent behavior, tool use, and trust boundaries rather than count users. The guidance breaks down when organisations cannot observe the downstream systems an AI can reach, because then usage volume stops telling you where exposure actually lives.
Where adoption percentage is still useful, and where it is not
Tighter metrics often increase reporting overhead, requiring organisations to balance simplicity against operational truth. Adoption percentage still has value for change management, licensing, training uptake, and broad governance trends. It can show whether a programme is spreading, whether policy exceptions are growing, or whether a sanctioned tool is replacing shadow AI. But it is weak as a standalone security measure because it collapses very different exposure profiles into one number.
The main edge case is low-risk, low-privilege AI usage. If a tool is limited to public content generation, no sensitive data, and no external actions, seat count may be an acceptable coarse indicator for programme oversight. The opposite edge case is the small, embedded workflow: a narrowly adopted system inside finance, support, devops, or identity operations may deserve more attention than a company-wide chatbot. That is where usage data, permission scope, and data-classification context need to be read together. For organisations assessing vendor claims about “safe adoption,” the useful question is not how many users have touched the tool, but which workflows it controls and what happens if those workflows are abused or compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA MAESTRO and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 — Organisational Context | AI risk depends on workflow context, not user counts. |
| PR.AA-01 — Identity and Access Management | Privilege scope drives exposure more than seat counts. | |
| DE.CM-01 — Continuous Monitoring | Usage metrics must be paired with visibility into actual actions. | |
| Recommendation — Assess AI workflows by asset criticality and exposure, not by adoption alone. Bound AI access to the minimum permissions needed for each workflow. Monitor AI actions and data access to validate the real risk profile. | ||
| CSA MAESTRO | T1 — Agentic Threat Modeling | Agentic risk is defined by tool use and trust boundaries. |
| Recommendation — Model each agent workflow for data access, tool reach, and failure paths. | ||
| MITRE ATLAS | AML.TA0002 — Reconnaissance | AI exposure can arise from how systems are accessed and discovered. |
| Recommendation — Map AI-enabled attack paths to exposed tools, data, and actions. | ||
Practitioner Guidance
What to prioritise: Start with the workflows that combine sensitive data, external connectivity, and write access. Those are the places where adoption counts most often understate exposure, because a small user base can still own a large share of the blast radius.
What to verify: Confirm whether the AI system can only recommend actions or can also execute them. Verify the actual permission boundary, the identity under which it acts, and the systems it can touch, because those facts matter more than the number of active users.
What good looks like: A security owner can explain risk by workflow category, privilege level, and data sensitivity, not by seat count alone. The organisation should be able to distinguish a high-adoption, low-risk use case from a low-adoption, high-risk one without guesswork.
Common mistake: Treating adoption percentage as a proxy for threat exposure. That shortcut usually hides the most important question, which is whether the AI is connected to the wrong data or the wrong authority.
Practitioner takeaway: Security risk follows privilege, data, and action scope more than popularity, so adoption percentage should be treated as a programme metric, not a control metric.
Related resources from NHI Mgmt Group
- How should security teams measure whether AI is helping rather than hiding risk?
- How do teams decide whether AI adoption is increasing security risk or improving control?
- Why does AI adoption increase burnout risk in security teams?
- How should security teams measure human cyber risk across employees and AI agents?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
