Scripts and services on the Manager API, on your list only
Scripts and services use the Manager API only with an Entra application that a SuperAdmin lists and a second SuperAdmin approves, as Reader or Admin.
Purpose
Integrations need an identity of their own, but an application with standing write access to privileged access is a risk of its own.
Design
The list of API applications is off - empty - by default. Adding an application, with the Reader or Admin role it gets, is a request that a different SuperAdmin approves. An application reads, prepares changes and runs jobs; a person saves every change, and the audit trail shows both. Changes that create accounts or grant access are never open to an application.
Business opportunities
Your ticketing and reporting systems connect to the Manager without a shared password, and nothing they prepare reaches your tenant without a person.
Related features
PIM policy changes wait for a SuperAdmin
A policy run plans its changes and holds them until a SuperAdmin approves that exact change set, with the setting that weakens protection marked.
Changes only what you define - deleting an account is a person's decision
The engine changes groups, roles and admins only when your data defines them, does not disable, revoke or offboard your break-glass accounts, and does not delete a user account on its own.
Emergency access: break-glass accounts and a time-boxed override
Your break-glass accounts are protected from PIM Manager's revoke, disable and offboard paths, and in an emergency a SuperAdmin can lift the approval requirement for a bounded time.
PIM for on-premises Active Directory
Just-in-time membership of on-premises AD groups, driven by PIM activation in the cloud and applied by a small hybrid worker.