COPILOT STUDIO · MICROSOFT FOUNDRY · SECURITY

Copilot Studio
vs Microsoft Foundry

Two platforms. Very different security models. This page is your condensed security handbook for both — what controls apply, what the gaps are, and what to do first.

🛡️

BEFORE ANYTHING ELSE · DAY 1

Set up the Security Dashboard for AI

Covers both Copilot Studio and Microsoft Foundry agents. Single pane of glass for your entire AI estate — posture, inventory, risk signals. GA, no additional licence. Takes 30 minutes.

→ Setup Guide

Platform Overview

Which platform are you securing?

The security controls, gaps, and runbooks are fundamentally different depending on which platform your agents run on. Start here to make sure you're looking at the right controls.

🤖

Microsoft Copilot Studio

LOW-CODE · POWER PLATFORM · MAKERS

Who uses it: Makers, Copilot admins, Power Platform teams — people who build agents with low-code tools, not developers writing code

What it produces: Copilot Studio agents published to Teams, SharePoint, websites — conversational agents connecting to M365 data

Critical distinction: Classic agents (most existing deployments) sit outside the Entra security perimeter. Modern agents (new) get full Entra coverage

Primary risk surface: Maker credentials, no-auth agents, org-wide sharing, agent sprawl, any-user-can-change-auth

Primary detection surface: AIAgentsInfo table in Defender Advanced Hunting

🏭

Microsoft Foundry

CODE-FIRST · AZURE · DEVELOPERS

Who uses it: Developers, solution architects, AI engineers — people building custom AI agents and workloads in Azure using SDKs and code

What it produces: Custom AI agents, RAG pipelines, multi-agent orchestration, enterprise AI applications — deployed as Azure resources

Critical distinction: Uses modern Agent ID authentication (OAuth 2.0) by default — CA for Agents and ID Protection apply. Much stronger baseline than Classic Copilot Studio agents

Primary risk surface: Logging gaps (nothing collected by default), content capture governance, RBAC at resource vs project level, supply chain

Primary detection surface: Azure Monitor Diagnostic Settings, Application Insights, Entra ID sign-in logs

Side-by-Side Comparison

Security posture at a glance

Security Control	Copilot Studio	Microsoft Foundry
Entra Agent ID	⚠️ Modern agents only — most existing deployments are Classic and excluded	✅ Supported — agents are Entra identities by default
Conditional Access for Agents	❌ Does NOT apply to Copilot Studio agents	✅ Applies — OAuth 2.0 Agent ID authentication
ID Protection for Agents	❌ Classic agents only — Modern agents supported	✅ Supported
Identity Governance (lifecycle)	⚠️ Modern agents only	✅ Supported via Entra ID Governance
Defender real-time protection	✅ Copilot Studio agents (Defender for Cloud Apps)	✅ Defender for Cloud AI security posture
Sentinel analytics rules	✅ AIAgentsInfo table queries	✅ Azure Monitor + App Insights tables
Prompt Shield / Content Safety	✅ Built-in via M365 Copilot layer	✅ Content Safety SDK — opt-in per agent
DLP / Purview	✅ DLP for M365 Copilot (GA March 31 2026)	✅ Azure data governance applies
Inventory / discovery	✅ Agent 365 + AIAgentsInfo table	⚠️ Azure Resource Manager + Entra Agent ID — no unified agent-level inventory table equivalent
Logging — default state	✅ Some data in AIAgentsInfo automatically	⚠️ Nothing collected by default — all logging is opt-in
Red teaming	⚠️ No native Copilot Studio red teaming tool	✅ AI Red Teaming Agent in Microsoft Foundry
Supply chain scanning	⚠️ Limited — connector risk is the main vector	✅ Defender for Cloud CSPM, AI model scanning

Copilot Studio — Security Condensed

The five authentication patterns — risk at a glance

Every Copilot Studio agent uses one of five authentication patterns. The pattern determines the risk level, what controls apply, and how you detect it.

①

End User Credentials (OBO)

Auth with Microsoft → End user credentials

LOW RISK

UserAuthenticationType == "Integrated"

②

Maker-Provided Credentials

Auth with Microsoft → Maker-provided credentials

HIGH RISK

AgentToolsDetails.mode == "Maker"

③

App Registration — Delegated

Authenticate manually → Entra ID V2 (delegated)

LOW RISK

HTTP Request + delegated token

④

App Registration — Application Permissions

Authenticate manually → Entra ID V2 (application)

VERY HIGH RISK

HTTP to graph.microsoft.com + client creds

⑤

Agent's User Account

Full human identity — mailbox, Teams, SharePoint access

VERY HIGH RISK

Entra ID Governance lifecycle required

The Classic vs Modern gap — the most important distinction

Most existing Copilot Studio deployments are Classic agents. They authenticate as service principals or via OBO — not as modern Agent ID identities. This means CA for Agents, ID Protection for Agents, and Entra lifecycle governance do not apply. The entire Entra security product stack Microsoft markets for agent security only works with Modern agents.

⚠️ The gap nobody talks about

Microsoft does not clearly document this distinction in its product marketing. Most security teams assume that purchasing Entra Agent ID or enabling CA for Agents covers their Copilot Studio estate. It does not — unless agents have been specifically created as Modern agents using the Agent ID framework. Field research confirms this is the default state of most enterprise Copilot Studio deployments.

Copilot Studio — 30-minute audit

Run these in Defender Advanced Hunting to get immediate visibility. Any result from Query 1 or 2 is a critical finding.

// Query 1: No-auth agents (critical — run first)
AIAgentsInfo
| summarize arg_max(Timestamp, *) by AIAgentId
| where AgentStatus == "Published"
| where UserAuthenticationType == "None"
| project AIAgentName, CreatorAccountUpn, OwnerAccountUpns, AgentCreationTime

