Copilot agents expand the NHI governance gap in Microsoft environments

At a glance

What this is: This guide explains how Microsoft Copilot and Copilot Studio agents show up across Entra ID, Dataverse, Graph, Teams, and audit logs, with the key finding that agent discovery depends on stitching together multiple consoles and APIs.

Why it matters: IAM and NHI teams need a single governance model for Copilot agents because fragmented visibility increases the chance that exposed connectors, overprivileged connections, or unaudited agent actions go unnoticed.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Token Security's guide to discovering and governing Copilot agents

Context

Copilot agent governance is an NHI problem because each agent behaves like a non-human identity with its own permissions, connectors, and audit trail. In Microsoft environments, those identities can appear across Entra ID, Dataverse, Teams, and audit logs, which means the security team has to assemble a complete picture from separate consoles before it can make an access decision. That fragmentation is the real risk, not the chatbot interface itself.

The article’s main point is operational rather than theoretical: discovery is possible, but only if teams understand where Microsoft stores agent metadata and how authentication is modeled across the stack. That makes Copilot governance a cross-domain IAM task involving identity inventory, connector review, and runtime monitoring. For most enterprises, this starting position is typical, not unusual, because platform sprawl is already the default.

The practical takeaway is that Copilot agents should be treated as governed workloads, not as simple user-facing features. Once an agent can call connectors, inherit OAuth context, or expose activity in audit logs, it belongs in the same control set as other NHIs. Teams that still track only human identities will miss the access paths that matter most.

Key questions

Q: How should security teams inventory Copilot agents in Microsoft environments?

A: Start by correlating Dataverse agent records with Entra app registrations, then confirm which agents are also exposed in Teams or Microsoft 365 audit logs. The goal is one inventory that ties each agent to an owner, permission set, and connector list. Without that correlation, teams will miss renamed agents and orphaned access paths.

Q: Why do Copilot agents create NHI governance risk?

A: Copilot agents create NHI risk because they authenticate, connect to tools, and act on behalf of a workload rather than a person. That makes them subject to the same problems as other NHIs, including privilege creep, weak ownership, and poor offboarding. If they are not governed as identities, they become unmanaged access paths.

Q: What is the difference between a Copilot agent and a normal SaaS integration?

A: A Copilot agent is an autonomous identity that can initiate actions, chain tools, and persist across multiple Microsoft services, while a normal SaaS integration is usually a narrower, predefined connection. The governance difference is scope: Copilot agents require identity lifecycle controls, connector review, and audit monitoring, not just API enablement.

Q: When does Copilot automation become a privileged access problem?

A: Copilot automation becomes a privileged access problem when the agent inherits the owner’s credentials, uses broad OAuth scopes, or reaches sensitive systems through connectors. At that point, the agent is not just automating work, it is carrying elevated authority. Teams should apply the same caution they use for PAM and high-risk service accounts.

Technical breakdown

How Copilot agents map to Entra app registrations and Dataverse records

Copilot Studio creates an Entra ID app registration for each agent, which gives identity teams a durable object to inventory even when the agent name changes. The Dataverse Web API then exposes the agent record, and the synchronizationstatus field links back to the applicationId. That link matters because it joins the operational agent in Dataverse to the identity object in Entra. In practice, this is the minimum viable control plane for discovery: if the team cannot tie the agent record to the app registration, it cannot assess ownership, privilege, or lifecycle state.

Practical implication: Inventory agents by correlating Dataverse bot records with Entra app registrations before reviewing privileges or connectors.

Why connectors and owner credentials create hidden privilege paths

Copilot agents can use pre-built connectors, custom connectors, Power Automate flows, and knowledge bases, which means the agent’s access is rarely limited to a single service boundary. The risk rises when OAuth connections use the owner’s credentials, because users effectively inherit the creator’s access context. That is a classic NHI problem: the identity that authenticates the agent is not always the identity that should authorize every action. Overprivileged third-party permissions make the issue worse because a single connector can widen the blast radius far beyond the intended task.

Practical implication: Review every connector for privilege inheritance and replace owner-credential patterns with task-scoped authorization wherever possible.

How audit logs reveal agent activity and connection events

Microsoft’s audit trail can show CopilotInteraction events, which record prompts and accessed resources, and PutConnection events, which record when an agent is linked to a third-party identity. These logs are valuable because they separate agent usage from ordinary user activity and let analysts reconstruct what the agent touched and when. The limitation is that logging does not equal governance. If the team never defines alert thresholds, ownership, and review workflows, the log data becomes retrospective evidence rather than a control.

Practical implication: Route CopilotInteraction and PutConnection events into monitoring workflows that flag new connectors, high-risk resources, and unusual access patterns.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Copilot agents should be governed as NHIs, not as UI features. Once a Microsoft agent can authenticate, call tools, and retain an app registration, it has the same lifecycle obligations as any other non-human identity. The governance failure is usually not the agent itself, but the assumption that a user-facing assistant does not need inventory, ownership, rotation, or offboarding. Practitioners should place Copilot agents under the same control framework used for service accounts and API-driven workloads.

