How do organisations decide whether an agent session is acting as a user or as an app?

Why This Matters for Security Teams

Session classification is not a cosmetic identity problem. If an organisation misreads an agent session as a human user, it may grant interactive permissions, weaker monitoring, or the wrong approval path. If it misreads a user-originated flow as an app, it can break accountability and create blind spots in incident response. The practical issue is that agentic and delegated flows often carry mixed signals, so the right question is not "what does the token look like?" but "what trust chain produced it?" That framing aligns with current guidance in the OWASP Agentic AI Top 10 and with NHI governance research from Ultimate Guide to NHIs. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of visibility gap that makes session attribution unreliable.

In practice, many security teams discover the attribution problem only after a delegated token has already been used to move further than anyone expected.

How It Works in Practice

Effective classification starts by correlating the full identity path rather than trusting a single claim. Teams should inspect idtyp to understand the token class, appid to identify the application that requested the session, oid to anchor the principal, scp to see what permissions were actually granted, and the token exchange path to determine whether the session was minted through user delegation, workload authentication, or an intermediary broker. That approach is consistent with the direction of the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasise context, provenance, and runtime evaluation.

• If the token originated from a human login but was exchanged by an app, treat it as delegated user activity, not as a pure app identity.
• If the session was issued to an autonomous agent, prefer workload identity and short-lived credentials over long-lived shared secrets.
• If scp exceeds the user’s normal entitlements, investigate whether the app widened access during token exchange.
• If the token chain crosses multiple brokers, verify which principal is accountable for each hop.

For agentic systems, this also means relying on runtime policy and not static role assumptions. A session may begin with a user, continue through an app, and then be executed by an AI agent that chains tools autonomously. That is why related NHIMG research on the OWASP NHI Top 10 and incidents such as CoPhish OAuth Token Theft via Copilot Studio are so relevant: they show how identity shape alone can be misleading when execution authority is delegated dynamically.

These controls tend to break down in federated SaaS environments with nested token exchange, because lineage is often fragmented across providers and logging is incomplete.

Common Variations and Edge Cases

Tighter session attribution often increases engineering and operations overhead, requiring organisations to balance stronger accountability against slower troubleshooting and more complex policy logic. There is no universal standard for this yet, especially for multi-tenant apps, AI copilots, and cross-domain delegation chains, so current guidance suggests documenting decision rules explicitly rather than assuming the platform will infer intent correctly.

Edge cases matter. A service account may present a user-like token during an on-behalf-of flow. A browser session may carry app-scoped claims while still being initiated by a human. An autonomous agent may inherit a user’s permissions temporarily but execute actions that the user never directly intended. In those cases, the safest interpretation comes from the relationship chain plus real-time policy, not from a binary user-versus-app label. That is especially important when organisations use long-lived tokens, broad scopes, or shared service principals, all of which can blur accountability and weaken revocation.

For deeper context on why these chains become exploitable, see NHIMG analysis of the Analysis of Claude Code Security and the external threat perspective in MITRE ATLAS adversarial AI threat matrix. In mixed human-agent environments, the classification rule has to be conservative: if provenance is unclear, treat the session as delegated until the chain is proven otherwise.

Related resources from NHI Mgmt Group

• When should organisations treat an AI agent as a privileged system?
• How can organisations tell whether an AI agent is acting outside its intended scope?
• How do organisations prevent AI agent access from outliving the user session?
• How do organisations decide whether an AI agent should be allowed to act autonomously?