Classify AI by the data it can see, the actions it can take, and the potential blast radius if access is misused. A low-risk assistant and a decisioning system should not share the same approval path. Classification should drive logging depth, human review, and access restrictions.
How to classify AI use cases for security review
Classify AI use cases by the sensitivity of the data they can access, the authority they have to act, and the consequences if that access is misused. The right lens is not “AI” in general, but whether the use case can see protected information, trigger real-world actions, or amplify damage if it is compromised or misconfigured.
That means a read-only summariser, a customer-facing assistant, and an autonomous workflow tool belong in different security tiers even if they all use the same model. Security classification should shape approval depth, logging, human review, and the access model you allow around the use case.
Use a classification scheme that is simple enough to apply consistently, but strict enough to separate low-risk assistance from decisioning or action-taking systems. If the use case can influence financial, operational, legal, or customer outcomes, treat it as higher sensitivity than a passive content generator.
What dimensions should drive the classification?
The first dimension is data access. Identify what the system can ingest, retain, or expose, including prompts, uploaded files, connectors, memory, and downstream system outputs. A model that can only answer generic questions presents a different profile from one that can query HR records, source code, customer cases, or internal documents.
The second dimension is action authority. Determine whether the AI only recommends, or whether it can send messages, change records, approve requests, execute code, or call business systems. The moment a use case can take action, the approval path should include stronger controls on scope, approval, traceability, and exception handling.
The third dimension is blast radius. Ask what happens if the AI is manipulated, over-permitted, or fed malicious input. Where a failure could cause broad data exposure, fraudulent action, unsafe automation, or systemic disruption, the use case needs tighter guardrails than a narrow internal assistant. For deeper control planning, NHI Management Group’s AI Agent Identity Security Buyer's Guide helps teams evaluate the access model behind AI-enabled actions.
How should the classification change the control path?
Classification should drive which controls are mandatory, not just which team signs off. Lower-risk use cases can often rely on standard logging, restricted data scopes, and periodic review. Higher-risk use cases should require explicit ownership, stronger monitoring, tighter authorization boundaries, and a clear human intervention path when the system crosses from suggestion into action.
It is also useful to separate the approval of the model from the approval of the use case. A harmless model can be embedded in a high-risk workflow, and a high-capability model can still be acceptable in a tightly bounded role. The classification should therefore follow the business function and the access path, not the vendor label.
For practical policy design, NHIMG’s Agentic AI Security Policy Template is a useful reference point for separating registration, oversight, tool access, and retirement requirements.
Risk and Threat Considerations
Misclassification creates the most common failure mode: a low-friction pilot becomes a high-trust operational system without the corresponding controls. That exposes organisations to data leakage, over-automation, unauthorised action, and inconsistent oversight, especially when the AI has connectors or persistent access.
Failure mechanism: The system is approved as a generic productivity tool, then later gains access to sensitive data, tools, or decision workflows without a new security review. Over time, the blast radius expands faster than the control set.
Impact: Sensitive information can be disclosed, actions can be taken outside intended authority, and incident response becomes harder because the organisation never classified the use case at the level of access it eventually received.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI use cases change risk when they can act with delegated authority. |
| Recommendation — Limit agent authority and require explicit approval for privileged actions. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Classification should determine how much access an AI use case receives. |
| AU-2 — Event Logging | Higher-risk AI use cases need deeper logging based on data access and actions. | |
| IA-5 — Authenticator Management | AI use cases often depend on credentials and tokens that must be controlled by sensitivity. | |
| Recommendation — Constrain each AI use case to the minimum permissions needed. Log prompts, tool calls, and sensitive outcomes for higher-risk AI use cases. Rotate and protect AI credentials according to the use case risk tier. | ||
| ISO/IEC 42001:2023 | 4.2 — Understanding the needs and expectations of interested parties | AI use case classification should reflect governance expectations and impact boundaries. |
| Recommendation — Define approval tiers that match stakeholder expectations and risk tolerance. | ||
Practitioner Guidance
What to prioritise: Classify AI use cases by the highest-consequence thing they can touch, not by the model type. If the same system can both read sensitive data and trigger an action, classify it for the more dangerous mode.
What to verify: Confirm the actual connectors, prompts, memory, and action pathways in production, not just the intended design. Many control failures begin when a pilot quietly inherits broader access than the original approval assumed.
Practitioner takeaway: Good AI classification is an access decision with consequences, not a naming exercise; if the use case can see more, do more, or affect more, it needs stronger security treatment.