> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Oleria assigns NHI ownership

> How Oleria decides who owns a non-human identity (NHI) - the evidence it looks for automatically, when a human reviewer gets involved, and what happens if nobody acts in time.

Every non-human identity (NHI) - a service account, API key, bot, managed identity, or AI agent - needs an accountable owner behind it. An unowned NHI is a credential nobody is watching: nobody notices if its access grows, nobody rotates it, and nobody answers for what it did. The **NHI ownership assignment** workflow closes that gap for the applications you turn it on for, through three stages: automatic detection, human review, and an optional time-bound fallback.

## Automatic signal detection

Oleria first looks for direct evidence of ownership in your connected applications. It checks a fixed set of signals in priority order, from strongest to weakest, and stops at the first priority level that identifies an owner - it does not fall back to a weaker guess once a strong signal is found.

| Signal | What it means |
| :- | :- |
| Source owner (shown on owners as "Owner assigned by source system") | The application already records an explicit owner for this identity - a user, group, or role. |
| Creator (shown on owners as "Created by this user") | The application records which user created the identity. |
| Group or role owner (shown on owners as "Manages its group or role") | A user owns a group or role the NHI belongs to, including through nested groups. If the owner is itself a group or role, its members are credited. In Microsoft Entra ID, if the group has no owner, Oleria credits the Groups Administrator role (then Application Administrator); for a role with no owner, the Privileged Role Administrator role. |
| Administers its Google Cloud resource (Google Cloud only) | A user holds an administrative IAM role on the project, folder, or organization that contains the service account. Google Cloud uses this in place of group or role ownership. |
| Delegated access (shown on owners as "Can act as this user") | The NHI has permission to act on behalf of this user - for example, through delegated access or impersonation rights. When the delegation is OAuth-based rather than tied to one specific person, Oleria credits the application's admins instead. |
| Microsoft Entra ID admin role (Microsoft Entra ID only) | For Microsoft internal applications, managed identities, and Entra agent identities, Oleria credits members of the Entra role that administers that kind of identity: Application Administrator, Cloud Application Administrator (then Application Administrator), or Agent ID Administrator. |
| User name match with NHI (shown on owners as "Matching name") | The NHI's name contains, or is contained in, the name of a user account in the same application (ignoring case). |

Not every signal applies to every application. Signals marked for one provider only run for identities from that provider, and Google Cloud service accounts don't use "Can act as this user."

> [!NOTE]
>
> If a signal points to an account that is disabled, or has had no activity for longer than your workspace's dormant account threshold, Oleria assigns that person's manager instead. The manager comes from your HR or identity provider data and must have an enabled account in the same application. If there's no such manager, that signal doesn't produce an owner and Oleria moves on to the next signal.

A single clear signal is enough to assign ownership - Oleria doesn't require multiple signals to agree. If a signal, or several signals at the same priority level, identify more than one person, Oleria assigns all of them as owners - for example, every admin of the application when access is delegated through OAuth.

## Manual review when no signal is found

If none of the applicable signals identify an owner, what happens next depends on the application. If the application has its own ownership settings, the NHI is routed to the reviewers configured there - a specific reviewer, or an admin, group, or role. If it doesn't, the NHI stays unowned and Oleria checks it again on its next daily run.

If more than one reviewer is assigned, the first decision made resolves the review and closes any other pending reviews for that NHI.

> [!NOTE]
>
> Oleria keeps checking for signals in the background while a review is pending. If a clear signal appears before a reviewer acts, the NHI is assigned automatically and the pending review closes on its own.

## Fallback assignment when the review period expires

If you've enabled fallback assignment for an application, reviewers have a set number of days to act. If a review isn't completed within that window, ownership is assigned automatically to the fallback owner configured for that application - an admin account, a specific account, a role, or a user group.

This assignment is recorded as a system action, distinct from a human reviewer's decision, with the reason logged as the review period expiring without a decision. If no fallback owner is configured for an application, the NHI stays unowned rather than being assigned to an arbitrary default.

See [NHI ownership assignment](https://docs.oleria.com/posture/nhi-ownership-assignment-workflow.md) for how to configure this workflow.

## Contact us

For questions, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.