How should teams classify AI systems before applying access controls?

How to classify an AI system before access controls are applied

Start with what the system can actually do at runtime, not the marketing label. A read-only assistant, a workflow runner, and a tool-using agent create different trust boundaries, so they should not inherit the same access model. The practical question is whether the system merely responds, or whether it can initiate actions that affect data, services, or other identities.

That distinction matters because access control is not just about who can log in, it is about what the system is allowed to do once authenticated. If the system can execute actions, choose tools, or delegate work, its permissions, approvals, and audit expectations should be treated like an operational identity with bounded authority. The classification should therefore follow autonomy, scope, and blast radius.

Useful labels are operational, not decorative. A chat interface may sit in front of the same model as an agentic workflow, but the control posture changes when the system can retrieve data, trigger transactions, or chain services without a person reviewing every step. Teams should classify by the strongest authority the system can exercise, then constrain everything below that level.

Which capabilities should change the control model?

The key capability tests are whether the AI system can select an action, invoke a tool, or continue a task across steps. If it can only generate text or recommendations, treat it as a decision-support component. If it can call APIs, move data, or make state changes, then it needs tighter access boundaries, stronger approval logic, and fuller logging because the risk is no longer limited to the content it produces.

Tool reach is often the clearest dividing line. Systems that can read from internal sources, write to business systems, or hand off to downstream automations should be reviewed for privilege, session scope, and delegation path. That is the same reason teams should use the Authorisation Models Guide when deciding whether policy should be role-based, attribute-based, or relationship-based around AI actions.

The classification should also account for human delegation. When a person authorises the system to act on their behalf, the system is no longer just a user interface. It is exercising borrowed authority, so teams need to decide whether the delegation is narrow, time-bound, and reversible, or whether it creates persistent access that outlives the task.

What controls follow from a higher autonomy classification?

Once a system can act, controls need to cover identity, approval, and traceability together. That means the system should have its own account or service identity, explicit entitlements, and logs that show both the triggering context and the action taken. If the system can reach production systems, the team should treat credential scope and approval gates as first-class design choices, not implementation details.

Teams often need to align this classification with access governance and lifecycle management rather than with the model itself. The control question is who can grant the system access, who can approve exceptions, and how access is removed when the use case ends. The IAM and IGA Basics resource is useful here because the same provisioning, review, and revocation discipline applies when the actor is a machine or agent rather than a person.

For systems that can touch business data or privileged actions, teams should also classify the exposure as an access-control problem, not just an AI safety problem. If the system can select objects, invoke functions, or pass credentials into downstream services, its failures can become authorisation failures. That is why the Broken Access Control Prevention Guide is relevant whenever an AI system can cross trust boundaries on its own.

Practitioner Guidance

What to verify: Confirm the system’s actual runtime permissions, not the permissions the vendor documentation implies. Test whether it can read, write, trigger, approve, or forward actions across systems, because those capabilities determine the control model more reliably than the product category.

Decision rule: If the system can only answer questions, classify it as an informational control surface. If it can choose actions or call tools, classify it as an operational actor and require explicit approval paths, narrower entitlements, and auditable decision traces.

What good looks like: Each AI system has a documented authority profile that matches its real capabilities, with short-lived access where possible, separate identities for separate functions, and logs that make the acting context reconstructable after the fact.

Common mistake: Teams often grant broad access because the system is “just an assistant” at launch, then discover it has become a de facto automation layer. That is usually when overbroad entitlements, weak approval flows, and poor attribution show up together.

Practitioner takeaway: Classify AI systems by the authority they can exercise, because autonomy determines whether you are governing a conversational interface or a bounded operational identity.

Related resources from NHI Mgmt Group

• How should security teams test privileged access controls against AI agents before they are exposed to production systems?
• What should security teams check before extending access controls to autonomous systems?
• How should security teams classify AI agents before writing controls?
• What should teams prioritise first: guardrails, observability, or access controls for AI systems?