TL;DR: AI identity governance should be evaluated on what it can change, who approves it, and what evidence it leaves, according to Ploy’s guide, not on conversational quality alone. The real test is whether permissions, exceptions, failures, and auditability are controlled at the action level, not merely described in a demo.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Ploy's blog post: AI identity governance should be measured by action-level permissions, approvals, and evidence rather than by the quality of the chatbot experience.
Why it matters: This matters because identity leaders need to know whether an AI-assisted governance tool recommends changes or actually executes them under control, with auditable proof after each action.
Context
AI-assisted identity governance introduces a familiar control problem in a new interface: the system may appear conversational while still being capable of making real changes. The governance question is not whether the assistant sounds capable, but whether its permissions, approvals, and exception handling are bounded before any identity state changes.
There is also a split between AI that helps govern access and AI identities that must themselves be governed. Those are related but separate problems, and confusing them leads to weak evaluation criteria for both IAM and IGA basics and AI-driven administration.
Key questions
Q: How should AI identity governance tools separate recommendation from execution?
A: 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.
Q: What should teams test when evaluating an AI identity administration workflow?
A: Teams should test whether the workflow can prove which human approved the agent, what delegated scopes it received, which tools and data it can reach, and how revocation works. They should also check logging, policy enforcement, step-up approval for privileged actions, and whether emergency suspension actually stops runtime access.
Q: How do action-level permissions reduce risk in AI-assisted identity operations?
A: Action-level permissions limit an AI assistant to specific operations such as read, propose, approve, or revoke, rather than giving broad administrative access. That reduces misuse because the agent can complete only the exact identity task allowed, and sensitive steps still require a separate authorised control path.
Q: Why is audit evidence harder for automated identity actions than for manual review?
A: Automated identity actions are harder to evidence because the system may change accounts, tokens, or entitlements without a person reviewing each step in real time. Post-change verification helps by checking the final state, comparing it with the intended change, and recording immutable logs, but it is still less transparent than manual review.
Technical breakdown
Recommendation versus execution in AI-assisted IGA
AI-assisted identity governance usually falls into two operating modes. In recommendation mode, the system drafts access-review outputs, suggested joiner-mover-leaver actions, or remediation steps, but a person still makes the final change. In execution mode, the system can carry out actions within rules that have been pre-approved. The architectural difference is not cosmetic: execution creates a need for scoped permissions, explicit exception logic, and verifiable state checks after each step. If those are missing, the tool may look like an assistant while behaving like an operator with delegated authority. See the NHI Lifecycle Management Guide.
Practical implication: Separate read-only, approval-required, rule-based, and blocked actions so the governance model matches the system's actual authority.
Why action-level permissions matter more than model quality
The security boundary sits around the action, not the model. A strong language model can still be unsafe if it can grant access, remove access, revoke sessions, or message employees without the right control gates. Action-level permissioning allows one AI capability to be read-only while another is allowed to propose or execute. It also forces the operator to define which systems are touched, which actions are irreversible, and which tasks can only proceed when a named person approves. That is the real control surface for AI in identity operations. See the IAM and IGA Basics.
Practical implication: Define permissions per action and per system, not just per agent, so destructive steps can be hard-blocked.
Why audit evidence must prove completion, not just intent
For AI-run identity work, an audit log that records the proposed action is not enough. Practitioners need evidence that the target system changed as intended, that the change was verified independently, and that failures were visible rather than hidden behind a confident summary. This means the record should show planning, approval, execution, and post-action confirmation as separate events. If the system only returns a success message from an API call, that is a weak control signal because it does not prove the identity state actually changed. See the Audit Evidence and Continuous Controls Monitoring Guide.
Practical implication: Require post-action rechecks and separate logging of planning, approval, execution, and verification steps.
Threat narrative
Attacker objective: The objective is to use delegated governance capability to alter identity state without the control evidence that would normally expose or stop the change.
- Entry occurs when an AI identity governance system is allowed to move from recommendation into execution without clear action-level boundaries.
- Escalation follows when the assistant can change access, memberships, or sessions beyond the scope a reviewer expected.
- Impact appears when a failed or poorly bounded action changes real identity state without a reliable post-action verification trail.
Breaches seen in the wild
- Meta AI Instagram Account Takeover: 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
- Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Action authority is the real governance boundary for AI-assisted identity work. A tool that can suggest changes but not execute them creates a different control problem from one that can modify access directly. The critical distinction is not conversational quality but whether the system can act, under what rules, and with what rollback path. Practitioners should treat authority tiers as the first design decision, not an implementation detail.
Separated approval and execution are the minimum viable control pattern. Identity programmes fail when recommendation, approval, and execution collapse into one opaque workflow. Distinct states make it possible to know who decided, what was permitted, and whether the system stayed inside its bounds. That separation is the difference between governance support and delegated administration.
Auditability has to prove state change, not just model output. An AI assistant that says an access removal succeeded has not yet proven anything about the target system. The evidence standard has to include re-reading the destination system, confirming the new state, and preserving that proof for review. Without that, the organisation is left with a transcript, not assurance.
AI identity governance is becoming a control-design problem, not a feature-evaluation problem. Buyers are moving past whether the assistant can draft a review or answer a question and toward what the system is allowed to do on their behalf. That shift raises the bar for operator control, exception handling, and evidence retention. The market will increasingly reward tools that make authority visible and reversible, not merely convenient.
Human review remains necessary where the change cannot be proven automatically. Some identity actions still depend on contextual judgement, especially when access decisions involve ambiguity, exceptions, or incomplete evidence. AI can compress the workflow, but it cannot erase the need for accountable decision ownership. Practitioners should keep humans at the points where meaning, not just mechanics, matters.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
- Read next: NHI Lifecycle Management Guide
What this signals
Governance programmes that treat AI as a chat interface will underestimate the control design work required once the system can touch live identity state. The practical shift is toward explicit authority tiers, separate approvals, and verifiable completion, because the review process only works when the system leaves an inspectable trail.
Execution-bound governance: the next phase of AI identity control is not about making assistants smarter, but about making their authority visible, constrained, and reversible. That means designing for the exact step where a suggestion becomes a change, and for the evidence that must exist after the change is made.
For practitioners
- Define action-level authority tiers Classify each AI capability as read-only, approval-required, rule-based, or blocked before it is allowed into production workflows.
- Separate approval from execution Keep recommendation, named approval, and system change as distinct steps so a reviewer can see what was proposed versus what was done.
- Test failure paths before rollout Run scenarios for partial failure, silent refusal, non-response, and operator intervention so the team can see how the system behaves outside the happy path.
- Require post-change verification Check the target identity system after every automated change and retain the verification evidence alongside the action record.
- Document data handling and retention Obtain written answers on what identity data the system reads, where it is stored, whether it trains models, and how long logs persist.
Key takeaways
- AI identity governance is not primarily a chatbot question. The real issue is whether the system can change identity state under rules the organisation can inspect and control.
- The strongest control pattern is to keep recommendation, approval, and execution separate, with hard blocks for actions that should never be automatic.
- Audit evidence has to prove the post-change state in the target system, not merely show that the AI generated a plausible answer.
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · IAM and IGA Basics · Audit Evidence and Continuous Controls Monitoring Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI identity governance decisions depend on constraining delegated authority and action scope. |
| ASI09 — Human-Agent Trust Exploitation | The guide centres on when users trust an agent to act instead of merely advise. | |
| Recommendation — Map AI administration paths to ASI03 and limit action scope before execution is allowed. Require explicit approval states so trust in the assistant does not become implied authorization. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about governing AI-enabled identity administration, not just model output. |
| Recommendation — Define accountable authority, review points, and evidence retention under AI governance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The guide focuses on how AI systems may change permissions and entitlements. |
| GV.RM-01 — Risk management strategy is established | Tool evaluation here is a governance and risk decision, not a UI choice. | |
| Recommendation — Apply PR.AA-05 to keep AI-driven entitlement changes within approved authorisation boundaries. Tie AI identity tool selection to a documented risk strategy and approval model. | ||
Key terms
- AI identity governance: AI identity governance is the set of policies, controls, and oversight used to manage the identities, permissions, and lifecycle of AI agents and related non-human identities. It covers authentication, authorization, credential handling, least privilege, monitoring, and revocation so AI systems only access approved tools, data, and actions.
- Post-Change Verification: Post-Change Verification is a control that checks whether an identity or access change took effect as intended after it was applied. It compares the resulting account, entitlement, token, or policy state with the approved request, and can reveal drift, partial failure, or unauthorised side effects.
- Action-Level Permissions: Action-level permissions define exactly which operations a user, service, or agent may perform within an application or system. In IAM and NHI governance, they restrict access to specific actions such as read, create, approve, transfer, or delete, rather than granting broad role-based access. This supports least privilege and tighter audit control.
- Approval Boundaries: The policy limits that define which access requests can be approved automatically and which require human review. Strong approval boundaries prevent workflow tools from turning convenience into excessive entitlements or uncontrolled app adoption.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org