UPDATED · FIELD RESEARCH · MARCH 2026

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

The identity layer for AI agents is more fragmented and risky than Microsoft's marketing suggests. Three overlapping problems — Classic vs Modern agents, OBO token delegation, and Copilot Studio maker credentials — each undermine the agent security story independently. All three coexist in most enterprise deployments today.

⚠ MOST COPILOT STUDIO AGENTS ARE CLASSIC — NO ENTRA PROTECTION
⚠ MAKER CREDENTIALS WORSE THAN OBO IN COPILOT STUDIO
⚠ AGENT ID: PREVIEW · FRONTIER ONLY — UNCHANGED AT RSAC 2026
Classic vs Modern Agents

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.

⚠ Classic Agents Cannot Be Protected by Entra Security Products

Classic Agents are completely outside the Entra Agent ID security perimeter. They receive no ID Protection for Agents, no Conditional Access for Agents, no Agent lifecycle governance. The Entra security products that Microsoft markets for agent protection only work with Modern Agents. Microsoft has acknowledged a migration tool is planned — it does not exist yet. The only current workaround is to recreate agents from scratch as Modern Agents, which is impractical at scale.

DimensionClassic AgentModern Agent
Entra registration typeService Principal (Enterprise App)Agent Identity (Agent Blueprint)
ID Protection for Agents❌ Not supported✓ Supported (preview)
Conditional Access for Agents❌ Not supported✓ Supported (preview)
Agent lifecycle governance❌ Not supported✓ Sponsor model available
Owner modelPower Virtual Agent Service + creator as Owner — this introduces credential abuse risk (owner can add client secrets)Sponsor model — creator in Notes field, not Owner role
Name sync with Copilot StudioName stays as original Agent # — not updated on renameSame bug — name not synced on rename
Migration pathRecreate from scratch OR await Microsoft migration toolN/A — is the target state
Where most production agents are todayMost existing Copilot Studio agentsOnly newly created agents with setting enabled
⚠ The Owner vs Sponsor Distinction Matters

For Classic Agents, the user who created the agent is added as an Owner of the Enterprise Application. An Owner can add client secrets, bypassing Conditional Access and MFA, abuse federated credentials for cross-tenant access, and is a high-privilege technical role. For Modern Agents, the creator should be listed as a Sponsor in the Notes field — a business accountability role without these technical powers. Using the Owner option on Classic Agents introduces real credential abuse risk. Field research by Derk van der Woude confirms this is the default behaviour in production environments.

Maker Credentials

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.

OBO Flow
Standard agents: Agent inherits token from the invoking user. If User A asks the agent to send an email, the email is sent with User A's permissions. Audit log shows User A.
Maker Creds
Copilot Studio agents: Agent authenticates as the maker — the person who built it. If User A (developer, admin) built the agent and User B (intern) interacts with it, the agent acts with User A's admin permissions. Audit log may show the service, not User A.
⚠ Blast Radius
Combined with org-wide sharing (one toggle): A developer with admin rights builds an agent, enables org-wide sharing, and sets no authentication. Every employee in the organisation can now interact with the agent using the developer's admin-level permissions. This is the single most dangerous default configuration pattern in Copilot Studio deployments.

Comparing the Three Authentication Patterns

PatternWho Is AuthenticatedAudit TrailBlast RadiusMitigation
OBO (standard)Invoking userShows user UPN (not agent)User's own permissionsUser PAM hygiene
Maker credentials (Copilot Studio)Agent builderMay show service, not makerMaker's full permissions × all users of agentEnforce end-user auth; restrict sharing scope
No authenticationAnyone in TeamsNoneMaker's permissions × entire org, no login requiredPower Platform admin enforcement; KQL detection
OBO Token Flow

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.

