They should keep recommendation and execution in distinct control states, so the tool can suggest access changes without applying them until an approved actor authorises the step. That separation supports human review, workflow logging, and rollback of mistaken or unsafe changes to roles, entitlements, or privileged access.
Why recommendation and execution must stay separate in AI identity governance
AI identity governance tools should treat recommendation as advisory and execution as an authorised action, not a single automated step. That separation lets the system surface likely access changes, but keeps final state change with an approved reviewer who can challenge the suggestion, check business context, and prevent unsafe permission movement.
That design matters because identity decisions often change real authority, not just labels. If a tool can both detect and apply changes, a bad inference, stale data source, or overconfident model output can become an immediate privilege change, rather than a reviewable recommendation.
When the two states are distinct, the recommendation can be enriched with rationale, confidence, and supporting evidence without pretending to be a command. It also creates a cleaner boundary for workflow controls, because the recommendation can be logged, routed, amended, or rejected before any entitlement, role, or privileged-access update is committed.
What the split should look like in practice
The practical pattern is a staged workflow: observe, recommend, review, then execute only after approval. For identity and access use cases, that usually means the tool can propose role changes, entitlement removals, or privileged-access adjustments, but it cannot write them directly to the target system until the approval gate is satisfied.
The interface should make the difference obvious. A recommendation should show what would change, why the tool thinks it should change, and what evidence supports it. An execution action should require an explicit actor, a recorded decision, and a stable request context so the change is attributable and auditable.
This is especially important in environments with IAM and IGA Basics, because the value of governance comes from reviewable lifecycle decisions rather than silent automation. It also fits IGA Buyer's Guide criteria, where request handling, reviews, and connectors need to be evaluated as separate control points, not collapsed into one action.
Where recommendation-to-execution controls break down
The main failure mode is over-trust in the tool's suggestion layer. If recommendation and execution share the same control path, teams can accidentally automate overbroad access removal, apply a role mapping that does not reflect real job function, or propagate a bad entitlement decision across multiple systems before anyone notices.
Another common weakness is weak change provenance. When the same system both proposes and applies access changes, it becomes harder to tell whether the human approved the exact recommendation, whether the recommendation changed after review, or whether an execution happened outside the intended workflow.
For AI agent environments, the issue is even sharper. The Identity Governance for AI Agents Guide is useful here because it frames ownership, lifecycle, access review, and offboarding as distinct governance steps, which is exactly the kind of separation that prevents an agentic system from mutating authority on its own.
Risk and Threat Considerations
When recommendation and execution are not separated, a mistaken suggestion can become an immediate privilege change, and an attacker who influences the recommendation layer may be able to turn guidance into action. The risk is highest where identity decisions are high-impact, such as privileged roles, production access, shared administrative entitlements, or broad access revocation.
Failure mechanism: The tool's output is treated as authoritative enough to trigger writes, so poor data quality, prompt influence, model drift, or workflow shortcuts can convert a review aid into an automated control failure.
Impact: Organisations can create excessive access, remove needed access, weaken segregation of duties, or lose the ability to prove who approved what, which increases both operational blast radius and audit exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Manages credentials that underpin approval and execution boundaries in identity workflows. |
| AC-6 — Least Privilege | Limits the ability of governance tools to apply changes without authorised oversight. | |
| AU-2 — Audit Events | Captures the approval and execution trail needed to prove separation of duties in access governance. | |
| Recommendation — Require controlled lifecycle handling for credentials that can approve or execute access changes. Constrain tools so they can recommend access changes without broad execution authority. Log recommendation, approval, and execution as distinct auditable events. | ||
| NIST CSF 2.0 | PR.AA-05 — Assets are managed, including the inventory of hardware, software, data, and related systems. | Supports governed inventory and change control around systems that issue or apply access decisions. |
| Recommendation — Track the systems that generate and apply access recommendations and approvals. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Directly governs access decisions and the separation of authorised change from recommendation. |
| Recommendation — Define approval boundaries for any access change before it is executed. | ||
Practitioner Guidance
What to verify: Confirm that the system has separate states for draft recommendation, human approval, and committed execution, and that a state transition cannot happen without an authenticated approver and an immutable request record.
Decision rule: If the proposed change affects privileged access, production access, or broad entitlement removal, require manual approval and post-change validation before activation; treat fully automated execution as an exception, not the default.
What good looks like: The reviewer can see the evidence, edit or reject the proposal, and then approve a narrowly scoped change that is logged with the actor, timestamp, target entitlement, and rollback path.
Practitioner takeaway: The control objective is not to slow identity governance down, it is to prevent machine-generated advice from becoming authority until a responsible actor has explicitly accepted the risk of the change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org