AI Agent Onboarding for Microsoft 365: Entra Permissions, Purview Controls and Copilot Governance

The WorkRadar experiment: lots of access, little understanding​

Beaudry's main example is an internal agent his company built called WorkRadar. Its job is to find tasks that slipped through and help employees catch up. A typical question: "I've been on PTO. What happened, what should I skim, and what should I read closely?"

The team connected WorkRadar to a long list of sources:

• Outlook
• Microsoft Teams
• SharePoint
• Confluence
• Asana
• Meeting notes
• The company's HR information system (HRIS)

The idea was that the agent could work out each user's responsibilities from all that context and guess which topics they cared about. According to Beaudry, it didn't work. When he first tried it, WorkRadar couldn't tell strategic priorities from tactical busywork. It also missed initiatives he sponsors across departments, outside the normal reporting line. His verdict was blunt: the agent didn't know him well enough to help, and he was better off doing the work himself.

The fix wasn't more data. Users could now give WorkRadar a short personal profile covering:

• Their responsibilities and operating level
• Current priorities
• Key stakeholders for specific initiatives
• Their preferred communication style

Beaudry says most people's profile fits on less than a page of short bullets, and that it made a significant difference. He reports that many employees now use WorkRadar much like a strong executive assistant, especially for tracking open to-dos and easing back in after time off.

Section summary: Connecting an agent to Outlook, Teams and SharePoint gives it records. It doesn't tell the agent what matters to the person asking. In Beaudry's account, a short user-written profile closed most of that gap.

A healthy dose of skepticism​

This is an opinion column, and it should be read as one. The WorkRadar story is the author describing his own company's tool. It includes no deployment dates, user counts, accuracy figures, before-and-after comparisons, security architecture or measured productivity gains. "Made a significant difference" is a claim, not a benchmark.

Beaudry also cites outside figures:

• Gartner (August 2026): 40% of C-level executives said their organizations had operationalized AI in some business processes, but only 13% said they had achieved measurable results and were scaling AI across the organization.
• Brandon Hall Group: strong onboarding for human hires improves new-hire productivity by more than 70%.

These numbers measure different things in different groups. The Brandon Hall figure is about people, not agents. They support the analogy, but they don't prove that agent onboarding delivers the same results. WorkRadar isn't a Microsoft product either. Microsoft services were just some of its data sources.

Still, the core point holds up. If you've watched a Copilot rollout produce confident summaries of the wrong things, "access isn't understanding" will sound familiar.

Beaudry's five-part management framework​

Beaudry says managers should define five things for every agent:

1. Role. What is the agent for? Does it act as a stand-in for an employee with that person's access, or under its own identity? Beaudry says its own identity is becoming best practice for governance, risk and compliance reasons. Does it run on your infrastructure or a vendor's? Who is its human supervisor, and at what points must it stop for human review?
2. Remit. What outcomes is it responsible for, and which systems does it need, whether through MCP servers, tools, skills or APIs? Beaudry separates the agent's "sphere of influence" (what you want it to touch) from its "blast radius" (everything it could touch, which you have to protect). He also recommends giving it read access to directories, policies, strategy documents, project trackers and compliance limits.
3. Personality and context. Decide what is permanent context, such as persona, strategy and guardrails, and what the agent should look up as needed. Give it too much and it chases expensive side quests. Give it too little and it wastes resources rediscovering things.
4. Performance review. Give the agent a way to store memories and feedback. Have its supervisor regularly review real outputs and show it examples of its best and worst work. Those examples can become a test suite that catches changes in behavior. Beaudry calls this possibly the most neglected step.
5. Teamwork. Allow carefully scoped access to email and chat. In multi-agent setups, define how agents exchange messages and files, and keep humans in the loop so one agent's mistakes don't flow unchecked into the next.

Section summary: Role, remit, context, review and teamwork are a solid checklist. The first two are where Windows and Microsoft 365 admins actually have controls to configure.

Turning "role" and "remit" into Microsoft controls​

Microsoft's own documentation makes it possible to turn Beaudry's principles into specific configuration choices.

Copilot is limited to what the user can already see​

Microsoft's Copilot architecture documentation says Copilot running inside the Microsoft 365 service boundary doesn't get tenant-wide visibility. Data access is limited to the signed-in user's permissions. Microsoft's privacy documentation adds that Copilot only surfaces organizational data the user can at least view. That means overshared SharePoint sites are still your problem, not something the AI fixes.

Choose delegated or application permissions on purpose​

Beaudry's choice between "employee stand-in" and "own identity" lines up with how Microsoft Entra Agent ID handles permissions:

