Copilot Studio Agent Security lessons learned from the field
This blog continues from my previous blog about Entra Agent Identities demystified. The previous blog was theoretical while this blog is about practical Security challenges due to the speed of innovation of AI Agents versus product development for Security for AI Agents [Preview].
Issue #1 - ‘Classic’ Copilot Studio Agent Owner
Classic Agents can have HPA (High Privileged Access permissions) configured while modern Agents are restricted from HPA permissions, see Microsoft for details.
For example you don’t want give Microsoft Graph API Directory.ReadWrite.All permissions or let Agents create other Agents.
As discussed in my previous blog, classic Agents created in Copilot Studio are created as Enterprise Applications [Service Principals] in Entra. The owner of this type of Enterprise Application is the Power Virtual Agent Service while the Sponsor of a modern Agent is (and should be) the user who created the agent.
An agent created with the free version of Copilot (grounded in public web data only) only has the service above as owner (lacks accountability), an agent created with the licensed version (advanced; can access corporate data) has the service above plus the user who created the agent (introduces risk).
To find the user who created the classic Agent from Copilot Studio, I created a script which can be tested from my GitHub.
Disclaimer: the script only has read-only permissions and is tested in my two lab environments so any feedback is welcome, will test in larger environment soon
Another option is to use the AI Agent Inventory feature in Microsoft Defender Cloud Apps [thanks to my friend Robbe van den Daele for the tip in his blog], see my previous blog for details how to setup.
AIAgentsInfo
| where AgentStatus contains "Created"
| distinct AIAgentName, AgentStatus,AgentCreationTime, CreatorAccountUpn, OwnerAccountUpns
| sort by AIAgentName asc 
The CreaterAccountUpn is the user who created the Copilot Studio Agent.
Adding the user as Owner of the Enterprise Application introduces the following risk:
- High Privileged Access permissions can be (ab)used by the user
- Credential abuse; an owner can add client secret (persistence & invisible access)
- Bypass Conditional Access & MFA
- Federated Credential abuse (cross-tenant access, supply-chain, etc.)
So instead of using the Owner option, we can add the Sponsor (equal to the naming convention and roles of modern Agents) in the Notes field of the Enterprise Application for accountability and administrative purposes.
Issue #2 - Inconsistent Copilot Studio Agent names in Entra Agent ID
When a Copilot Studio Agent is created, the name stored in the Entra Agent ID | All agent identities is the initial name which is Agent #, after the rename of the Agent in Copilot Studio, there is no sync (yet) to Entra Agent ID.
The agent registry is inconsistent in numbers of Agents compared to All agent identities but has the new name (rename after initial configuration).
This results in the following Agent ID overview.
These names are used by the Entra ID Security products like ID Protection for Agents and Conditional Access which is almost impossible for enterprise organizations.
To get the correct Copilot Studio Agent name, where our source is the Agent ID object-ID.
I created a script which can be used from my GitHub which input the Power Platform Admin Environment URL and Agent ID object-ID.
Disclaimer: The App-ID is required as input for the script while the Entra Agent ID portal shows the object-ID.
So this script works out-of-the-box for modern agents because Object-ID (Entra) == App-ID (Copilot Studio) while with classic agents the object-ID <> App-ID.
For the use with classic agents use the procedure below to get the App-ID from the Object-ID
I hope this blog helps with some clarity and understand the current inconsistencies which will be solved by Microsoft, until then, this blog contains some options.
