Least-Privilege Scoping for Agent Permissions
An agent should hold the smallest set of permissions that lets it finish its job. This topic walks through how to scope identity, tool access, and data reach — using Foundry's per-agent Entra identity, GitHub Copilot's MCP and trusted-directory policies, and the classic read/write/admin ladder.
Least-Privilege Scoping for Agent Permissions
An agent that can do more than it needs is a liability. Least privilege says: grant the smallest set of permissions that lets the agent finish its current job, on its current data, in its current scope — and nothing more. The exam expects you to know both the principle and the concrete knobs.
Three dimensions to scope
- Identity — who is the agent acting as? Itself (agent identity), the requesting user (OBO), or a shared service principal (almost always wrong)?
- Surface — which tools, APIs, paths, and URLs can it reach? Foundry's tool catalog and GitHub Copilot's trusted-directory / MCP policies are the levers here.
- Reach — within those tools, which records, repos, or rows is it scoped to?
The privilege ladder
Sort actions by the privilege they need — then grant the lowest rung that still works:
Sort by memory layer
Sort each agent action into the *lowest* privilege tier that lets it complete the task.
The Microsoft and GitHub levers
| Lever | Where | What it scopes | | --- | --- | --- | | Agent identity (Entra) | Foundry Agent Service | Auth identity per agent; RBAC applies | | On-Behalf-Of (OBO) | Foundry MCP / tool auth | Agent inherits the calling user's permissions | | Tool catalog selection | Foundry | Subset of MCP server actions an agent may use | | Trusted directories | GitHub Copilot | Path allow-list for tool reads/writes | | MCP server policies | GitHub Copilot Business/Enterprise | Which MCP servers developers may discover |
Exam tip: when a question offers "give the agent admin so it never gets stuck," the answer is always no. The right answer is to scope down and add a HITL gate for the rare admin path.
Quick check
Skim the keyTerms and pitfalls above before the exam — least-privilege questions are almost always solved by naming the correct layer (identity vs surface vs reach) and the correct pattern (OBO vs agent identity).
Where this shows up on the exam
GH-600 likes to bait you with options that "simplify ops." Simplification at the cost of broad permissions is the wrong answer. The right answer is whichever option restricts the agent's reach without breaking its job.
Key terms
- Least privilege
- The principle that an identity (human or agent) is granted only the permissions strictly needed for its current task — and nothing more.
- Agent identity
- A first-class Microsoft Entra identity assigned to the agent itself so its actions are auditable and scoped without sharing credentials with users.
- On-Behalf-Of (OBO)
- An authentication pattern where the agent calls a downstream tool *as the requesting user* — preserving the user's permissions rather than escalating to the agent's own.
- Tool scope
- The subset of a tool's capabilities exposed to the agent (e.g., the Azure DevOps MCP server can be limited to a chosen subset of actions in the Foundry tool catalog).
- Trusted directory
- A path allow-list in GitHub Copilot that restricts which files/directories agent tools may read or write.
Common pitfalls
- Granting an agent a broad service principal because it is *easier* than scoping. The first incident report will read 'the agent had write access to everything.'
- Confusing OBO with agent-identity. OBO means 'act as the user'; agent-identity means 'act as the agent.' Mixing them up either over-grants or breaks auditability.
- Scoping at install time and never re-scoping. As tasks change, permissions drift upward and never down. Schedule periodic reviews.