Treat chat as a request interface, not a trust boundary. The same entitlement policy, approval routing, and SoD checks must apply whether a user clicks a form or types a request in natural language. If the conversational layer changes the control path, it is not just a usability improvement, it is a governance redesign that needs explicit validation.
What changes when access requests happen in chat?
Chat changes the request channel, not the control requirement. Teams should govern a chat request exactly as they would a portal request: the request must resolve to a defined entitlement, an approver with real authority, and a logged decision that can be audited later. If natural language becomes the approval path, the organisation must prove the same control intent still holds.
That means the design question is not whether chat is convenient, but whether it preserves policy meaning. A request like “grant me access to the payroll export role for one week” still needs deterministic mapping to the access catalog, the right identity context, and the correct approval workflow before any access is granted.
For teams building the underlying IAM process, the governance baseline should look like the access request, entitlement, and approval model described in IAM and IGA Basics. Chat can improve intake speed, but it must not blur who requested what, who approved it, or which policy check resolved the decision.
Why chat requests fail when the workflow is not policy-backed
Chat introduces ambiguity at the exact point where access decisions need precision. Natural language can omit scope, duration, environment, or justification, and that ambiguity is dangerous when the same interface is used to request privileged access, emergency elevation, or access to sensitive systems. The control failure is usually not in the chat layer itself, but in the missing mapping between conversation and enforceable entitlement logic.
Teams also need to avoid turning convenience into an informal override channel. If reviewers start approving “because the request looked reasonable in chat,” the process drifts away from role, policy, and separation-of-duties controls. That risk is especially visible where requests can touch privileged roles, shared administrative functions, or workload credentials, because the impact of a mistaken approval can extend beyond the original user.
For broader identity governance and access recertification patterns, the Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful when teams need to evidence that approvals, reviews, and audit trails remain intact even when the intake channel changes.
Where chat workflows interact with policy engines or externalised authorisation, the access decision should still be grounded in the established model of roles, attributes, and entitlements described in Authorisation Models Guide. That is what prevents the conversation from becoming the authority.
What governance controls should sit behind the conversation?
The strongest pattern is to treat chat as intake, then hand off to the same control plane used elsewhere. The chat interface should capture structured fields, route the request to a policy decision point or workflow engine, and preserve the approval evidence. The user experience can be conversational, but the control evidence should be structured.
Teams should also define what the chat layer is allowed to do automatically. Low-risk classification, ticket creation, or access request drafting may be reasonable; access grant, role assignment, or approval should normally remain policy-bound and attributable. If a bot is allowed to interpret the request, it must not be allowed to silently reinterpret the policy.
Where the workflow includes human approval and delegated action, teams should borrow the same least-privilege mindset used for AI agents and other delegated actors in AI Agent Authorisation Guide. The practical lesson is simple: the interface may speak in natural language, but the granting step still needs bounded authority.
For organisations that want a broader operating model, Identity Security Programme Guide helps frame ownership, RACI, and governance so chat does not become an unowned side channel inside the IAM stack.
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 OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Chat access requests still need governed provisioning and approval of access. |
| AC-6 — Least Privilege | Requests should only resolve to the minimum entitlement needed for the task. | |
| AU-2 — Event Logging | Chat-driven approvals need auditable request and decision records. | |
| Recommendation — Route chat requests through AC-2 approval and provisioning controls before granting access. Validate requested access against AC-6 and deny scope creep in conversational requests. Log request, approval, and grant events to preserve AU-2 evidence across chat workflows. | ||
| OWASP ASVS | V8 — Authorization | Natural-language intake must still enforce explicit authorization decisions. |
| V16 — Security Logging and Error Handling | Chat workflow decisions should be traceable and reviewable after the fact. | |
| Recommendation — Map chat requests to V8 authorization checks instead of treating conversation as approval. Record chat request outcomes and failures under V16 so decisions remain auditable. | ||
Practitioner Guidance
What to verify: Confirm that every chat request resolves to a unique request object, an entitlement, an approver, and an audit record. If any of those are missing, the workflow is not yet equivalent to the form-based process.
Decision rule: If chat only changes the intake experience, you can treat it as a UI layer. If it changes who can approve, what gets approved, or how exceptions are handled, treat it as a control redesign and revalidate it before production use.
Common mistake: Teams often automate the conversational front end first and only later discover that approval ambiguity, free-text requests, or weak policy mapping has weakened SoD. The right sequence is policy first, interface second.
What good looks like: A requester can use chat to start the process, but the system still enforces the same entitlement catalog, approval chain, and exception handling as every other channel. Reviewers should be able to reconstruct the decision without relying on chat logs as the primary control evidence.
Practitioner takeaway: Chat is acceptable as a front door when it preserves deterministic governance, but once conversation influences entitlement logic, you need the same formal controls, evidence, and accountability you would require from any other IAM workflow.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern access requests in ServiceNow without weakening IAM controls?
- How should teams govern access to regulated data across privacy and IAM workflows?