Copilots Have Your Permissions. All of Them.

A copilot is AI that ships inside software you already own. Software that updates on a Tuesday and now has an AI in it.

Microsoft 365 Copilot lives inside Word, Outlook, Teams, and SharePoint. Salesforce embedded Agentforce in the CRM. ServiceNow baked Now Assist into its platform. GitHub Copilot sits in the IDE. These arrived as feature updates to products already in the environment, already licensed, already holding data.

This matters because the AI's access model is inherited wholesale. And what it inherits is the problem.

The mechanism: permission inheritance

Microsoft's architecture documentation is unusually direct: "Data access is always scoped to the signed-in user's permissions." Copilot queries Microsoft Graph to retrieve emails, chats, documents, and calendar items. It uses a Semantic Index that maps organizational content into a retrieval layer optimized for natural language. Every query is permission-trimmed. The Semantic Index does not create new access rights. Content appears in Copilot responses only if the user already has access through existing Microsoft 365 permissions.

Your Conditional Access policies still apply. Your MFA still fires. The authorization boundary hasn't moved an inch.

The AI exercises the full granted permission set on every query, though, which changes the access behavior completely.

What copilots actually do with your permissions

Before Copilot, accessing a SharePoint file required knowing it existed. You navigated to the right site, searched with the right keywords, or got a link from someone. The permission was granted, but actual access was constrained by a human's browsing habits, memory, and attention span. Most users touch a tiny fraction of what they're authorized to reach.

Copilot removes that constraint. A prompt like "summarize the Q3 budget discussion" queries across the full Semantic Index simultaneously. Every SharePoint site, every OneDrive folder, every Teams channel the user can access. It doesn't browse. It searches everything, all at once, and surfaces whatever is most relevant.

The permissions are identical. The search behavior covers the entire granted set, simultaneously, on every prompt. And that search behavior exercises the user's full permission set on every query, rather than the narrow subset they'd habitually navigate.

Think of it as permission debt, the same way engineers talk about technical debt. Every "Anyone with the link" share that was never revoked, every legacy AD group from a 2019 migration, every site where the marketing intern still has Finance folder access from a project three roles ago. That debt accumulated silently for years because no one browsed to it. Copilot is the audit that calls the debt due.

The oversharing event

SharePoint's default sharing settings are, in Microsoft's own phrasing, "the most permissive option." A Gartner survey of 132 IT leaders in June 2024 found that oversharing concerns caused 40% of organizations to delay Copilot rollouts by three or more months. Varonis, analyzing data from over 1,000 customer environments, reported that 90% of organizations had sensitive files exposed to all employees through Copilot. Varonis sells tools that fix this exact problem, so weight that number accordingly. But the structural finding is consistent with what Microsoft's own readiness documentation implicitly acknowledges by existing at all.

The deployment pattern is always the same: someone runs a test prompt, and the response references a document from a SharePoint site they didn't know they could access. "Wait, why is Copilot showing me this?"

Because you could always see it. You just never looked.

Where your IDAM intuition helps

You already hold the concept that makes this legible. You know the difference between granted permissions and effective permissions. Granted is what the RBAC system says a user can access. Effective is what the user actually reaches. There's always a gap. That gap is where permission sprawl hides, and it's why access reviews exist.

Copilot deployments are, functionally, the most thorough access review most organizations have ever run. The AI exercises the granted permission set so exhaustively that every gap between granted and effective becomes visible. It shows up on a user's screen, and they ask their manager about it.

Your intuition is correct here: the problem is a permissions problem. The buyer who asks "how do we secure our copilot deployment?" is, at bottom, asking "how do we fix the permission debt we've been accumulating for a decade?" That's a conversation you know how to have.

Where your IDAM intuition misleads

Now the part that's less comfortable.

In traditional IDAM, if permissions are correctly scoped, risk is managed. The implicit assumption is that granted permissions represent a ceiling, and actual access falls somewhere below it because humans are selective about what they touch. You evaluate risk based on what's granted, knowing that effective access will be narrower.

Copilots eliminate the gap between ceiling and floor. Every granted permission becomes exercised access. The behavioral constraint that kept oversharing invisible is gone.

So the risk model changes even when the authorization model is untouched. A permission that was low-risk when it required a human to navigate to it becomes high-risk when an AI surfaces it in response to a natural language question. Same permission, same user, same policy. Materially higher risk.

Your IDAM frame will tell you that if the permissions haven't changed, the risk profile hasn't changed. That's the instinct to override. Copilots make the granted permission set the effective access surface. Every permission is now load-bearing.

Beyond Microsoft: the pattern holds

Salesforce's Agentforce inherits the user's permissions and respects field-level security and sharing settings. ServiceNow's AI agents run as the invoking user by default, evaluating access based on that user's roles. GitHub Copilot's scope is narrower, bounded to workspace and repository access rather than a tenant-wide index. The primary documentation for Salesforce and ServiceNow's permission models is less centralized than Microsoft's, but the principle holds across all of them: the AI operates within the user's existing permission boundary.

ServiceNow introduced role-masking in late 2025, which limits AI agents to a subset of the invoking user's roles. That's the most explicit least-privilege enforcement any major copilot platform has shipped so far. It's also a quiet acknowledgment that inheriting the full permission set is the wrong default. The spec calls this "delegation," which is a generous word for what's actually happening.

The buyer conversation

When a buyer asks about securing their copilot deployment, the first problem is simpler and harder than AI governance frameworks.

Microsoft's own readiness guidance starts with:

• Data access governance reports
• Sharing setting adjustments
• Restricted access controls for sensitive sites
• Sensitivity labeling

The documentation calls this "getting ready for Copilot." In practice, it's the permission cleanup that should have happened years ago, now urgent because an AI is about to exercise every permission that exists.

If the buyer's next question is about access reviews, permission scoping, or sensitivity labeling, you're in familiar territory. If it shifts to prompt injection, model behavior, or AI-specific threat models, that's the SE's conversation. The permission surface you've been discussing is also an attack surface. EchoLeak (CVE-2025-32711, patched June 2025) was a zero-click prompt injection that could exfiltrate data from a user's full Copilot access scope via a single crafted email. The attack worked precisely because Copilot already had access to everything. No privilege escalation required. The attacker just redirected an AI that was already inside the walls.

The permission layer is yours. The AI threat layer is the SE's. Knowing the boundary is the skill.