For Windows and Microsoft 365 administrators, the practical change is less about another AI security dashboard than it is about inventory. Microsoft Entra tenants already contain a crowded mix of users, service principals, managed identities, enterprise applications, workload identities, and now agent identities. An AI agent that cannot be located cannot be assigned an owner, reviewed for permissions, constrained with Conditional Access, or disabled when its project ends.
Petri’s August 19 report is currently the detailed public account of the release. Netwrix’s public PingCastle 4.0 documentation confirms that the product is positioned to assess both Active Directory and Entra ID, while Microsoft’s own Entra documentation now treats agent identities as a distinct identity type built around service-principal infrastructure. The important limitation: neither the Petri report nor the publicly available PingCastle 4.0 guide lists the 102 new Entra checks individually. Administrators therefore should not treat “102 checks” as proof that every existing Entra application, service principal, or third-party AI integration is automatically identified.
AI agent discovery is becoming an Entra administration problem
Microsoft’s Entra Agent ID documentation makes clear why this category is now operationally different from a conventional application registration. Agent identities can be assigned direct access to Microsoft Graph, Azure RBAC roles, Entra directory roles, and app roles; they can also act with delegated access on behalf of a user. Microsoft describes them as identities created for AI agents, with their own sponsors and audit records.
That model is a security improvement over an agent silently operating through a shared user account or a generic service principal. It also creates a new inventory challenge. Agents may be created through low-code tools such as Copilot Studio, be spun up through automation, or be short-lived components of a larger workflow. The question for security teams is no longer merely whether an approved AI platform exists in the tenant. It is whether every agent instance, its sponsor, its credential path, and its effective permissions are visible.
Netwrix’s claimed addition of agent discovery to PingCastle matters because it aims to answer the preceding question before an access review begins. The company’s earlier research found that only 19% of surveyed organizations fully govern non-human identities. That is vendor-sponsored survey data, not a measurement of every enterprise, but Microsoft’s own product direction corroborates the underlying shift: Entra now has dedicated concepts for agent identities, blueprints, sponsors, lifecycle controls, and policy enforcement.
The release should also temper a common assumption: an Entra tenant’s Enterprise Applications blade is not necessarily a complete AI-agent register. Microsoft distinguishes purpose-built agent identities from ordinary application service principals, while agent integrations can still authenticate using service principals, agent identities, or agent-associated user accounts depending on the application’s capabilities. A useful discovery product has to handle more than one object class and connect it to permissions actually granted in the tenant.
The 102-check figure needs operational validation
PingCastle has long been used to turn Active Directory configuration findings into a risk score and prioritized remediation work. Adding 102 Entra ID assessments would substantially expand that model into a hybrid identity environment, where on-premises AD weaknesses can coexist with cloud-side privilege, consent, application, and configuration problems.
But a raw check count is not a remediation plan. It does not reveal how many checks apply to a tenant, which require privileged collection, how Netwrix weights their severity, whether false positives are expected, or whether the checks cover Microsoft’s newer agent-identity objects directly rather than only conventional Entra applications and service principals.
That distinction deserves attention because the product documentation also reveals a versioning wrinkle. Netwrix’s developer documentation has a PingCastle 4.0 section, but the public PingCastle GitHub repository recently identified its available version as 3.5.0.33. That does not establish that PingCastle 4.0 is unavailable; it does mean administrators should confirm which edition and build they are running before expecting the new Entra and agent-visibility capabilities.
This is especially relevant in organizations that adopted PingCastle as an open-source or community assessment utility before Netwrix acquired the project. The newest features may be tied to a commercial release, a different distribution channel, or a product tier with different reporting and collection requirements. Netwrix has not publicly enumerated those boundaries in the material accompanying this announcement.
Before treating a PingCastle report as authoritative, teams should validate several basics:
- Confirm that the deployed PingCastle edition and build actually includes the Entra ID and agent-discovery capabilities described by Petri.
- Establish which account and Microsoft Graph permissions the assessment uses, because limited collection can produce a cleaner-looking report by omitting objects it cannot inspect.
- Compare discovered agents against Copilot Studio, Azure, Microsoft 365, approved SaaS applications, and internal automation inventories.
- Assign every discovered non-human identity to a business owner and record its intended purpose, expiry or review date, and emergency disablement path.
- Review direct application permissions, Azure RBAC assignments, Entra roles, app-role assignments, consent grants, group memberships, and delegated access separately.
The last point is the one that tends to disappear under the word visibility. Finding an identity is useful, but the risk resides in what it can do. A named agent with broad Files.ReadWrite.All permissions, a privileged Azure role, or standing delegated access to a sensitive SharePoint site has a materially different exposure from an agent limited to a single approved API and a narrow app role.
Threat Manager extends the monitoring boundary to Azure Files
The other half of Netwrix’s update is support for Azure Files in Threat Manager. Petri says the feature can detect ransomware activity, unusual behavior, and configurations such as overly permissive file-sharing settings.
Azure Files is not a traditional Windows file server, even if clients access it through SMB and it may occupy the same business role. Monitoring it requires Azure-side telemetry and proper diagnostic configuration. Netwrix’s own Azure Files documentation notes that activity logs can take between three and 20 minutes to become available for analysis, a platform delay that matters in a ransomware investigation. This is detection and response support, not a guarantee of instantaneous prevention.
The product’s configuration requirements also matter. Netwrix documentation says Azure Files monitoring relies on an Azure application registration, suitable access to the relevant subscription or storage account, and Azure diagnostic settings that send audit data to a log storage account. If the necessary logs are not enabled before an incident, no new Threat Manager integration can reconstruct missing evidence after the fact.
That makes the most practical value of the Azure Files addition configuration monitoring. Ransomware alerts are important, but an alert on anomalous file changes arrives after an actor or malicious process has begun changing data. An alert about a permissive file-sharing configuration, excessive access, or a dangerous change to a storage setting gives a team a chance to reduce the attack surface before encryption starts.
Microsoft administrators should also check how the new monitoring overlaps with their existing tools. Microsoft Defender for Storage, Microsoft Sentinel, Azure Monitor, Defender XDR, and third-party SIEM platforms may already collect pieces of the same Azure Files activity. The priority is not to create duplicate alerts; it is to ensure that detection ownership, log retention, escalation paths, and response authority are clear.
Native Entra controls remain the control plane
Netwrix is explicitly positioning the release as complementary to Microsoft’s native security tools, and that is the correct framing. An assessment platform can identify weak configurations and supply an independent risk model. It cannot replace the Entra settings that enforce access decisions.
Microsoft supports Conditional Access for workload identities in defined circumstances, access reviews for applications and service-principal role assignments, and custom security attributes to help establish a filterable service-principal inventory. For agent identities, Entra’s newer tooling adds sponsors, blueprints, agent-specific audit activity, lifecycle governance, and policies designed for agents at scale.
Those native controls establish the intended state. Netwrix’s contribution is to provide a cross-environment assessment layer that can flag where reality diverges from the intended state, particularly for organizations managing both Active Directory and Entra ID.
A sensible first deployment would use PingCastle 4.0 findings to build a remediation queue rather than immediately changing permissions across production. Start with identities that lack accountable owners, hold privileged directory or Azure roles, have broad application permissions, use long-lived secrets, or access sensitive data stores. Then test the least-privilege change with the application owner before removing access that may support a business workflow.
Netwrix’s update reflects a real transition in Microsoft identity administration: AI agents are becoming governed principals in Entra, not merely features inside an application. The immediate task for IT teams is to verify which agents already exist, who owns them, and whether their access can survive a serious review.
Update: Additional details (August 19, 2026)
RCP Channel Briefing identifies the monitoring release as Netwrix Threat Manager 3.3 and says PingCastle 4.0 and Threat Manager 3.3 are available now.
It also reports that Threat Manager can inventory agent identities and their access, but agent-specific threat detection is planned for a later release.