Identity fragmentation is the real Copilot risk. The article shows that agent data is distributed across Entra, Dataverse, Teams, Graph, and audit logs. That distribution creates a discovery problem before it becomes a security problem, because no single console gives the full answer. The market should interpret this as validation that NHI governance must operate across platforms, not inside one admin plane.

Credential inheritance turns convenience into privilege amplification. When an agent connects through the owner’s credentials, the security boundary shifts from task-based authorization to human-based trust. That pattern is risky because the agent can act with a broader permission set than the requester intended, and those actions may be hard to distinguish in retrospect. Security teams should treat inherited OAuth context as a privileged access pattern, not a harmless default.

Connector review is now part of access review. Copilot agents make third-party access a first-class governance issue because the agent’s utility depends on external APIs, flows, and knowledge sources. That means an identity review that stops at the app registration is incomplete. Practitioners should extend access review to include what each agent can reach, not just whether the agent exists.

Agent observability needs to become a policy control. Audit logs can show what happened, but they only become governance when teams define what should be monitored, escalated, and revoked. The field is moving toward runtime accountability for agents, where discovery, authorization, and event review must be treated as one lifecycle. Practitioners should build that lifecycle before Copilot sprawl normalizes unmanaged access.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how slowly remediation can lag once access is exposed.
• For a broader control model, see OWASP NHI Top 10, which helps teams prioritise agent identity, tool access, and runtime abuse risks.

What this signals

Copilot governance will fail where identity tooling still assumes human users. The operational lesson is that discovery must precede policy, because policy cannot protect what the team cannot enumerate. In Microsoft-heavy estates, the next control gap will be agent sprawl, not another dashboard.

Ephemeral access is not the same as controlled access. The presence of logs and app registrations can create a false sense of coverage if teams do not review connector scope, ownership, and offboarding. That is why the governance model has to include access review for agents, not only for human accounts.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, the Copilot problem is not isolated. It is another example of how autonomous access expands faster than review processes, and that should push teams toward tighter lifecycle controls and explicit connector approvals.

For practitioners

• Correlate every Copilot agent to an identity object Map Dataverse bot records to Entra app registrations so each agent has a known owner, lifecycle state, and review path. Treat orphaned or renamed agents as unresolved risk until the identity mapping is complete.
• Review connector privilege inheritance Inspect whether OAuth connections use owner credentials, shared service identities, or task-scoped authorization. Where possible, replace inherited privileges with dedicated low-privilege access and document every third-party connector in the access review process.
• Monitor CopilotInteraction and PutConnection events Send both audit actions into detection workflows that alert on new connectors, unexpected accessed resources, and unusual connection creation from administrative accounts. Use the logs to confirm who connected the agent and what resource the agent touched.
• Classify Copilot agents as governed NHIs Add Copilot agents to the same inventory, approval, and offboarding process used for service accounts, API keys, and automation identities. Require explicit ownership and periodic recertification for each agent that can reach external services.

Key takeaways

• Copilot agents are NHIs with their own identity, permissions, and lifecycle risk, so they need the same governance model as service accounts and API keys.
• Fragmented visibility across Entra, Dataverse, Teams, Graph, and audit logs makes discovery the first control gap teams must close.
• Connector scope, inherited credentials, and audit review are the practical levers that determine whether Copilot automation stays bounded or becomes privileged access sprawl.

Key terms

• Copilot Agent: A Copilot agent is an autonomous software identity that can interact with tools, connectors, and knowledge sources on behalf of a user or workflow. In governance terms, it behaves like a non-human identity with its own permissions, lifecycle, and audit requirements.
• Dataverse Web API: Dataverse Web API is the interface used to query Copilot Studio and Power Platform data, including agent records and related components. For security teams, it is a discovery source that can reveal what an agent is, who owns it, and what it is connected to.
• Connector: A connector is the integration path an agent uses to reach an external service, such as GitHub, Salesforce, or a custom API. Connectors matter because they expand the agent’s effective access scope and often determine the highest-risk permissions in the environment.
• Inherited Credentials: Inherited credentials are OAuth or service credentials that let an agent act with the privileges of the user or creator who configured it. This pattern increases blast radius because the agent may acquire access that exceeds its intended task scope.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step Dataverse and Graph API queries for enumerating Copilot Studio agents across Microsoft services
• Exact OData expand examples that expose topics, actions, tools, and parent bot components
• Audit log field examples for CopilotInteraction and PutConnection events
• Practical checks for identifying unauthenticated agents, owner-credential connections, and overprivileged third-party permissions

👉 Token Security's full post covers the API queries, log fields, and misconfiguration checks in detail

Deepen your knowledge

Copilot agent discovery and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring agent identities under the same control model as service accounts, it is worth exploring.