The Identity Problem:
Classic vs Modern, OBO & Maker Credentials

The Classic Agent Problem — The Gap Nobody Talks About

Before Entra Agent ID was introduced, Copilot Studio agents were registered as standard Service Principals (Enterprise Applications) in Entra — what are now called Classic Agents. Most organisations with existing Copilot Studio deployments have Classic Agents. This is the most underappreciated structural gap in Microsoft's agent security story.

Maker Credentials — The Copilot Studio–Specific Risk

Beyond OBO, Copilot Studio introduces a structurally distinct and in many ways more dangerous authentication pattern: maker credentials. When a Copilot Studio agent is connected to tools (SharePoint, Outlook, Teams, etc.), it authenticates to those services as the person who built the agent — not the person using it.

Comparing the Three Authentication Patterns

OAuth 2.0 On-Behalf-Of — The Standard Agent Pattern

For agents outside Copilot Studio (Azure AI Foundry, custom agents), OBO remains the primary token mechanism. The agent receives a token derived from the invoking user's access token — it acts on behalf of the user, not as an independent identity.

Agent Name Sync — An Operational Gap

Both Classic and Modern agents share a documented bug: when an agent is renamed in Copilot Studio after initial creation, the name stored in Entra Agent ID is not updated. The Entra portal continues to show the original name assigned at creation — typically Agent # (a number).

Entra Agent ID — Status & What It Delivers for Modern Agents

What Security Products Apply to Classic vs Modern Agents

This is the single most important table for architects deploying Copilot Studio agents. The gap between Classic and Modern is not marginal — it determines whether any Entra security product applies at all.

How Copilot Studio Agents Actually Authenticate

Field research by Derk van der Woude (March 2026) identifies four distinct authentication configurations for Copilot Studio agents — each with a very different risk profile. Knowing which pattern your agents use is the first step to securing them.

Detecting Maker Credentials with Precision

The following KQL (field-validated by Derk van der Woude) detects maker credentials at the connector level — checking both AgentToolsDetails and AgentTopicsDetails for where maker mode is actually configured. This is more precise than checking only the agent-level auth type.

let base = AIAgentsInfo
| summarize arg_max(Timestamp, *) by AIAgentId
| where AgentStatus == "Published";
let directActions = base
| mv-expand detail = AgentToolsDetails
| where detail.action.connectionProperties.mode == "Maker"
| extend ActionType = "FromTools", Action = detail.action
| project-reorder AgentCreationTime, AIAgentId, AIAgentName,
    UserAuthenticationType, CreatorAccountUpn;
let topicActions = base
| mv-expand topic = AgentTopicsDetails
| extend topicActionsArray = topic.beginDialog.actions
| mv-expand Action = topicActionsArray
| where Action.connectionProperties.mode == "Maker"
| extend ActionType = "FromTopic"
| project-reorder AgentCreationTime, AIAgentId, AIAgentName,
    AgentStatus, CreatorAccountUpn, OwnerAccountUpns, Action;
directActions
| union topicActions
| sort by AIAgentId, Timestamp desc

Detecting App Registration Agents Calling Microsoft Graph

Finds agents using HTTP Request actions to graph.microsoft.com or management.azure.com — indicating App Registration authentication (pattern ③ or ④). Delegated = low risk. Application permissions = very high risk.

AIAgentsInfo
| summarize arg_max(Timestamp, *) by AIAgentId
| where AgentStatus != "Deleted"
| mvexpand Topic = AgentTopicsDetails
| where Topic has "HttpRequestAction"
| extend TopicActions = Topic.beginDialog.actions
| mvexpand action = TopicActions
| where action['$kind'] == "HttpRequestAction"
| extend Url = tostring(action.url.literalValue)
| extend ParsedUrl = parse_url(Url)
| extend Host = tostring(ParsedUrl["Host"])
| where Host has_any("graph.microsoft.com", "management.azure.com")
| project-reorder AgentCreationTime, AIAgentId, AIAgentName,
    ParsedUrl, Url, Host, AgentStatus,
    CreatorAccountUpn, OwnerAccountUpns

Source: Derk van der Woude — Your Copilot Studio agent is acting as someone, do you know who? (March 2026)

The Agent Sprawl Problem

Microsoft formally defines agent sprawl as the uncontrolled expansion of agents across an organisation without adequate visibility, management, or lifecycle controls. It emerges when business units create agents without formal IT oversight (shadow AI), when agents created for temporary purposes remain in production indefinitely, and when agent permissions exceed actual requirements and are never reviewed.

Beyond MCP — The A2A Standard

Microsoft's Entra Agent ID platform now supports agent-to-agent (A2A) discovery and authorisation alongside MCP. A2A is an emerging standard protocol for authenticated communication between agents — enabling orchestration agents to delegate tasks to sub-agents with proper identity verification. Without A2A controls, an adversary can inject a malicious agent into an orchestration chain or intercept inter-agent communications.

Source: Microsoft Entra security for AI overview (April 2026)

Practical Controls — Ranked by Availability