Notifications
Clear all
Topic starter
01/07/2026 2:05 am
TL;DR: Access requests often stall because intake, approval logic, and provisioning live in separate systems, but Opal and Risotto connect Slack to governed grants so requests can resolve in seconds with policy, approvals, and audit intact. The underlying governance challenge is not speed alone, but keeping least privilege and accountability intact as access becomes self-serve.
NHIMG editorial — based on content published by Opal Security: Back From Slack Request to Governed Grant
Questions worth separating out
Q: How should security teams implement self-serve access without weakening least privilege?
A: Keep the request channel separate from the approval and provisioning authority.
Q: Why do manual access requests often lead to standing privilege?
A: Manual queues make access feel expensive, so teams approve broader grants to reduce repeat tickets.
Q: What breaks when access requests are handled across separate systems?
A: The request can lose context between intake, policy review, and provisioning.
Practitioner guidance
- Keep entitlement authority in one system of record Use the request channel for intake only, then route every decision through the catalog and policy engine that owns the grant.
- Limit self-serve to pre-scoped entitlements Restrict the access catalog to grants that can be approved and provisioned without ambiguous judgment.
- Preserve the audit chain across every hop Confirm that request metadata, approval outcomes, and provisioning events all land in the audit trail, even when the user never leaves Slack.
What's in the full article
Opal Security's full article covers the implementation detail this post intentionally leaves for the source:
- How the Slack request flow maps to Opal's API-backed approval and provisioning path.
- How automatic catalog sync builds access rules from Apps, Resources, Groups, and Bundles.
- How real-time signed webhooks and polling fallback keep request status from getting stuck pending.
- How the integration preserves Jira, ServiceNow, and Zendesk records across the full request lifecycle.
👉 Read Opal Security's analysis of self-serve access requests through governed grants →
Slack-to-grant access requests: what changes for IAM teams?
Explore further
01/07/2026 2:26 am
Governed self-serve access is a control model, not a convenience feature. The important shift is not that employees can ask in Slack, but that the request path can be shortened without surrendering policy authority. That makes the architecture relevant to IAM, IGA, and PAM teams that are trying to reduce manual handling while keeping approvals and audits central. The practitioner takeaway is that self-service only works when governance remains the source of truth.
A few things that frame the scale:
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to the State of Secrets Sprawl 2025.
- The State of Non-Human Identity Security shows that only 1.5 out of 10 organisations are highly confident in securing NHIs.
A question worth separating out:
Q: Who is accountable when a self-serve access workflow grants the wrong entitlement?
A: Accountability stays with the governance model that defines the catalog, approval rules, and provisioning controls, not with the chat channel that collected the request. Teams should be able to show who approved the grant, what policy allowed it, and whether the resulting access was later reviewed or revoked.
👉 Read our full editorial: Governed self-serve access closes the gap between Slack and grant
