Identity controls for AI agents in Microsoft 365

An AI assistant that answers questions over your organisation’s content has to read that content. When it acts on behalf of a signed-in user, it operates with that user’s permissions — which is the correct design, and which has a consequence organisations consistently underestimate.

A user with read access to four hundred SharePoint sites has, in practice, opened perhaps three of them. An agent searching on their behalf reads all four hundred. The permissions did not change; the realised access did.

The threat: latent access becomes actual

This is the central idea and it is worth stating carefully, because it is not a vulnerability in any product.

Most organisations have accumulated access that nobody exercises. A site opened to everyone during a project. A Teams channel with the whole company in it. An HR folder whose permissions were set by someone who has left. This over-permissioning has always been a risk, and it has been mitigated in practice by obscurity: people did not know the content was there, and search was not good enough to surface it.

An AI agent removes the obscurity. It searches comprehensively, summarises, and presents information from wherever the user is permitted to read. A question like “what are we planning for the restructure” returns whatever the user can technically reach.

Nothing was breached. The access was always there. It is now used.

A second, related exposure: agents that run without a user. An agent operating with its own application identity and tenant-wide permissions is not bounded by any user’s access at all. That is the exposure described in application consent in Microsoft Entra ID, and it applies here with more force because the thing holding the permission is designed to read broadly and synthesise.

Exposure: what to establish before deployment

Where is the oversharing? Sites and Teams with organisation-wide access, anonymous links, and stale guest access. This is the same inventory as in Microsoft Purview and the permissions work that has to come first, and the AI deployment is simply what makes it urgent.

Which agents will exist, and what identity does each use? Distinguish clearly between agents acting on behalf of a signed-in user and agents running with their own identity and application permissions. The governance requirements differ substantially.

Who can create agents? Low-code and no-code agent building means the answer may be “anyone”, which turns agent governance into a problem of scale rather than of individual review.

What data sources will be connected? An agent grounded only in a curated set of documents is a much smaller exposure than one with access to everything the user can reach, plus connectors to external systems.

Assessment

Run this before enabling anything broadly:

1. Report on organisation-wide and anonymous access across SharePoint and OneDrive. The number is usually larger than anyone in the room expects, and it is the single most useful piece of evidence for getting the remediation prioritised.
2. Identify sites holding sensitive content that have broad access. Purview’s content explorer helps once classification is running; the sharing reports help immediately.
3. Inventory existing applications with tenant-wide read permissions, because an agent platform typically sits alongside them.
4. Pilot with a small group and look at what the agent actually surfaces. This is more informative than any amount of policy design — ask it the questions a curious employee would ask, and see what comes back.

That last step is the one I would insist on. It converts an abstract argument about over-permissioning into a specific, demonstrable finding.

Hardening: the controls that apply

Fix the permissions. Nothing else on this list substitutes for it. Remove organisation-wide access where it is not warranted, revoke lapsed guests, and establish site ownership. This is the work, and an AI deployment is a good reason to fund it.

Restrict sharing defaults so the problem stops growing, per SharePoint and OneDrive sharing defaults.

Apply sensitivity labels with encryption to the most sensitive content. Where a label applies encryption, it restricts who can open the content regardless of the location’s permissions — which means it constrains what an agent can use, because the agent operates within the user’s rights. This is one of the few places where labelling provides a genuine boundary rather than a marking.

Scope the agent’s grounding data where the platform allows it. An agent restricted to a curated set of sources is a far smaller exposure than one with the user’s full reach, and for most business uses it also gives better answers.

Apply Conditional Access to the agent’s access paths, so the same device, location and authentication strength requirements apply as in Conditional Access baselines.

Govern agent identities as application identities. An agent with its own identity and permissions needs an owner, a review date, a documented purpose and least-privilege permissions. Where the platform supports an agent-specific identity model, use it rather than granting broad application permissions to a general-purpose registration.

Control who can create and publish agents, and require review for any agent that will be shared beyond its creator or that uses application permissions.

Detection

• Audit agent interactions. The prompts and responses are a record of what was accessed, and they should be retained and searchable to the same standard as other access logs.
• Alert on agents being granted new permissions, especially tenant-wide ones.
• Watch for sensitive content appearing in responses, using the same activity monitoring as for other data access.
• Review agent inventory periodically — what exists, who owns it, what it can reach.

The audit trail matters more here than in most deployments, because “what did this person have access to” and “what did this person actually see” have diverged, and only the log answers the second question.

Validation

• Confirm a test user cannot obtain, through the agent, information they should not be able to reach. Test with content you deliberately placed in a location they should not access.
• Confirm labelled and encrypted content behaves as intended — that the agent does not surface content the user cannot open.
• Confirm the audit trail records interactions with enough detail to investigate.
• Re-run the oversharing report after remediation and confirm the numbers moved.
• Repeat the pilot questioning after remediation, and confirm the previously surfaced content is no longer returned.

Honest limits, and what I am not claiming

This article is about the identity and permissions model, which is the part that is stable and well understood. The agent platforms themselves, their identity models and their governance tooling are changing quickly — features arrive, names change, and capability differs by licence. I am not describing a specific product’s current feature set, and anything I wrote about one today would be partly wrong within months.

What will remain true is the underlying property: an agent acting for a user realises that user’s latent access. Whatever the platform, the control that matters most is that the user’s access is correct in the first place.

It is also worth saying plainly that these controls address confidentiality and access. They do not address accuracy, appropriate use, or the question of whether an automated summary should be relied upon for a decision. Those are real issues and they are not identity problems.

Verification and limits

The delegated permission model — an agent acting on behalf of a user operating within that user’s access — and the distinction from application permissions were checked against current Microsoft documentation on 20 September 2026, along with sensitivity label encryption behaviour and Conditional Access applicability.

Nothing here was deployed or tested for this article, and no claim is made about a specific agent product’s current capabilities. This is the fastest-moving area covered in this library: confirm the current identity model, permission behaviour, governance tooling and licensing before designing a deployment, and treat the permissions remediation as the part that will still be correct next year.

References

• Microsoft Graph permissions reference
• Learn about sensitivity labels
• Configure how users consent to applications
• External sharing overview