As AI agents become part of enterprise operations, an important question emerges: How do organizations discover agents, govern their access, and respond when they behave unexpectedly?
These agents may be developed through Microsoft Copilot Studio, hosted on third-party platforms, or installed directly on employee workstations.
Microsoft's October 29 announcement on the general availability of local AI agent discovery through Defender for Endpoint marks another important step toward enterprise-wide AI visibility.
1. Discover: Where are our AI agents?
Microsoft provides different discovery mechanisms depending on where an agent operates.
- Microsoft 365 agents: The Microsoft 365 Agent Registry provides visibility into supported Microsoft, partner, organizational, and user-shared agents.
- Third-party cloud agents: Microsoft Agent 365 supports connected-platform synchronization from Amazon Bedrock, Google Vertex AI, Salesforce Agentforce, Databricks Genie, Anthropic Claude Managed Agents, Oracle Generative AI Agents, and Snowflake Cortex.
- Local AI agents: Microsoft Defender for Endpoint discovers supported agents such as Claude Code and Cursor on managed Windows and macOS devices, including their configured Model Context Protocol (MCP) servers.
For local agents, administrators can navigate to Microsoft Defender portal → Assets → AI agents → Local agents.
Discovery begins after Defender observes supported agent activity on an onboarded device. An installed but inactive agent may not appear immediately.
Microsoft's October 29 announcement describes coverage for more than 50 supported agents and MCP servers. However, no discovery mechanism guarantees visibility into every custom or unsupported agent.
2. Govern: Where does Agent 365 fit?
Microsoft Agent 365 provides a centralized governance approach, while the Microsoft 365 Agent Registry offers inventory, ownership, and administrative visibility.
Microsoft Defender contributes security discovery and investigation. Microsoft Entra and Purview provide complementary identity, access, and data security capabilities.
For connected third-party platforms, an important distinction applies:
Connections are read-only by design. Agent 365 does not invoke, execute, or modify agents in the source platform through these connections.
The exception is an administrator's explicit action to remove a synchronized agent, which requires a separate, optional deletion permission.
Organizations can withhold that permission unless there is a clear operational requirement.
Ownership matters beyond initial onboarding
Connected-platform governance also introduces operational responsibilities:
- Synchronization: Registry synchronization is manual. Changes or deletions in the source platform may not automatically appear in the registry, making periodic reconciliation important.
- Credentials: Supported connections require key-based credentials. Credential rotation, secure storage, and expiry monitoring need clear ownership.
- Administrative responsibilities: The Agent 365 AI administrator manages connection setup, validation, and synchronized-agent verification, while the source-platform administrator provisions credentials and grants permissions.
The Microsoft 365 Agent Registry also highlights agents without owners, including situations where a shared agent's creator has left the organization. This reinforces an important governance principle: agent ownership must be reviewed throughout its lifecycle, not just assigned during deployment.
These are practical examples of why AI agent governance requires shared accountability between platform, identity, and security teams.
3. Contain: When an agent behaves unexpectedly
Consider an employee running an AI coding assistant on a managed corporate laptop, configured with an MCP connection to an internal development service.
Defender discovers the supported agent, its associated device and account, and the configured MCP server.
Security teams can investigate its configuration, including whether the agent automatically approves its own actions, and assess the associated identities and potential exposure.
Depending on the deployment, typical incident-response steps may include:
- Microsoft 365 agents: Use supported administrative controls to block or remove the agent.
- Local endpoint agents: Restrict the application, investigate the endpoint, or isolate the device when warranted.
- Third-party cloud agents: Use source-platform controls to disable the agent or revoke affected credentials and integrations. Where supported and explicitly authorized, Agent 365 may provide a synchronized-agent removal action.
These are general incident-response approaches, not a single automated containment capability delivered by Defender discovery.
Discovering an agent does not automatically provide a universal kill switch.
4. Licensing, availability and limitations
Microsoft's October 29 announcement describes local AI agent discovery on Windows and macOS as generally available.
An earlier Microsoft Learn implementation page still labels macOS discovery as preview. Because these sources differ, organizations should confirm current platform-specific availability before deployment.
Other considerations include:
- Licensing: Defender for Endpoint Plan 2 supports discovery and advanced hunting. Agent risk levels, risk indicators, and security recommendations require Microsoft 365 E7, or Microsoft Agent 365 together with Defender for Endpoint Plan 2.
- Cloud availability: Local agent discovery requires Microsoft's commercial cloud; sovereign and national clouds are not supported.
- Runtime protection: Windows runtime prompt-injection protection remains in preview and is separate from discovery.
- Observability: Connected-platform observability data collection is a separate capability associated with the Frontier preview program; agent synchronization should not be confused with full runtime monitoring.
My perspective
Enterprise AI governance must extend beyond centrally managed agents.
Digital Workplace, EUC, identity, and security teams increasingly need visibility into local AI tools, third-party agents, their permissions, and the enterprise systems they can access.
But visibility alone is not enough. Organizations also need clear responsibility for agent ownership, registry synchronization, credential lifecycle, access reviews, and incident response.
Three questions should guide the operating model:
Can we discover the agent? Who governs it? How can we contain it?
This complements my earlier article, Who Owns an AI Agent After It Goes Live?, which explored ownership and operational accountability.
The next step is translating those principles into practical security operations.
No comments:
Post a Comment