AI governance at work speed needs governed agents, not faster tabs

At a glance

What this is: This is ConductorOne’s analysis of a governed AI assistant that performs access work inside Slack, with the key finding that governance has to move into the flow of work to keep up with AI-driven access demand.

Why it matters: It matters because IAM teams now have to govern AI-assisted work, NHI-style execution, and human approvals in one operating model without losing auditability or control.

👉 Read ConductorOne's analysis of governed AI assistants for access work

Context

AI governance now sits inside the access path, not beside it. When tools can ask for access, review entitlements, produce evidence, and trigger changes from the same workspace where work happens, the control problem changes from one of policy definition to one of governed execution. That is the primary keyword here: AI governance has to keep pace with how access work is actually done.

For IAM and IGA teams, this is the same programme pressure seen across non-human identities and human access reviews: more identities, more requests, and less patience for context switching. The operational question is whether governance can remain reviewable when the action itself is performed by an assistant rather than by a person clicking through a console.

Key questions

Q: How should security teams govern AI assistants that can perform access work?

A: Treat the assistant as a delegated execution path, not a chat feature. Restrict it to explicit task scopes, tie each action to a policy decision or human approval where required, and ensure every change lands in the same audit trail as normal identity operations. If the assistant can act, it must be governable as an identity workflow, not just a UI layer.

Q: Why do AI assistants change IAM and IGA operating models?

A: They reduce the gap between request, approval, and execution, which can improve adoption and reduce workaround behaviour. But they also move more identity work into runtime decision paths, so controls must be enforced where the work occurs. That means governance shifts from a separate review function to a workflow-integrated control model.

Q: What breaks when access reviews stay detached from the work being done?

A: Review completion drops and exceptions accumulate because people skip processes that are slow, inconvenient, or out of context. When the action is one click away from the task, the governed path becomes more usable than the workaround. Detached review models fail when users do not naturally return to them.

Q: How do organisations keep AI-assisted access changes accountable?

A: Use explicit approval gates for write actions, keep role attribution visible, and preserve evidence for who requested, approved, and executed each change. Accountability depends on being able to reconstruct the decision chain after the fact, including the assistant’s role in the workflow.

How it works in practice

Governed AI assistants and delegated access work

A governed AI assistant is not just a chat layer. It is an execution layer that can inspect entitlement data, prepare a request, submit a change, and return evidence in the same workflow. That changes the identity model because the assistant is not merely informing a human decision, it is carrying out parts of the access lifecycle on the user's behalf. The important technical boundary is whether each action is still tied to policy, audit logging, and existing permission state. Without that linkage, the assistant becomes another uncontrolled automation path rather than a governed identity actor.

Practical implication: treat the assistant as an identity-bearing execution path and verify every action is policy-bound, logged, and reviewable.

Slack as the control plane for identity work

Putting identity work into Slack reduces friction, but it also collapses the distance between request, approval, and execution. That matters because many governance failures come from context switches, not missing policy. If a reviewer can approve a revocation, a campaign, or an evidence request in the same thread where the task appears, the control surface becomes conversational and the timing of governance becomes more immediate. The technical question is not whether Slack is the interface, but whether the same underlying controls, entitlements, and audit records remain intact when the interface is conversational.

Practical implication: validate that thread-based actions still write to the same audit trail and policy engine as console-based workflows.

Access review automation versus access decision automation

There is a difference between automating the preparation of access review artefacts and automating the access decision itself. The first compresses work and can improve follow-through. The second moves authority closer to runtime execution and raises the stakes around approvals, exception handling, and segregation of duties. In identity programmes, that distinction matters because an assistant that can build a quarterly review is operating in a different risk class from one that can actually revoke, reassign, or escalate access. The article describes both, which means the governance model has to be explicit about when the assistant is advisory and when it is acting.

Practical implication: separate read-only review automation from write-capable access automation in policy and approval design.

NHI Mgmt Group analysis

Governance at AI speed is really a control-placement problem. When access work moves into the workspace, the control point must move with it or the programme falls back to a slower, disconnected review model. That is why the article matters for identity governance as a discipline: latency becomes a governance failure, not just an inconvenience. Practitioners should read this as a signal that workflow placement is now part of control design.

