The five Foundry roles

Most people learning Foundry's access model learn four roles. There are five, and
the one that gets missed is the one a least-privilege question is most likely to be
about.

The ladder, narrowest first

Foundry Agent Consumer — "Grants access to interact with agent endpoints in a
Foundry project. Least-privilege access role for principals that only need to
interact with agents."

This is the role for everyone who uses an agent and never builds one. Call the
endpoint, and nothing else. No reading the project, no data actions, no publishing.
If a scenario describes a service principal or a group of end users who only need
to talk to an agent, this is the answer — and it is not on most people's list.

Foundry User — build and test in a project, read projects and resources, call
endpoints. This is least privilege for developers, and it is the one assigned
automatically when you create a project through the portal (assuming you have
rights to assign roles at all).

Foundry Project Manager — everything above, plus the ability to publish
agents, plus the ability to assign Foundry User to other people.

Foundry Account Owner — creates accounts and projects, manages models, assigns
roles. And notably cannot build.

Foundry Owner — all of it.

Two things in that ladder worth pausing on

Publishing needs Foundry Project Manager at minimum. Building an agent and
publishing an agent are separate privileges. That is a promotion gate expressed as
access control, and it is a sensible one — dev access and production approval are
different decisions and should be held by different people.

Account Owner cannot build. This looks like an omission and is deliberate: it
separates the person who provisions the environment from the person who develops in
it. Someone can manage the platform without being able to reach the data inside a
project.

The rename, and why it changes nothing

Microsoft renamed these roles, and both names are still circulating:

"Foundry User, Foundry Owner, Foundry Account Owner, and Foundry
Project Manager were previously named Azure AI User, Azure AI Owner, Azure AI
Account Owner, and Azure AI Project Manager… The role IDs and core permissions
are unchanged by the rename."

That last sentence is the exam-relevant part. If an option claims the rename
altered what a role can do, it is wrong. And if two options are the same role under
its old and new names, neither can be the answer — you are being asked whether you
know they are the same thing.

There is a practical consequence too, and Microsoft states it: use the role
definition GUID rather than the name in code, because the names are still rolling
out. Foundry User is 53ca6127-db72-4b80-b1b0-d745d6d5456d. Access control written
against names is access control that breaks when the names move.

Two roles named to look right

Both of these are excellent distractors, because both names read as correct.

"Don't assign built-in roles that start with Cognitive Services. These roles
are designed for accessing AI Services resources directly and don't apply to
Foundry scenarios."

"Similarly, don't use the Azure AI Developer role for Foundry work. Despite
the name, this role is scoped to Azure Machine Learning workspaces and Foundry
hubs, not to Foundry projects or Foundry hosted agents."

"Azure AI Developer" is exactly what you would guess the role for an AI developer
was called. It is the wrong one. Microsoft anticipated the confusion clearly enough
to write "despite the name" into the documentation, which is about as strong a
signal as you get that it turns up in practice.

The trap

Reach for the role that sounds like the job title and you will get this wrong twice
— once with Azure AI Developer, once by giving a consumer Foundry User because it
sounds like the basic tier.

The question to ask is not "what is this person called" but "what does this
principal actually need to do". Someone who only calls an endpoint needs Foundry
Agent Consumer. Someone who builds needs Foundry User. Someone who ships to
production needs Foundry Project Manager. The names are a poor guide; the
permission table is a good one.