Start with observed runtime access, not intent. If the agent can reach data or systems that trigger mandatory breach reporting, exam scrutiny, or regulatory notification timelines, Track 2 is the safer assumption. If the agent is read-only and stays outside regulated data classes, Track 1 is usually defensible.
How to classify an AI agent by runtime access, not by label
Track 1 and Track 2 should be decided from what the agent can actually do at runtime. A harmless-sounding agent can still belong in Track 2 if it can touch regulated data, trigger reportable events, or act through credentials that create material business or compliance exposure. That makes the question one of observed authority, not product category.
The practical test is whether the agent’s current permissions and reachable systems create an obligation or consequence that the organisation would have to defend if something went wrong. A read-only helper with tightly bounded scope is usually easier to keep in Track 1, but any path into sensitive data or operational systems moves the decision toward Track 2.
What evidence should decide the track assignment?
Use concrete runtime evidence: granted scopes, reachable APIs, session context, data classes, write actions, and downstream effect. If the agent can initiate actions on behalf of a user, alter records, or observe information protected by legal or regulatory handling rules, the track decision should follow that exposure. If the access is truly limited to non-sensitive reading and non-privileged browsing, Track 1 is often supportable.
That means teams should document what the agent can reach today, not what the vendor says it was designed to do. Design intent is useful, but it is not the deciding factor when you are classifying operational risk, because permissions drift, integrations change, and a previously benign workflow can become high impact once it is connected to live systems.
When teams want a broader way to frame that decision, AI Agents vs Agentic AI is useful because it maps autonomy and access to the way risk changes at each stage. For a stricter control viewpoint, AI Agent Authorisation Guide helps teams tie the classification to least privilege and per-action approval rather than vague “assistant” language.
Why sensitive access usually pushes an agent into Track 2
Track 2 is the safer assumption whenever the agent can reach data or systems that would change your breach, incident, or notification posture. The key issue is blast radius: once the agent can read regulated data, write to production, or use delegated credentials, a failure becomes a reporting and containment problem rather than a simple workflow defect.
That is why even a narrow-looking agent can be high risk if it can cross a boundary into records that carry mandatory notification timelines or exam scrutiny. The point is not whether the agent is “AI” or “automation”; it is whether its access path can create obligations that would not exist with a purely read-only, non-sensitive tool.
The same logic is why runtime visibility matters. A team that cannot show which systems the agent can reach, which account it uses, and which actions it can complete should assume the track decision is not yet stable. If the answer depends on hidden or inherited access, the classification is likely too optimistic.
For a control-focused treatment of those access boundaries, Zero Trust for AI Agents reinforces the idea that standing privilege should be removed and every action should be verified. AI Agent Observability, Audit and Incident Response Guide is the natural companion when teams need evidence of what the agent actually did and whether the access was contained.
Practical track decisions for teams
Track assignment should follow a simple rule: if the agent can only observe low-risk information and cannot materially change state, Track 1 is often reasonable; if it can reach regulated, sensitive, or operationally consequential assets, Track 2 is the safer default. That rule works best when it is reviewed after every permission change, new integration, or prompt/tool update.
Teams should also be careful not to overfit on the name of the agent or the user experience. A polished chatbot can still be a privileged workflow entry point, while a narrow internal helper may become a Track 2 issue the moment it is given a token, a write API, or access to a sensitive reporting system.
The most useful operating model is to treat the track as a living control decision. Reassess when the agent gains new tools, new data visibility, new delegated authority, or a broader session context. That keeps the classification aligned to real exposure instead of to the original project charter.
What to prioritise: base the decision on observed runtime access, then re-check it whenever the agent’s permissions or integrations change.
What to verify: confirm the exact data classes, systems, and write paths the agent can reach, and whether any of them trigger breach reporting or regulatory handling obligations.
Practitioner takeaway: Track 1 is a low-exposure designation, not a label you keep once an agent gains meaningful access. If the access path can create regulated impact, default to Track 2 until you can prove the blast radius is genuinely limited.
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 and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agent track hinges on runtime authority and access scope. |
| ASI02 — Tool Misuse | Track 2 risk rises when an agent can misuse tools or APIs to change state. | |
| Recommendation — Limit agent permissions and require per-action authorization for sensitive operations. Constrain tools to the minimum actions needed and block unsafe tool chains. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Track decisions depend on whether the agent has excess runtime access. |
| AU-2 — Event Logging | Track 2 decisions need evidence of what the agent did and when. | |
| Recommendation — Reduce agent permissions to the minimum access required for the task. Log agent actions, access events, and sensitive decisions for auditability. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Runtime access and continuous verification are central to deciding agent track. |
| Recommendation — Verify every agent request and remove standing trust from access decisions. | ||
Related resources from NHI Mgmt Group
- How should security teams decide whether an AI agent gets human or non-human identity?
- How do security teams decide whether an AI agent should keep access to regulated data?
- How do teams decide whether an AI agent needs human approval?
- How do security teams decide whether an AI agent needs PAM-style controls?