> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/nhi/access-policies.md). # Access policies for NHIs Control who may register, activate, re-scope or retire a non-human identity with policy-based access control — the NHI resource, its management actions, and how the enforcement fails closed. ## What this is, and when you need it Every administrative action on a non-human identity (NHI) — registering one, activating it, changing its owner, re-scoping it, retiring it — is authorized by **policy-based access control (PBAC)**, OpenIAM's Cedar-based policy engine. A non-human identity is a Cedar **resource**, and each management action is a Cedar **action**, so you decide who may do what with the same policy authoring you use elsewhere. Read this page to understand which actions are governed and how to grant them; it assumes you already know how to author a policy — if not, start with [Decide access with policies](/administration-guide/pbac.md). ## The NHI resource and its actions A non-human identity is exposed to the policy engine as the resource type **`Openiam::Nhi`**, carrying the identity's own attributes (its type, environment, risk classification, owner and so on) so policies can decide on them — for example, "only the platform security team may activate a **Prod** identity." The management actions live in the **`Openiam::NhiManagement`** action namespace: | Action | Governs | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | CREATE | Registering a new identity. | | UPDATE | Editing an existing identity (the baseline check on every save). | | ACTIVATE | Taking an identity Active — directly, and the visibility of the **Activate** button. | | SUSPEND | Suspending an Active identity. | | DECOMMISSION | Retiring an identity. | | CHANGE\_OWNER | Reassigning the owner. | | EXTEND\_EXPIRY | Moving the expiry date out. | | RESCOPE | Changing the declared scope. | | CERTIFY | Certifying the identity. | | REQUEST | Requesting registration approval. | | APPROVE | Approving a registration (reserved for policy authoring; the running approval decision is authorized by the [workflow's approver assignment](/administration-guide/nhi/request-and-approval.md), not this action). | | CREDENTIAL\_DELETE | Removing a credential. | {% hint style="info" %} Because a `CREATE` happens before any identity exists, it is evaluated against a sentinel resource rather than a real record. Author create policies on the resource type and its context, not on a specific identity. {% endhint %} ## How enforcement behaves * **Human actions are gated; system actions are not.** Every action a person initiates in the Webconsole is authorized against these policies. Automated paths that carry no human actor — a bulk [synchronization](/administration-guide/nhi/csv-synchronization.md) run, or the [governance jobs](/administration-guide/nhi/governance.md) that auto-suspend an expired identity — run as the system and are not subject to the management policies. This keeps unattended jobs from being blocked by a policy written for interactive users. * **It fails closed.** An action is allowed only when at least one policy set was evaluated and **every** result allowed. A denial, no applicable policy, an evaluation error, or a broker failure all resolve to **deny**. If nobody has been granted an action, nobody can perform it — grant the NHI management actions explicitly. * **The button follows the policy.** The **Activate** button appears on the edit form only when your `ACTIVATE` right is satisfied, but the server re-checks on submit and stays authoritative even if the button is shown. ## Grant access Author a PBAC policy that permits the NHI management actions you intend a group or role to hold, scoped by the resource attributes you care about (environment, risk, type). Follow [Create a policy](/administration-guide/pbac/create-a-policy.md), then [simulate](/administration-guide/pbac/simulate-a-policy.md) it and [roll it out](/administration-guide/pbac/roll-out-a-policy.md). Because enforcement is default-deny, a fresh tenant needs at least one policy granting the management actions before anyone can register or activate an identity. ## When it goes wrong | Symptom | Likely cause | | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | An administrator cannot register, activate or edit an identity, and no error explains why. | No policy grants them the action — default-deny is in force. Grant the relevant NHI management action. | | The **Activate** button is missing for an administrator who should have it. | Their `ACTIVATE` right is not satisfied for that identity's attributes. Check the policy's scope against the identity's environment and risk. | | A synchronization or governance job succeeds even though no policy grants it. | Expected — system-initiated paths are not gated by the management policies. | | Every action is denied after a policy change. | A policy may have narrowed the grant, or the policy set failed to evaluate — a broker or evaluation failure fails closed. [Trace the decision](/administration-guide/pbac/trace-a-decision.md). | ## Related * [Decide access with policies](/administration-guide/pbac.md) — how PBAC policies are authored and evaluated. * [Request and approve registration](/administration-guide/nhi/request-and-approval.md) — the workflow authority, separate from these policies. * [Lifecycle and status](/administration-guide/nhi/lifecycle.md) — the actions these policies govern. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/nhi/access-policies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.