Copilot is you. An autonomous agent isn't.

Copilot has never had an opinion about what it's allowed to read. It reads what you can read: your groups, your permissions, the rights your labels grant you. The moment an autonomous agent acts on its own identity instead of yours, that stops being true, and "what can it read?" becomes a question no person can answer for it.

Copilot's reach is really your reach

Copilot gets no god's-eye view of your tenant. It reasons only over content the signed-in user is already allowed to open — and where a label applies encryption, that user must hold the EXTRACT and VIEW usage rights before Copilot can touch the content at all (Microsoft Learn).

So every access question about Copilot has really been a question about the human in the chair. The human is the access decision; Copilot just rides along on it. Borrowed permission, end to end.

Interactive agents still borrow. Autonomous ones don't.

An interactive agent — one called with your token — works the same way. It acts in your context, and its token carries both your identity and the agent's (Microsoft Learn). Same borrowed permission as Copilot.

An autonomous agent is different. It doesn't ride along on anyone — it authenticates independently, on its own identity, using its blueprint's credentials (Microsoft Learn). The question you could previously answer by reading one person's permissions now has no person behind it. There's no inherited boundary to inherit. You have to set one.

What that identity actually is

On the Microsoft stack, that identity is Microsoft Entra Agent ID — a purpose-built identity construct for AI agents, distinct from a human user and from an ordinary application (Microsoft Learn). (It's currently in preview, so expect the details to change.)

An agent identity holds no standing credentials of its own. It's provisioned from a reusable template Microsoft calls an agent identity blueprint, which holds the credentials and acquires tokens on the agent's behalf. And it carries a sponsor — the human user or group recorded as accountable for it, used, for instance, to reach a responsible person if a security incident occurs (Microsoft Learn). No password, no person it borrows from — an identity of its own, with a human's name attached for accountability.

So it's a least-privilege identity question now

This is familiar work in an unfamiliar place. Because no human's permissions bound the agent, you draw the boundary deliberately: scoped, time-bound tokens so it reaches only the resources it actually needs; Conditional Access and Identity Protection applied to agents the way they already apply to users; and identity-governance constructs — access packages, entitlement management, lifecycle workflows — to onboard and retire an agent with the same rigour as an employee (Microsoft Learn).

Here's the concrete lever. Because every agent of a given kind is created from one blueprint, you govern them as a class: in the Microsoft Entra admin center you can apply a Conditional Access policy to all of them, disable all of them, or revoke a permission grant for all of them — in a single action (Microsoft Learn). You're not chasing individual agents; you're setting rules for a kind.

Discovery and identity are two different questions

Microsoft Agent 365 is the registry — the inventory of what agents exist in my tenant at all. Microsoft Entra Agent ID is the identity and access foundation beneath it — what this thing is allowed to be (Microsoft Learn).

Discovery answers "what is running?" Identity answers "what may it do, and who answers for it?" You need both.

Why this is still governance

Information protection governs what gets read — the encryption and usage-rights gate is the same gate, whoever is knocking. Identity governs who or what is doing the reading, and on whose authority.

For a human user those two collapse into one person, which is why labels and usage rights take you a long way. For an autonomous agent they come apart: the document's protection still decides whether the agent can read it, and the agent's own identity decides what it is, what it may do, and who is accountable. You govern both.

Go set the boundary

Before you deploy your first autonomous agent, answer the three things you can't borrow from a user:

1. What identity does it authenticate as?
2. What's the smallest scope it needs?
3. Who is its sponsor?

Then open the Microsoft Entra admin center and check whether your agents are created from blueprints you can govern as a class.