Copilot agents expand the NHI governance gap in Microsoft environments

At a glance

What this is: This guide explains how Copilot agents appear across Microsoft 365, Copilot Studio, Entra ID, Dataverse, Graph, and audit logs, and why that fragmentation creates NHI visibility gaps.

Why it matters: IAM and security teams need a reliable way to inventory agent identities, connected tools, and delegated access because governance breaks down when those elements live in different Microsoft control planes.

Context

Copilot agents in Microsoft environments are non-human identities with their own registrations, connections, and audit footprint. The governance problem is not that they are invisible everywhere, but that no single Microsoft control plane presents the full identity picture cleanly.

Token Security’s analysis shows that Copilot Studio and Microsoft 365 Copilot split discovery across Entra ID, Dataverse, Graph, Teams, and the O365 Management API. For identity teams, that means inventory, review, and offboarding are still harder than the platform branding suggests.

The core issue is visibility and control over NHI behaviour inside an ecosystem designed around multiple dashboards and permissions models. Once an agent can connect to third-party services and inherit credentials, governance depends on stitching together evidence that was never built to live in one place.

Key questions

Q: What breaks when Copilot agents are managed across separate Microsoft consoles?

A: The control breaks when inventory, ownership, and access evidence live in different places. Teams can see an agent in one console, its configuration in another, and its activity in logs elsewhere, which makes recertification and offboarding unreliable unless those records are joined into one governance view.

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: How do security teams know whether an agent has too much privilege?

A: The clearest signal is whether the agent can reach systems, data, or tools that are not necessary for the task and still complete its objective. If the same identity can query, decide, and execute across multiple domains without constraint, the privilege boundary is too broad. Effective review should focus on reachable actions and chained outcomes, not only assigned roles.

Q: Should organisations treat Copilot agents like service accounts or like app features?

A: They should treat them as governed non-human identities with application characteristics. That means inventory, ownership, access review, and retirement processes must apply, even though the agent sits inside a productivity platform rather than a traditional infrastructure stack.

Technical breakdown

Why Copilot agents become separate non-human identities

Copilot Studio agents are not just prompts wrapped in a chat interface. In Microsoft’s model, each agent gets an Entra app registration, while its configuration and components live in Dataverse and its activity can surface in Microsoft Graph and audit logs. That means the agent has an identity lifecycle, connection objects, and runtime evidence spread across different services. Security teams therefore have to treat the agent as an NHI with its own inventory record, not as a feature toggle inside M365. The technical challenge is less about seeing an agent exist and more about connecting the identity, its tools, and its effective access scope into one governance view.

Practical implication: build an agent inventory that joins Entra app registrations, Dataverse bot records, and audit events into one governance dataset.

How tool connections and permissions change the risk picture

Copilot Studio agents can use pre-built connectors, custom connectors, Power Automate flows, and knowledge bases. Each connector is a data path and sometimes a privilege path, because the agent’s effective access depends on the identity behind the connection. The article highlights a common failure mode: using the owner’s credentials, which makes users act as the creator and can inherit that person’s elevated rights. That is classic privilege transference, but in an NHI wrapper. In practice, the control question is not just what the agent can do, but whose permissions it is borrowing to do it.

Practical implication: separate the agent’s own identity from the human owner’s credentials and review every connection for inherited privilege.

Why Microsoft audit logs are necessary but not sufficient

The O365 Management API can show CopilotInteraction and PutConnection events, which is useful because it gives investigators a way to correlate prompts, tool usage, and third-party connection setup. But logs do not replace governance. They show that an action happened, not whether the agent was discovered in time, owned correctly, approved appropriately, or offboarded when its purpose changed. This is where many NHI programmes fall short: they assume logging equals control. In reality, audit evidence is only one layer in an identity lifecycle that also needs ownership, entitlement review, and revocation discipline.

Practical implication: use audit logs for detection and forensics, but anchor governance in ownership, review, and revocation workflows.

NHI Mgmt Group analysis

