Skip to main content

​
Background

Before you can govern non-human identities, you need to trust the line between “human” and “non-human.” Misclassification cuts both ways: a contractor flagged as a service account gets skipped in offboarding, and a service account treated as a person pollutes Access Reviews. This article explains where classification appears in Lumos, what drives it, and what to do when an identity is classified incorrectly. Related: Managing Identities · NHI Inventory · Identity Agent Force Overview · Get Started with Agentic Access Reviews

​
Where classification appears

  • Identities page. The Identities tab splits identities into Human, Non-human, and Uncategorized tabs, and shows each identity’s type. You can filter and save views on type, for example a “Service accounts” view.
  • NHI Inventory. Identities discovered through your NHI connectors appear at Identities → Non-Human Identities, each with an Identity Type: AI Agent, Service Identity, Application Identity, or Service Account. See NHI Inventory.
  • Access Reviews. AI review insights include a Non Human category that flags service accounts and other non-human identities, so reviewers can apply different scrutiny.
  • Identity Agent Force findings. Agents distinguish identities your tenant owns from vendor-managed and first-party service principals, and exclude the latter from findings to reduce noise.

​
What drives classification

​
Human identities

  • A user pulled from any integration you have set as a User Source is categorized as a human identity by default. See Importing User Sources.
  • Lumos normalizes human identities to Full Time, Part Time, Contractor, Intern, Freelance, or Other (human) by keyword matching on the source’s standard identity type field.
If the field is empty or Lumos doesn’t know the source’s standard field, the type shows as Other.

​
Non-human identities

  • Lumos also reads the integration’s standard identity type field to categorize identities as non-human. These can come from User Sources or any other integration.
  • Non-human identities are normalized to Service Account (automated accounts for programmatic access, system operations, and API integrations) or Other (Non-human) (distribution lists, security groups, shared mailboxes, resource accounts, and similar).

​
Uncategorized identities

Anything Lumos can’t auto-identify as human or non-human lands in Uncategorized.

​
NHI Inventory types

For identities from NHI connectors, Lumos assigns the type from what the source reports and how the identity is configured. For example, an Entra app registration with a client secret is a Service Identity, and a CI pipeline that assumes an AWS role with a short-lived token is an Application Identity. When the source doesn’t give enough signal, Lumos uses Service Account.

​
Correcting a misclassification

​
Limitations

  • Contractors and external collaborators who aren’t in a User Source are the most common misclassification. Connecting all worker types to a User Source improves accuracy.
  • Classification depends on what the source reports. Identities from sources with an explicit type field classify more reliably than ones Lumos has to infer.
Questions? Contact your Lumos account team or open a support ticket.