What an AI Agent Must Never Be Allowed to Do

Most of the agent security conversation is about inputs — prompt injection, jailbreaks, poisoned context, tool descriptions that lie. That’s the loud problem, and it deserves the attention.

The quieter problem is authority. Not what you can trick an agent into saying, but what it is permitted to do once it holds a real enterprise identity. An agent that can be manipulated is a bad day. An agent that can be manipulated and holds permission to create more agents, grant itself scopes, or edit the policy that governs it is a different category of event entirely.

Microsoft has now answered the authority question in code. When Agent 365 reached general availability on 1 May 2026 and the Entra Agent ID APIs landed in Microsoft Graph v1.0, something shipped alongside them that I haven’t seen anyone write up: a list of Microsoft Graph permissions that cannot be granted to an agent identity at all.

Not “shouldn’t.” Not “flagged in a hardening guide.” Cannot — the assignment is refused, through both Microsoft Graph and the Entra admin center (Microsoft Learn).

It’s published the way API references publish things: an alphabetical table of ❌ marks near the bottom of a documentation page. Read top to bottom, it’s inventory. Read backwards — sorted by what each block prevents rather than by permission name — it becomes the first authority model for AI agents that a major identity platform has been willing to enforce rather than recommend.

Reading the list backwards

Group the blocked permissions by what they would let an agent accomplish, and six prohibitions fall out.

1. An agent may not create another agent. AgentIdentity.Create, AgentIdentity.Create.All, AgentIdentity.CreateAsManager, AgentIdentityBlueprint.Create, AgentIdentityBlueprint.CreateAsManager, AgentIdentityBlueprint.ReadWrite.All, AgentIdentityBlueprintPrincipal.Create — all blocked as application permissions. Agent creation stays a human-authorised act. There is no supported path to an agent that spawns agents.

2. An agent may not expand its own permissions or approve consent. Application.ReadWrite.All, Application.ReadWrite.OwnedBy, AppRoleAssignment.ReadWrite.All, DelegatedPermissionGrant.ReadWrite.All, ConsentRequest.ReadWrite.All, Policy.ReadWrite.PermissionGrant. The consent boundary — the thing your change process assumes is procedural — turns out to be platform-backed for agents.

3. An agent may not write to the directory or to role assignments. Directory.ReadWrite.All, Directory.Write.Restricted, RoleManagement.ReadWrite.All, RoleManagement.ReadWrite.Directory, PrivilegedAccess.ReadWrite.AzureAD, PrivilegedAccess.ReadWrite.AzureResources. The classic escalation path, closed.

4. An agent may not touch credentials or authentication methods. User.ReadWrite.All, User-PasswordProfile.ReadWrite.All, User.EnableDisableAccount.All, User.DeleteRestore.All, UserAuthenticationMethod.ReadWrite.All, IdentityProvider.ReadWrite.All, User.Invite.All. No password resets, no MFA method changes, no disabling accounts, no inviting external identities.

5. An agent may not hold tenant-wide content access. Files.Read.All, Files.ReadWrite.All, the whole Sites.* family through Sites.FullControl.All, Chat.Read.All, ChannelMessage.Read.All, Calendars.Read, Tasks.ReadWrite.All. And the indirect route is closed too — Group.Create, Group.ReadWrite.All, GroupMember.ReadWrite.All, so an agent can’t add itself to a group and inherit what that group entitles.

6. An agent may not edit the machinery that governs it. EntitlementManagement.ReadWrite.All, LifecycleManagement.ReadWrite.All, CustomSecAttributeDefinition.ReadWrite.All, CustomSecAttributeAssignment.ReadWrite.All, Policy.ReadWrite.AuthenticationMethod, Policy.ReadWrite.SecurityDefaults, Policy.ReadWrite.CrossTenantAccess. An agent cannot rewrite the access packages, lifecycle workflows, or security attributes used to oversee it — including the attributes that drive Conditional Access decisions about the agent itself.

Most of these land on application permissions, which is the autonomous path — the case where no human is present. A subset is blocked for delegated access as well.

The principle underneath

Six families, one rule:

An agent may act within its authority. It may never alter its authority — or the machinery that grants, reviews, and revokes it.

That is a cleaner articulation of agent least-privilege than most of what’s currently in circulation, and it came out of a product decision rather than a framework committee.

Prohibition six is the one worth sitting with. Traditional service-account governance never had to think about it, because a service account doesn’t reason about its own constraints. An autonomous agent operating against a goal, with permission to modify its own oversight configuration, has an obvious and entirely non-malicious path to removing friction. You don’t need to posit a rogue agent for that to end badly. You just need a capable one, an ambiguous objective, and standing write access to the wrong policy object.

Two things this is not

It is not a ceiling. It’s a floor. Nothing here stops you granting an agent a genuinely dangerous combination of permissions Microsoft hasn’t blocked. And because permissions are defined on the blueprint and inherited by every identity created from it, an over-scoped template multiplies across the fleet. Blueprint review is still the control that matters — the block list just means the very worst grants are no longer available to get wrong.

It is not portable. This binds Entra agent identities. It does nothing for the agents in the same estate running on Bedrock, Vertex, an agent framework on your own Kubernetes, or embedded in a SaaS product you bought last quarter. Those agents hold credentials issued by other systems, under other authority models — and I have not found an equivalent published, enforced prohibition list from the other major agent platforms. If one exists, I’d genuinely like to be pointed at it.

That gap is the actual finding here. One platform in your estate now has an enforced agent authority model. The rest have whatever your team happened to configure.

Six questions for every agent platform you run

Take the prohibitions, drop the vendor, and you have a checklist that works anywhere:

1. Can an agent running on this platform create another agent, service principal, or machine identity?
2. Can it grant or expand its own permissions, or approve a pending consent or access request?
3. Can it modify roles, policies, or directory objects?
4. Can it read or reset credentials and authentication methods?
5. Can it hold tenant-wide or bucket-wide read on content stores?
6. Can it modify the logging, review, or governance configuration that covers it?

Run that against each platform and write down the answers. If any answer is yes — or, far more commonly, “I don’t know” — you don’t have an agent authority model. You have a service account with a language model attached, and the only thing standing between it and your directory is that nobody has asked it to try.

The six controls are cheap to state and awkward to verify, which is exactly why they’re worth doing before your agent population gets larger. Mine is the same argument I’ve been making about non-human identity generally: the governance isn’t exotic, it’s the discipline we already know, applied to a population that grew faster than the programme did. The full control set I use is in A Control Framework for Non-Human & Agentic Identity, and nhi-scan risk-tiers the identities themselves.

The list is Microsoft’s. The question isn’t.

---

Views are my own. Everything above is drawn from public Microsoft documentation.