AI assistants are becoming a new class of non-human identity with delegated authority. The assistant described here does not merely suggest actions. It acts within permissions, produces evidence, and participates in entitlement workflows, which puts it in the same governance conversation as service accounts and API-driven automations. OWASP-NHI and NIST-CSF are relevant because the core issue is still access, provenance, and auditability. Practitioners should stop treating assistant interfaces as separate from identity governance.

Flow-of-work governance reduces workaround risk, but only if the underlying approval model stays intact. The article’s central claim is that people choose the easiest path, so placing governed actions where work already happens can improve adoption. That is plausible, but only when policy enforcement, human escalation, and review evidence remain non-negotiable. The implication for the field is that convenience is not the control, it is the delivery method for the control.

Identity programmes need a named concept for this pattern: access-work orchestration. This is the convergence of request handling, entitlement analysis, change execution, and evidence generation inside one assistant-led workflow. It reduces context switching, but it also concentrates responsibility for who can ask, who can approve, and who can execute. Practitioners should design for orchestration with explicit role boundaries, not assume conversation itself is a safe governance layer.

This is an NHI governance story even though the interface looks human. The assistant operates as a machine identity that performs access work on behalf of a person or team. That means lifecycle, logging, scope control, and offboarding questions all apply, even when the user experience feels like chat. The field should treat this as part of the broader shift from static access administration to delegated, runtime identity operations.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For the broader control model behind this problem, see Top 10 NHI Issues for the governance failures that recur across machine access.

What this signals

Access-work orchestration: the next governance battleground is not whether AI can answer questions, but whether it can safely complete the follow-up work without bypassing controls. Teams that keep identity governance in a separate tab will keep paying the context-switch tax, while workflow-native governance becomes the operational baseline.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the problem is already structural before AI assistants enter the picture. As more access work shifts into conversational workflows, the programme risk is not just new automation, but unmanaged delegation chains that are harder to see and harder to retire.

The forward signal for IAM leaders is clear: identity operations will increasingly be judged by how much of the access lifecycle can be completed without leaving the work surface, while still preserving approval, evidence, and offboarding discipline. That is a programme design issue, not a UI preference.

For practitioners

• Map every assistant action to a specific control owner Document which requests the assistant may prepare, which it may execute, and which always require a human approver. Tie each action class to a named policy owner and a reviewable audit path.
• Separate read-only and write-capable workflows Allow the assistant to gather evidence and draft reviews without changing entitlements, then require a distinct approval step before revocation, escalation, or campaign changes.
• Test audit fidelity in the same workspace where work happens Verify that Slack-thread actions write the same identity, policy, and change records as console actions, with no hidden side channel for execution or evidence.
• Define offboarding for the assistant itself Create a lifecycle process for disabling the assistant, removing delegated permissions, and preserving historical records when the workflow is retired or re-scoped.

Key takeaways

• AI assistants that perform access work are effectively delegated identity actors, so governance must move from interface control to execution control.
• The operational risk is not just speed, but the loss of separation between request, approval, and change unless policy gates remain explicit.
• Teams that want adoption without losing oversight need workflow-native auditability, scoped authority, and a defined offboarding path for the assistant itself.

Key terms

• Governed AI Assistant: An AI assistant that can carry out access-related work while remaining bound to policy, approval, and audit controls. In practice, it acts as a delegated execution layer rather than a simple chat interface, so identity teams must manage its permissions, logging, and lifecycle like any other non-human actor.
• Access-Work Orchestration: The combination of request handling, entitlement analysis, approval routing, execution, and evidence generation inside one workflow. It matters because the control point moves from separate admin screens into the path where work already happens, which changes how teams design accountability and review.
• Delegated Execution Path: A pathway in which a system performs actions on behalf of a user or team under bounded permissions. For identity governance, the key question is not whether the system is automated, but whether its actions are attributable, reviewable, and removable when the delegation ends.

Deepen your knowledge

AI governance at work speed is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are adapting identity governance for assistants that can act, it is worth exploring.

This post draws on content published by ConductorOne: Governance at AI Speed, Meet the C1 AI Assistant. Read the original.