Microsoft 365
How does autonomous Microsoft 365 access request handling work?
Autonomous Microsoft 365 access request handling captures a request in plain language, checks it against eligibility and least-privilege policy, routes any required approval, then provisions the access directly in Entra ID, SharePoint, Teams, and security groups — all without a ticket queuing for a human engineer. Every step is verified after execution and written to an immutable audit trail. The result is access granted in seconds instead of hours or days, with governance enforced at the execution layer rather than left to manual review.
- Updated
- June 2026
- Read time
- 10 min read
- For
- IT admins, identity and access managers, M365 administrators
- Topic
- Microsoft 365
In brief
- An employee asks for access in plain language; the system parses the request into a specific resource and scope.
- A policy engine checks whether the requester is eligible and whether the requested scope follows least privilege before any change is attempted.
- If policy requires approval, the request is routed to the resource or data owner; if policy allows it outright, it proceeds directly.
- Provisioning happens through native Microsoft Graph operations against Entra ID, SharePoint, Teams, and security groups.
- The system verifies the grant succeeded and logs every decision and action to an audit trail for compliance and review.
Best for
IT and identity teams handling recurring M365 access requests at volume, especially organizations enforcing least privilege or facing access-related audit requirements.
Based on how autonomous IT engineering operates against the Microsoft Graph and Entra ID, with governance enforced in the execution layer.
What does autonomous M365 access request handling actually do?
Autonomous M365 access request handling takes a request for access to a Microsoft 365 resource and fulfills it without a human engineer performing the work. The system reads the request, identifies the exact resource and permission level involved, checks it against policy, obtains approval if required, makes the change through Microsoft Graph, and confirms the result. The defining characteristic is execution: it grants the access rather than logging a ticket for someone else to act on.
This is distinct from three things people often confuse it with. A self-service portal still hands the provisioning step to an administrator. A workflow tool can route an approval but cannot make the Entra ID or SharePoint change itself. A chatbot can explain how to request access but does not perform any operation. Autonomous handling collapses request capture, governance, approval, and provisioning into a single continuous flow.
Key takeaways
- The system completes the access change, not just the request form.
- Policy and least-privilege checks happen before execution, not after.
- It is not a chatbot or a portal — it executes real M365 operations.
What happens between a request and an access grant?
Between request and grant, an autonomous system runs a fixed sequence: capture the natural-language request, resolve it to a specific resource and scope, run an eligibility and policy check, route approval if policy demands it, provision the access through native APIs, verify the change, and write the audit record. Each stage gates the next, so a request that fails the policy check never reaches provisioning. The sequence is deterministic in its order even though the language understanding at the front is probabilistic.
The capture stage turns a sentence like "I need edit access to the Finance SharePoint site" into a structured intent: resource = Finance site, permission = contribute, requester = the authenticated user. The resolution stage disambiguates when multiple resources match. Only after the request is fully resolved and the requester identified does the policy check run, which keeps the security boundary independent of how cleanly the request was phrased.
Key takeaways
- The flow is gated: each stage must pass before the next begins.
- Natural-language capture is separated from the deterministic policy check.
- A failed policy check stops the request before any change is made.
Examples
SharePoint site access
A finance analyst asks for edit access to a project site. The request resolves to a contribute role on a specific site, passes the policy check for their department, and is provisioned via a Microsoft 365 group membership change — verified and logged within seconds.
Teams channel membership
A new hire requests to join a private Teams channel. Policy requires the channel owner's approval, so the request routes to that owner; once approved, membership is added and confirmed back to the requester.
How is least privilege enforced during autonomous provisioning?
Least privilege is enforced by a policy layer that defines what each requester is eligible for and the maximum scope any grant may carry, evaluated before provisioning runs. Rather than granting the broad permission a user asks for, a well-designed system maps the request to the narrowest permission that satisfies the need — read instead of write, a single group instead of a role, time-bound instead of standing access where supported. Because this check sits in the execution path, no provisioning operation can proceed that the policy has not explicitly allowed.
The strongest implementations make policy deterministic and code-level rather than instruction-level. In a prompt-based guardrail, a cleverly worded request can sometimes talk the model into over-granting. In a code-level policy engine, the grant simply cannot execute unless it matches an explicit rule — there is no policy, so there is no action. This is why governance belongs in the execution layer, not in the model's instructions.
Key takeaways
- Eligibility and maximum scope are evaluated before any change runs.
- Requests are mapped to the narrowest sufficient permission, not the requested one.
- Code-level policy cannot be bypassed by how a request is phrased.
Common mistakes
- Granting the permission the user named instead of the least permission that meets the need.
- Relying on prompt instructions for guardrails, which a crafted request can override.
- Allowing standing access where time-bound or just-in-time access would suffice.
- Skipping a periodic review, so access granted for one project never gets revoked.
When does an access request need approval, and who approves it?
Approval is required whenever policy classifies the requested resource or scope as sensitive enough to need a human sign-off, and it is routed to the owner of that resource or data — typically the SharePoint site owner, Teams channel owner, group owner, or a designated data steward. Low-sensitivity requests that fall squarely inside a requester's eligibility can be configured to proceed without approval, while privileged roles or regulated data always route for sign-off. The routing decision is itself driven by policy, so it is consistent rather than dependent on who happens to handle the request.
Good approval design keeps the approver's decision lightweight: the approver sees who is asking, what they want, why, and what scope will be granted, then approves or denies in one action. For high-volume, low-risk patterns, an "approve always" style standing approval lets an owner pre-authorize a category of requests so routine grants do not interrupt them, while still preserving the audit record. The aim is to put humans in the loop where judgment matters and out of it where it does not.
Key takeaways
- Whether approval is needed is a policy decision, not an ad-hoc one.
- Requests route to the actual resource or data owner, not a generic queue.
- Routine low-risk grants can proceed without an interrupt; privileged ones always route.
For IT admins
- Map each sensitive resource class to a named owner before enabling autonomous grants.
- Define which request categories may proceed without approval and which always route.
For Identity & access managers
- Set the maximum scope policy per resource so approvals are bounded, not open-ended.
- Decide where time-bound or just-in-time access replaces standing membership.
For Resource & data owners
- Review the requester, scope, and reason presented at approval time.
- Use standing pre-authorization only for genuinely low-risk, high-volume request types.
What gets provisioned across the Microsoft 365 stack?
Once approved, provisioning happens through native Microsoft Graph operations against the relevant service: Entra ID for group membership and role assignment, SharePoint for site and document library permissions, Teams for channel and team membership, Exchange Online for mailbox and distribution-group access, and security or Microsoft 365 groups for the group-based access model. Because access in M365 is overwhelmingly governed through group membership, most grants resolve to adding the requester to the correct group rather than assigning a direct permission. This keeps the resulting access model clean and reviewable.
Group-based provisioning matters for governance, not just convenience. Direct permissions scattered across individual sites and items are hard to audit and harder to revoke. Provisioning through groups means a single membership review surfaces everything a user can reach, and a single removal revokes it cleanly. An autonomous system that defaults to the group model leaves the tenant in a more auditable state than ad-hoc direct grants would.
Key takeaways
- Provisioning runs through native Microsoft Graph calls, not scripts run by hand.
- Most access resolves to group membership rather than direct per-item permissions.
- Group-based provisioning keeps the access model auditable and revocable.
Examples
Entra ID security group
A request for access to a line-of-business app resolves to membership in the Entra ID security group that gates the app, rather than a direct app assignment — one membership covers and later revokes the access cleanly.
Exchange shared mailbox
A support agent needs access to a shared mailbox. The grant is a Full Access permission on that mailbox in Exchange Online, scoped to the agent and recorded for review.
How is the grant verified and recorded for audit?
After provisioning, an autonomous system reads the resource state back to confirm the access was actually applied — that the group now contains the user, or the permission now exists — rather than assuming the write succeeded. It then writes a complete record of the request to an audit trail: who asked, what was requested, what policy decision was made, who approved, what was changed, and the verified result. This record lives both in the native Microsoft 365 audit logs and in the system's own activity log, giving two independent sources of truth.
Verification closes the gap between "the API call returned success" and "the user actually has access." Reading the state back catches partial failures, replication lag, and conflicting policies that a fire-and-forget grant would miss. The dual audit trail matters for compliance: when an auditor asks who approved a finance-site grant and when, the answer is a single immutable record rather than a reconstruction from scattered logs.
Key takeaways
- The system reads back resource state to confirm the grant, not just the API response.
- Every request is logged with requester, decision, approver, action, and result.
- Records exist in both M365 audit logs and the system's own activity log.
Where does an autonomous IT engineer like Dex fit?
Dex is the world's first autonomous IT engineer for Microsoft 365, and access request handling is one of its most direct use cases. Dex Go handles the employee side inside Microsoft Teams or Slack: a user describes the access they need and Dex Go fulfills it, acting only on the requesting user's own account as a strict security boundary. Dex Pro handles the administrator side from a web console, executing access changes across Entra ID, SharePoint, Teams, Exchange, and groups using the admin's own delegated permissions rather than a shared application key.
The governance comes from a deterministic, six-layer policy engine — Global, Tenant, Target Rules, Department, Action, and Runtime — that enforces what may happen at the code level. No matching policy means no action, and prompt injection cannot bypass it because safety lives in the execution layer, not the prompt. Dex Pro shows every action before executing, with an "Approve Always" option for bulk or routine operations, and Dex resolves L1 through L3 work autonomously rather than just simple Tier 1 tasks. It is built by the team behind SysAid and carries ISO 27001, 27017, and 27018 certification, SOC 2 Type 2 compliance, GDPR alignment, zero data retention, and a full audit trail.
Key takeaways
- Dex Go fulfills employee access requests in Teams or Slack, scoped to the requester's own account.
- Dex Pro executes admin-side access changes using delegated permissions, not a shared API key.
- A code-level six-layer policy engine enforces least privilege and cannot be bypassed by prompt injection.
How software helps
Dex turns an access request into a fulfilled, verified, and logged change: it parses the natural-language ask, checks it against the policy engine, routes approval to the right owner when required, provisions through native Microsoft Graph operations, verifies the result, and records everything to the audit trail — without a ticket waiting in a human queue.
The autonomous access request lifecycle, step by step
This is the end-to-end path a single access request travels, from the moment an employee asks to the moment the grant is verified and logged. Each step gates the next.
- 1
Capture the request in natural language
An employee describes the access they need in plain language inside Teams or Slack — for example, "I need to upload to the Marketing SharePoint library." No form, ticket category, or resource ID is required from the user.
- 2
Resolve the request to a specific resource and scope
The system parses the request into a concrete target and permission level — a named SharePoint library with contribute access — and disambiguates if more than one resource could match. The authenticated identity of the requester is attached.
- 3
Run the eligibility and least-privilege policy check
The policy engine evaluates whether the requester is eligible for this resource and whether the requested scope is within the maximum allowed. It maps the request to the narrowest permission that meets the need. No matching policy means no action.
- 4
Route approval when policy requires it
If policy classifies the request as needing sign-off, it routes to the resource or data owner with the requester, scope, and reason presented for a one-action decision. Low-risk requests inside the requester's eligibility can proceed without an interrupt.
- 5
Provision the access through native operations
On approval, the change executes through Microsoft Graph — typically by adding the user to the correct security or Microsoft 365 group, or by setting the specific SharePoint, Teams, or Exchange permission. Admin-side changes run under delegated permissions.
- 6
Verify the grant took effect
The system reads the resource state back to confirm the access actually applied — the membership now exists, the permission is present — rather than trusting the API response alone. Partial failures and replication issues are caught here.
- 7
Record the audit trail and confirm to the requester
The full request — requester, decision, approver, action, and verified result — is written to both the M365 audit log and the system's activity log. The requester is told the access is live, closing the loop without a ticket ever queuing.
What should you evaluate in an autonomous access request system?
These criteria help you judge whether a system can handle M365 access requests safely and at scale.
- Where governance is enforced
- Confirm whether policy is enforced at the code level in the execution path or merely as model instructions. Only code-level enforcement cannot be talked around by a crafted request.
- Permission model
- Prefer delegated permissions — the admin's or user's own scoped token — over a shared application key with broad tenant access. Delegated access keeps every action attributable.
- Least-privilege mapping
- The system should grant the narrowest permission that meets the need and support time-bound access where the resource allows it, rather than granting exactly what was asked.
- Approval routing fidelity
- Approvals should route to the real resource or data owner with full context, and the routing decision itself should be policy-driven and consistent.
- Verification after execution
- The system must read resource state back to confirm the grant rather than trusting the API response, so partial failures are caught.
- Audit and compliance posture
- Look for a complete, immutable audit trail in both M365 logs and the system's own log, plus relevant certifications such as ISO 27001 and SOC 2 Type 2.
Are you ready to automate M365 access requests? A readiness checklist
Use this checklist to confirm your tenant and team are ready before enabling autonomous access request handling.
Your most common access request types are documented
SharePoint, Teams, group, and mailbox requests should be cataloged by frequency.
Access is governed primarily through groups rather than direct per-item permissions
Group-based access is what makes autonomous grants clean to provision and revoke.
Each sensitive resource class has a named owner or data steward
Required so approvals route to a real decision-maker, not a generic queue.
Least-privilege and maximum-scope policies are defined per resource class
You have decided which request categories may proceed without approval
The autonomous system uses delegated permissions, not a shared application key
Delegated permissions keep every action attributable and scoped.
Verification and audit logging are enabled before go-live, not added later
A periodic access review process exists to revoke grants that are no longer needed
Putting it all together: from problem to platform
Placeholder — a short paragraph framing the challenge and what a modern approach looks like, before outlining where automation, AI, and a purpose-built platform each play a role.
The challenge
M365 access requests are high-volume, repetitive, and time-sensitive, yet each one traditionally waits in a ticket queue for an administrator to interpret, approve, and provision by hand. The cost is not only delay — manual provisioning is inconsistent, tends to over-grant under time pressure, and leaves an audit trail scattered across systems. The challenge is to fulfill these requests in seconds while tightening governance, not loosening it.
What good looks like
- Access requests are fulfilled and verified within seconds of being asked, with no ticket queuing
- Every grant is the narrowest permission that meets the need, enforced before provisioning runs
- Approvals reach the right owner with full context and a one-action decision
- Every request, decision, and change is captured in a single immutable audit record
Where automation helps
- Provisioning routine, low-risk access by adding users to the correct group automatically
- Routing approvals to the named resource owner without a human dispatcher in the loop
- Reading resource state back to confirm each grant actually took effect
- Writing a complete audit record for every request without manual logging
Where AI helps
- Interpreting a plain-language request and resolving it to a specific resource and scope
- Disambiguating when multiple resources could match the requester's description
- Mapping a broadly-worded ask to the narrowest permission that satisfies it
- Handling the full range of M365 access types without a predefined form for each
Where a platform fits
- Enforcing least privilege through a deterministic, code-level policy engine in the execution path
- Acting through delegated permissions so every change is attributable to a real identity
- Provisioning natively across Entra ID, SharePoint, Teams, Exchange, and groups
- Maintaining a dual audit trail across M365 logs and its own activity log for compliance
Placeholder — short, direct value statement
Placeholder supporting sentence. No jargon. One clear benefit.
See how Dex handles access requests autonomouslyFrequently asked questions
Common questions about this topic, answered directly.
A self-service portal collects the request and usually still routes the provisioning step to an administrator to perform by hand. Autonomous handling completes the provisioning itself, executing the Entra ID, SharePoint, or Teams change through native APIs and verifying the result. The user experience can look similar, but only the autonomous system removes the human from the fulfillment step.
It strengthens them when governance is enforced at the execution layer. A code-level policy engine evaluates eligibility and maximum scope before any change runs, maps each request to the narrowest sufficient permission, and blocks anything without a matching policy. Because the check is deterministic and applied every time, it is more consistent than manual review under time pressure.
Common targets include Entra ID for group membership and role assignment, SharePoint for site and library permissions, Teams for team and channel membership, and Exchange Online for mailbox access. Most grants resolve to security or Microsoft 365 group membership, which keeps the resulting access model auditable and easy to revoke.
Approval routes to the owner of the resource or data — the SharePoint site owner, Teams channel owner, group owner, or a designated data steward — based on a policy classification of the request. The owner sees who is asking, what they want, why, and the scope, then approves or denies in one action. Whether approval is required at all is itself a policy decision, so it is consistent across requests.
Dex Go acts only on the requesting user's own account and never on someone else's, which is a hard boundary rather than a setting. An employee can ask for access they personally need, but Dex Go cannot be used to grant access to a third party. Administrator-scoped changes that affect other users run through Dex Pro under delegated admin permissions instead.
Delegated permissions mean the system acts using the admin's or user's own scoped OAuth token rather than a shared application key with broad tenant access. This keeps every change attributable to a real identity and bounded by that identity's rights. A shared application key, by contrast, concentrates broad access in one credential and makes the audit trail less precise.
After provisioning, the system reads the resource state back to verify the access applied, then records the requester, the policy decision, the approver, the action taken, and the verified result. That record is written to both the native Microsoft 365 audit logs and the system's own activity log, giving compliance teams two independent sources of truth for any grant.
Not when governance lives in the execution layer rather than in the prompt. Dex uses a deterministic, six-layer policy engine where an action simply cannot execute unless it matches an explicit policy, so no wording in a request can authorize a grant the policy does not allow. Prompt injection can influence text generation, but it cannot reach past the code-level policy that gates execution.
The bottom line
Autonomous Microsoft 365 access request handling works by capturing a plain-language request, resolving it to a specific resource and scope, validating it against an eligibility and least-privilege policy, routing approval to the resource owner when required, provisioning the access through native Entra ID, SharePoint, Teams, and group operations, verifying the grant, and recording it to an immutable audit trail. The governance is strongest when it is enforced at the code level in the execution path, so no request can be phrased into an over-grant, and when changes run under delegated permissions that keep every action attributable. Done this way, access that once took hours or days in a ticket queue is granted in seconds — with least privilege and auditability tighter than manual provisioning ever achieved.
See it in action
Placeholder — one sentence describing what the viewer will see in a product walkthrough or demo session.