// Query 2: Change-detection — auth downgraded to None (use as Sentinel Analytics Rule)
AIAgentsInfo
| summarize arg_max(Timestamp, *) by AIAgentId
| where AgentStatus == "Published"
| order by AIAgentName
| extend PreviousAuthType = prev(UserAuthenticationType, 1)
| where UserAuthenticationType == "None" and PreviousAuthType != "None"
| project AIAgentName, PreviousAuthType, UserAuthenticationType, ReportId = tostring(AIAgentId), Timestamp

// Query 3: Maker credentials (field-validated — checks both Tools and Topics)
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"
| 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

Copilot Studio — Critical Gaps

Gap	Risk	Interim Mitigation
Classic agents outside Entra perimeter	⚠️ Critical	Inventory via AIAgentsInfo; enforce end-user auth in Power Platform admin; manually recreate critical agents as Modern
Any user can change another agent's auth type to None	⚠️ Critical	Deploy change-detection Sentinel Analytics Rule; restrict Copilot Studio access via Managed Environments
Maker credentials blast radius	⚠️ High	Enforce end-user auth per agent; PAM hygiene on developers who build agents; audit via Query 3 above
Portal inventory count inconsistency	⚠️ High	Trust AIAgentsInfo table as primary source; treat portal counts as approximate
Agent sprawl — no lifecycle enforcement	⚠️ High	Assign owners to all agents; use access packages for time-bound permissions; quarterly AIAgentsInfo audit

Microsoft Foundry — Security Condensed

The Foundry resource model — why it matters for security

Microsoft Foundry uses a layered resource model that most teams bolt security onto after deployment — when the decisions that matter most are already harder to change.

Foundry Resource

Microsoft.CognitiveServices/accounts

Networking · Private endpoints

RBAC · Managed identity

Encryption keys · Model deployments

Service connections

Security-sensitive: Management-plane operations (key rotation, RBAC changes, project creation) all originate here

Foundry Projects (one-to-many)

Microsoft.CognitiveServices/accounts/projects

Inherit resource networking + encryption

Agent builds · Evaluations · Prompt flows

Application Insights connection

Critical: Diagnostic Settings do NOT cascade from resource to projects — each project needs its own separate configuration

Microsoft Foundry — the four logging layers

Foundry generates telemetry across four distinct layers. The Activity Log is the only one that requires no configuration. Everything else is opt-in and off by default.

Layer	What it captures	Default state	SecOps priority
Layer 1 · Activity Log	Resource CRUD, RBAC changes, key rotation, network config, model deployments	✅ Automatic	⭐⭐⭐ Essential — route to Sentinel
Layer 2a · Diagnostic Settings (Resource)	Audit (data plane access), RequestResponse (inference metadata — no prompt content), AzureOpenAIRequestUsage, Trace	❌ Off by default — explicit opt-in per resource	⭐⭐⭐ Enable Audit + RequestResponse for SecOps
Layer 2b · Diagnostic Settings (Project)	Audit (agent operations — runs, file uploads, evaluations), Trace, AllMetrics	❌ Off by default — separate config per project	⭐⭐⭐ Enable Audit per project — does NOT inherit from resource
Layer 3 · Application Insights	Full agent runtime traces, tool call chains, prompt + completion content (if enabled), exceptions, dependencies	❌ Off by default — SDK connection per project	⭐⭐ Enable for agent-level behavioural visibility
Identity · Entra ID logs	Non-interactive sign-ins, service principal sign-ins, agent lifecycle events	❌ Tenant-level diagnostic setting — separate config	⭐⭐⭐ Required — without this, agent auth plane is a blind spot

⚠️ Two critical Foundry logging gotchas

1. Diagnostic Settings don't cascade. Settings configured at the Foundry resource level do NOT apply to projects. Every new project needs its own separate Diagnostic Settings configuration — or you accept the gap silently.

2. RequestResponse does not contain prompt content. By design. If investigation requires content-level visibility, Application Insights with content capture enabled is the only source — but enabling AZURE_TRACING_GEN_AI_CONTENT_RECORDING_ENABLED creates direct responsibility for storage, access controls, and retention of potentially sensitive data (PII, secrets, business data).

Microsoft Foundry — what to enable for SecOps

✅ ENABLE FOR SECOPS

Priority logging sources

Activity Log → route to Sentinel workspace

Entra ID sign-in + audit logs (tenant-level)

Diagnostic Settings Audit — at resource AND each project

Diagnostic Settings RequestResponse — at resource level

Application Insights — workspace-based, linked to same LAW as Sentinel

⚠️ FOUNDRY-SPECIFIC GAPS

What to watch

No logging by default — data never collected cannot be recovered

New projects don't inherit logging config — governance process required

Content capture governance must precede enabling prompt logging

App Insights must be workspace-based for Sentinel to query it

RBAC at resource scope cascades to projects — least-privilege may require project-level assignments

📌 Sources

Copilot Studio content: field research by Derk van der Woude (Microsoft Security MVP) · Microsoft Entra security for AI overview (April 2026) · Microsoft Zero Trust Assessment Workshop AI section.
Microsoft Foundry logging: Cyphora.io — Microsoft Foundry Logging (April 2026) · Microsoft Learn documentation.

← PREVIOUSPlaybooks NEXT →Changelog

STAY UPDATED

Get notified when Microsoft AI security changes

Monthly updates on new controls, GA announcements, and critical gaps — direct to your inbox.

Subscribe to updates →

aiagentsecurity.substack.com · Free · No spam