Step 1
User authenticates. Entra ID issues access token AT₁ scoped to the user's permissions.
Step 2
Agent host presents AT₁ with an OBO grant. Entra issues AT₂ for the downstream resource — still representing the user's identity.
Step 3
Agent uses AT₂ to access resources. The resource sees the original user's identity — not the agent's identity.
Step 4 (A2A)
Multi-agent chains multiply delegation hops: AT₁ → AT₂ → AT₃. Every downstream service sees a derivative of the original user identity. Each hop risks scope escalation.
⚠ Result
Audit logs attribute actions to the user, not the agent. Agent scope cannot be narrowed below the user's own permissions. If the user is overprivileged, so is every agent they invoke.
The Name Sync Bug

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).

⚠ Impact on Security Operations

Entra security products — ID Protection for Agents, Conditional Access, and the Agent ID portal — all reference the original names. In any enterprise with more than a handful of agents, this makes per-agent policy management in Entra nearly unworkable. You cannot create a meaningful Conditional Access policy for Agent #47. Microsoft has confirmed this inconsistency and states work is in progress — no fix timeline confirmed. Field workaround: use the Agent ID object-ID (not name) as the primary key for agent identification, cross-referenced via script against the Power Platform Admin Environment URL.

Entra Agent ID

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

⚠ Still Preview — Not Announced as GA at RSAC 2026 — Modern Agents Only

Entra Agent ID remains in limited preview for frontier/large enterprise programs. Even when it reaches GA, it will only apply to Modern Agents — Classic Agents (the majority of existing Copilot Studio deployments) require migration first.

Purpose-scoped Agent Identity
Each Modern Agent registered as a distinct non-human principal — separate from the user who created or invoked it. Enables per-agent audit trails and policy scoping. Does not apply to Classic Agents.
Modern Agents only · Not yet GA
Agent Identity Blueprint
Parent template for creating Agent Identities (1:N). Acts as a governance container for IT management. Blueprint-level permissions are inherited by all Agent Identities. Max 250 Agent Identities per Blueprint.
Modern Agents only · Not yet GA
Sponsor Requirement
Every Modern Agent should have a named Sponsor (business accountability role) and Owner (IT management role). These are distinct from the Owner role on Classic Agents — the Sponsor has no ability to add credentials or bypass CA.
Not yet GA⚠ Classic agents use Owner = risk
Per-agent Conditional Access
Once a Modern Agent has its own identity, CA policies can target it specifically. In practice, the name sync bug means policy management requires using object-IDs not names. The CA Optimization Agent adds recommendations but true per-agent scoping still requires Agent ID GA + Modern Agent migration.
Dependent on Agent ID GA + Modern migration
What to Do Today

Practical Controls — Ranked by Availability

ControlWhat It DoesStatusLimitation
Enforce end-user authentication per agentRequire users to authenticate with their own credentials — prevents maker credential blast radiusAvailable now (Power Platform admin)Must be set per agent; not default
Restrict org-wide sharingUse Managed Environments to set numerical sharing limits or restrict to security groupsAvailable now (Managed Environments)Requires Power Platform admin
Detect no-auth agents via KQLAIAgentsInfo | where UserAuthenticationType == "None"Available (requires AI Agent Inventory enabled)AI Agent Inventory requires Defender + Power Platform admin collaboration
Detect ownerless agents via KQLAIAgentsInfo | where isempty(OwnerAccountUpns)Available (requires AI Agent Inventory enabled)Same setup requirement
Migrate Classic → Modern AgentsEnables Entra security product coverage; requires recreating agents from scratchManual only — migration tool not yet availableImpractical at scale; migration tool planned
User PAM hygieneLeast-privileged makers → least-privileged agent credentialsAvailable via PAM toolingIndirect; does not change the structural authentication problem
Entra Workload IdentityApp-level service principal scoping for non-Copilot-Studio agentsGANot purpose-scoped per agent-instance
Defender for Cloud Apps real-time protectionBlocks tool invocations during suspicious prompt activity (XPIA, UPIA) for Copilot Studio agentsPreview · requires both Defender + Power Platform admin setupComplex 3-step setup; if no decision in 1 second, tool executes anyway