Copilot agents create an NHI governance gap because Microsoft distributes the evidence of their existence across multiple control planes. The agent identity lives in Entra, the configuration in Dataverse, activity in audit logs, and some deployment traces in Teams and Graph. That fragmentation is not a cosmetic inconvenience. It means governance teams cannot rely on a single inventory or review process to answer the basic question of what the agent is connected to and who is responsible for it.

Owner-credential delegation is the clearest control failure in this model. When an agent operates through the creator’s credentials, access becomes a borrowed privilege rather than a governed identity. That collapses accountability because the same permission set can outlive the original intent of the agent and expand to every user interacting with it. The implication is that Copilot governance must distinguish agent identity from human sponsorship.

Copilot visibility gaps are really lifecycle gaps in disguise. Discovery alone does not solve ownership, recertification, or offboarding when the platform exposes agents through different consoles and APIs. The named concept here is distributed agent inventory debt: the accumulated governance burden created when one non-human identity can only be understood by stitching together several partial records. Practitioners should treat that debt as a programme issue, not a tooling inconvenience.

Microsoft environments are now a practical test case for cross-plane NHI governance. Identity teams that only manage Entra records will miss Dataverse configuration and tool-level access, while Power Platform teams will miss the broader identity and audit context. The governance model must therefore cover the full agent lifecycle, from creation to connection to retirement, or the organisation will keep re-discovering the same blind spot in a new console.

Agentic features in familiar productivity platforms are changing the shape of identity risk without changing the governance obligations. The difference is not that Copilot agents are exotic; it is that they blur the line between application, workload, and identity. That makes them a strong fit for OWASP-NHI thinking and for lifecycle controls that were originally built for service accounts and APIs. Practitioners should stop treating them as UI features and start treating them as governed identities.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

Distributed agent inventory debt: Copilot-style agents create governance drift when identity, configuration, and activity are split across Entra, Dataverse, Teams, and audit logs. Security teams will need joined inventory workflows before they can trust recertification or offboarding outcomes.

The practical shift is from console-by-console review to identity-centric governance. That matters because NHI programmes built for service accounts and API keys already know how quickly unmanaged access grows when ownership and lifecycle evidence are fragmented.

For practitioners

• Build a cross-plane Copilot inventory Join Entra app registrations, Dataverse bot records, Teams app traces, and audit logs into one agent register so you can answer who created the agent, what it connects to, and where it is deployed.
• Remove owner-credential delegation Require agent-specific or service-specific authentication where possible, and flag any configuration that makes all users act under the creator’s permissions.
• Review every connector for inherited privilege Map each pre-built connector, custom connector, Power Automate flow, and knowledge base to the data and actions it can reach, then classify whether the connected identity is overprivileged.
• Use audit logs for correlation, not assurance Correlate CopilotInteraction and PutConnection events with admin ownership data so investigations can reconstruct who connected the agent and what it touched.
• Add agent offboarding to lifecycle governance Define a retirement process for Copilot agents that removes the Entra app registration, disconnects external services, and confirms the agent no longer appears in deployment consoles.

Key takeaways

• Copilot agents are non-human identities whose governance breaks down when identity, configuration, and audit evidence are spread across multiple Microsoft services.
• Agent-created access paths become harder to review when the platform lets connections inherit creator credentials and connect to external tools.
• Security teams should centralise inventory, remove credential borrowing, and tie offboarding to the full agent lifecycle rather than to any single console.

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.
• Distributed Agent Inventory Debt: Distributed agent inventory debt is the governance burden created when one non-human identity must be understood by stitching together records from multiple consoles, APIs, and logs. It is dangerous because review, offboarding, and accountability become slower and less reliable as the evidence remains fragmented.
• Owner-Credential Delegation: Owner-credential delegation occurs when an agent performs actions through the permissions of the person who created or connected it. This creates borrowed privilege, blurs accountability, and can make every user of the agent inherit the creator’s access path rather than a constrained agent identity.
• Agent Connection Lineage: Agent connection lineage is the chain of evidence showing which identity established a connector, what service it linked to, and what permissions were in play. It matters because effective governance depends on knowing how the agent reached a system, not just whether it exists in inventory.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.