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 (Microsoft 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)

Four Agent Identity Governance Concepts

Entra Agent ID introduces three distinct accountability roles — Owner, Sponsor, and Approver — plus a new failure mode (orphaned identities) that security architects need to understand separately. The Approver is what operationalises sharing controls; without an explicit IT approval gate, sharing limits become a guideline rather than an enforced control.

Detecting Ownerless & Orphaned Modern Agents (Graph API)

AIAgentsInfo KQL covers Copilot Studio agents (Classic and Modern) and Foundry, marketplace, and LOB agents registered with Agent 365. Use the RegistrySource column to distinguish: RegistrySource == "PowerPlatform" for Copilot Studio agents via the Power Platform connector; RegistrySource == "A365" for Agent 365-registered agents. Most existing KQL queries on this page target Copilot Studio (PowerPlatform) — see Playbook 01 Step 8 for A365-specific queries. For Modern agent Owner/Sponsor checks, use PowerShell via Microsoft Graph (Agent ID Administrator role required — Global Reader returns 403).

# Find Modern agents missing Owner or Sponsor
Connect-MgGraph -Scopes "AgentIdentity.Read.All"

$agents = Invoke-MgGraphRequest -Method GET `
    -Uri "https://graph.microsoft.com/beta/servicePrincipals/microsoft.graph.agentIdentity" `
    -OutputType PSObject

foreach ($agent in $agents.value) {
    $owners   = Invoke-MgGraphRequest -Method GET `
        -Uri "https://graph.microsoft.com/beta/servicePrincipals/$($agent.id)/owners" `
        -OutputType PSObject
    $sponsors = Invoke-MgGraphRequest -Method GET `
        -Uri "https://graph.microsoft.com/beta/servicePrincipals/$($agent.id)/sponsors" `
        -OutputType PSObject
    $flags = @()
    if ($owners.value.Count -eq 0)   { $flags += "No Owner" }
    if ($sponsors.value.Count -eq 0) { $flags += "No Sponsor" }
    if ($flags.Count -gt 0) {
        Write-Host "$($agent.displayName) | $($flags -join ', ')" -ForegroundColor Red
    }
}
Disconnect-MgGraph

Source: Thalpius — Microsoft Ownerless Agents: The silent risk in your Entra tenant (March 2026)

Three Agent Categories + The Blueprint Architecture

The Entra Agent ID portal shows three distinct agent categories — not two:

The Four Entra Agent ID Objects

The Entra Agent ID platform introduces four distinct object types — not just "agent" and "blueprint". Understanding all four is essential for inventory and governance work.

Risk detection for agent identities

Source: Microsoft Learn — ID Protection for Agents (Preview)

Microsoft Entra ID Protection now includes agent-specific risk detection. It establishes a baseline for each agent's normal activity, then flags anomalies as risky agent detections. Risk signals feed directly into Conditional Access for Agent ID — a CA policy can automatically block access when an agent's risk level hits High.

Licence: Entra P2 (included during preview). Applies to: Modern agents with Entra Agent ID only.

Six risk detections

Actions on risky agents

From the Risky Agents report in Entra ID Protection:

Agent segmentation with custom security attributes

Source: Microsoft Learn — CA for Agent ID (Preview)

The recommended approach for CA policy scoping is to use custom security attributes assigned to agents and resources. This enables precise, scalable policy targeting without manually managing object IDs.

Example pattern: create an attribute set AgentAttributes with attribute AgentApprovalStatus (values: New, In_Review, HR_Approved, Finance_Approved, IT_Approved). Assign attributes to agents and resources. CA policy: block all agents EXCEPT those tagged HR_Approved from accessing resources tagged HR. This is the governance model for agent segmentation at scale.

CA policies can scope agents by: all agent identities in tenant, specific agent identities by object ID, agents by custom security attribute, agents grouped by their Blueprint, or all Agent Users.

How Blueprint credentials work — and why FIC is the right choice

Source: Derk van der Woude — Entra Agent ID FIC Deep-Dive (April 2026)

When an agent authenticates, it goes through a two-phase flow:

T1 controls who is trusted to get a token. T2 controls what they are allowed to do once trusted. These are governed independently — you can have tightly scoped T2 permissions on a Blueprint that uses weak T1 credentials, or vice versa.

Blueprint credential types (T1) — preferred to least preferred

A Blueprint can use one of three credential types to complete T1. Source: Carlos Suarez (Microsoft) — Entra Agent ID Architecture.

Graph API scopes for Blueprint operations

Blueprint creation and credential management requires specific scopes beyond the read-only AgentIdentity.Read.All scope used for inventory queries:

Securing agent identities at enterprise scale

Source: Carlos Suarez (Microsoft) — Entra Agent ID Govern and Secure (April 2026)

Agent identities are subject to the same governance and security controls as human identities. Microsoft Entra provides seven pillars for agent governance — each addressing a distinct layer of the identity security stack.

Network-level security controls for Copilot Studio agent traffic

Source: Microsoft Learn — Secure Web and AI Gateway for Copilot Studio agents (Preview)

Global Secure Access for agents extends the same network security policies you apply to users to Copilot Studio agent traffic — web content filtering, threat intelligence filtering, and network file filtering. Agent traffic is forwarded to Global Secure Access's globally distributed proxy service and evaluated against your security policies before reaching external resources.

Practical Controls — Ranked by Availability