Zero-Standing-Access for Microsoft Copilot: Just-in-Time Permissions for AI

Almost every serious Microsoft 365 Copilot oversharing incident has the same root cause: users had standing access to content they never actively used, and Copilot faithfully surfaced it the moment someone asked the right question. The permission was legal. The exposure was not.

Zero-standing-access flips the model. Instead of granting broad, permanent read access "just in case," identities hold minimal defaults and elevate to what they need, when they need it, with an audit trail. Applied thoughtfully to Copilot, it cuts the blast radius of oversharing without gutting the productivity story.

Why standing access is the root cause of Copilot incidents

Traditional Microsoft 365 permissions accreted over years. HR uploads its policy library and grants "read" to the whole company. A finance analyst gets added to a working group and stays there for eighteen months. A departing executive's calendar delegate keeps their access. None of it looked risky before Copilot, because nobody was going to browse those SharePoint sites manually.

Copilot changed the exposure math. A single natural-language question — "summarize what our leadership has said about the reorganization" — will pull from every site the user technically has access to. The user was never authorized to see the content in a business sense; they were authorized in the ACL sense. Copilot cannot tell the difference.

Zero-standing-access recognizes that ACL sprawl is unfixable at scale through cleanup alone. The durable fix is to reduce standing rights so that even a broad Copilot query has less to grab.

The zero-standing-access model applied to Copilot

Zero-standing-access has three moving parts when applied to Copilot:

• Baseline defaults minimize standing rights. Users hold the permissions their day-to-day role actually requires, not the union of every role they have ever held.
• Elevation is request-based. When a user needs access to sensitive content, they request it through Entra Privileged Identity Management or Access Packages.
• Every elevation is time-bounded and logged. The permission expires. The request, approval, and use are all visible to audit.

Copilot inherits all of it. If a user does not have standing access to the M&A workspace, Copilot cannot ground on it. If the user elevates for an hour to review something specific, Copilot can — for that hour, and the audit log shows it.

This is not a new pattern in security. What is new is applying it to knowledge access, not just administrative access. Enterprises have used PIM for global admin roles for years. Extending the discipline to SharePoint site collections, Teams membership, and mailbox delegates is the frontier.

The tools: Entra PIM, Access Packages, and approval workflows

Three Entra capabilities do most of the work:

Entra Privileged Identity Management (PIM). Historically scoped to admin roles, PIM now supports role-based just-in-time elevation for a broader set of scenarios. For Copilot-relevant use, PIM handles time-bounded elevation into groups that gate SharePoint sites or Teams membership.

Entra Access Packages. These bundle a set of resources (a SharePoint site, a Teams channel, a specific app) into a request-approve-audit workflow. Users request the package, an approver signs off, access is provisioned for a set duration, and Access Packages handle the deprovisioning automatically.

Conditional access and approval routing. Requests can require MFA, device compliance, and multi-approver sign-off. High-sensitivity resources can be gated behind two approvers; routine ones behind a single manager.

Every request flows through the audit log, which means the incident question "who had access to this at 2:00 pm last Tuesday?" becomes answerable in minutes, not days.

The trade-offs are real: adoption friction and moment-of-insight latency

Zero-standing-access is not free. Two costs are real and worth naming:

• Adoption friction. A user who has to request access to a workspace every time they want to work in it will find workarounds. If those workarounds include sharing files out of band, the security posture gets worse, not better.
• Moment-of-insight latency. The best Copilot moments are when a user asks a question and gets an immediate, well-grounded answer. If the answer requires them to first request access to a resource they did not know existed, the flow breaks.

Both costs are manageable, but only if the design accounts for them from the start. The right answer is not "PIM everything." It is "PIM the sensitive tier, keep everyday content on frictionless standing access, and make the elevation flow itself fast." Our governance engagements typically tier content into three buckets: freely accessible, request-approved, and never-Copilot-grounded.

Automation patterns: approvals in Teams

The single biggest lever for reducing elevation friction is making the approval flow itself live where users already work. In practice, that means:

• Access Package requests route to the approver as a Teams adaptive card
• Approvers can approve or deny with a single click, from mobile, without a browser context switch
• High-frequency requesters get pre-approved packages that skip manual review for a defined scope
• Requests that time out surface back to the requester with a "still need this?" prompt rather than silently expiring

A Teams-native approval loop turns a five-minute browser round trip into a fifteen-second exchange. That is the difference between adoption success and users routing around the system. Our Copilot Studio services team frequently builds these approval agents as part of the initial rollout.

A phased rollout from standing access to JIT

Enterprises do not go from broad standing access to zero-standing-access in one step. The phased path our consultants recommend has four stages:

• Baseline. Audit standing access across SharePoint sites, Teams channels, and mailbox delegates. Publish the results by business unit.
• Tier the content. Sort resources into "everyday" (keep frictionless), "sensitive" (move to Access Packages), and "restricted" (never Copilot-grounded).
• Move the top decile first. Convert the highest-sensitivity resources — M&A, board materials, legal privilege, compensation data — to JIT. Learn the approval flow at low volume.
• Expand the tier and refine automation. As the approval flow stabilizes, expand JIT coverage to the next sensitivity band. Add pre-approved packages for high-frequency legitimate requesters.

Most rollouts spend three to six months in stages one and two before moving anything into production JIT. That timeline is where our Copilot delivery framework sequences the work so security, adoption, and Copilot rollout stay aligned.

What to do next

Zero-standing-access is not a Copilot feature — it is an identity discipline that pays for itself the moment Copilot goes live. The enterprises that get it right have fewer oversharing incidents, cleaner audit trails, and adoption stories that hold up in front of the board.

Book a scoped readiness assessment to see where your standing access exposure sits today, or review our risk scenarios for the incident patterns JIT prevents. To talk to a strategist directly, contact us.