• Delegated permissions: Use delegated permissions when your interactive agent needs to act on behalf of a signed-in user. For example, read that user's mail, calendar, or files.
• Application permissions: Use application permissions when your autonomous agent runs without a user present and requires app-only access. For example, to read all users' profiles.

Microsoft's Agent 365 documentation puts the same split in runtime terms. In service-to-service mode, the agent runs without a user context and acts as its own agent identity. Use this mode for scheduled tasks, monitoring, and background processing. In on-behalf-of mode, the agent uses delegated permissions; the user is the token subject and the agent identity is the actor.

A WorkRadar-style "catch me up" assistant is clearly interactive and centered on one user, so delegated access is the natural fit. Security researchers at Compass Security agree, writing that where possible, delegated permissions should be preferred over application permissions.

The platform enforces some limits on blast radius​

Entra Agent ID blocks certain high-risk Microsoft Graph permissions outright, including Application.ReadWrite.All, RoleManagement.ReadWrite.All and User.ReadWrite.All. Microsoft's documentation says this ensures that an agent can't circumvent security by asking for sweeping Microsoft Graph access – even an administrator can't consent to give an agent those permissions.

Lower-privilege, user-scoped permissions such as Mail.Read are still available. The platform blocks the worst cases, but sizing everything else is up to you.

Fine-grained and fleet-wide tools​

• Teams Resource-Specific Consent (RSC) grants permissions one team at a time instead of tenant-wide. That's useful when an agent only needs specific channels.
• Access packages let you enable standardized access for many AI Agents with the same access needs. The access package can include Entra roles, OAuth2 delegated and application permission grants and security group memberships.
• Blueprints group agents of the same type, so an administrator can apply a Conditional Access policy, revoke a permission grant, or disable every agent of that kind in one operation. That's the closest thing yet to "fire every agent of this type."
• Conditional Access can target agents, but check licensing first. Microsoft says Conditional Access for agents requires Microsoft Entra ID P1 or P2 and a Microsoft Agent 365 license for each user.

Clean up the data the agent reads​

Microsoft's Purview deployment guidance for Copilot agents recommends three steps:

• Apply sensitivity labels to grounding content in SharePoint and Dataverse.
• Use retention policies to remove stale SharePoint and OneDrive content. Microsoft says this improves agent accuracy.
• Create DLP policies with Microsoft 365 Copilot as the location to restrict highly sensitive files.

Microsoft also advises running those DLP policies in simulation mode first and checking the activity explorer before enforcing them. Admins can review agents' required permissions and decide which agents are allowed through the Microsoft 365 admin center.

These are Microsoft 365 controls. They don't cover Confluence, Asana or an HRIS, and Beaudry doesn't say how WorkRadar's third-party connections were secured.

Context windows, anchoring and the genie problem​

Beaudry ends with two warnings. First, agents lose focus in long sessions and tend to "anchor": they latch onto a passing comment and keep coming back to it. His advice is to start fresh sessions more often than feels natural, or to use context-management techniques such as compaction, truncation and summarization. He puts the effective context window at about 200K tokens without naming a model, so treat that as a rough figure, not a specification.

Second, agents focus narrowly on the task they were given and can miss surrounding requirements, like a genie granting a wish to the letter. As an example, he describes an architect who built a workflow that makes a coding agent interview the developer first, sometimes asking 40 or more clarifying questions before writing any code. That's one person's story, not a proven method. Anyone who has watched an agent confidently refactor the wrong module will still see the appeal.

A practical starter checklist for admins​

Based on Beaudry's framework and Microsoft's documentation:

1. Write a one-page charter per agent: purpose, owner, supervisor and the actions that require human approval.
2. Choose the identity model deliberately. Use delegated access for interactive, single-user agents. Use application permissions only when no user is present, and scope them tightly.
3. List the agent's blast radius. Every connector, MCP server and API it can reach goes on the list, including third-party systems outside Purview's coverage.
4. Fix oversharing first. Copilot follows user permissions, so a broadly shared SharePoint site is already broadly exposed.
5. Label, retain and run DLP in simulation before agents use content as grounding data.
6. Let users write a short profile. In Beaudry's account, this was the change that made WorkRadar useful.
7. Keep a set of good and bad output examples and re-test the agent against it after model or prompt changes.

The bottom line​

Beaudry's column is one CTO's experience with no hard numbers behind it. Its main idea is still sound: connecting more systems to an agent doesn't teach it what matters to the person using it. Treating agents like new hires (an owner, scoped access, clear context and regular reviews) is good management, and Microsoft's Entra and Purview tooling now has controls for much of it. If you're setting up agents, decide what each one is allowed to touch before you worry about how much it knows.