MaruOpsInfrastructure and AI notes

About (Korean)Contact (Korean)

Microsoft Expands Local AI Agent Discovery: Inventory Is Only the Start

A technician using a laptop beside a server rack at NERSC

Reference photo · A technician using a laptop beside a server rack at NERSC · Photo: Derrick Coetzee from Berkeley, CA, USA / Source / CC0 · Resized for listings; illustrative photo, not the tested environment

Microsoft announced discovery support for 60 types of local AI agents alongside expanded agent identity and dynamic permission capabilities. The direction is to govern locally introduced tools as well as centrally deployed agents. Microsoft Security official announcement

An inventory entry is insufficient if its data and tool access remain unknown. Connect each agent to a runtime account, purpose, and owner before deciding which standing privileges can be removed.

On this page

An agent inventory needs more than a product name

Employee-installed AI tools can run as editor extensions, command-line applications, or background services. Detecting software does not reveal its behavior. Connect the inventory to accessible files, external tools, and execution identities so that it becomes an operational control record. The same product used for a personal experiment and for production automation can require very different permissions.

Record the owner, business purpose, execution location, connected tools, data classification, and log destination. An agent without an accountable owner is difficult to contain because nobody can readily judge the effect of stopping it. These details help distinguish acceptable use from workflows needing a more detailed review, rather than treating installation counts as the endpoint of governance.

Reading, changing, and exporting data are different permissions

Explaining a repository and modifying code for deployment have different consequences. An agent running on behalf of an employee does not necessarily need every permission that employee holds. Consider task-specific identities or restricted tool access, and distinguish file reading, writes, external transmission, and administrative work when deciding which actions require approval.

Also account for instructions embedded in material the agent reads. An external page suggesting that internal files be transmitted should not create permission to transmit them. Enforce authorization outside the model-generated text, at the tool or service boundary. Sensitive actions may need an approval step even when the agent has produced a plausible explanation for performing them.

Test what stopping the agent actually stops

A hypothetical coding-assistant trial can begin with repository read access before considering write capabilities. Check whether denied tool calls leave understandable logs and whether unauthorized external destinations remain unreachable. Record discovery and enforcement separately: seeing an agent in an inventory is not evidence that every execution control has been applied to it.

During shutdown testing, look for scheduled work, child processes, and external sessions remaining after the interface closes. Revoke the identity’s permissions and examine what an existing session can still do. A central management product does not remove the need to understand that lifecycle. Confirm which controls are supported in the actual product and tenant configuration.

Add these fields to an agent inventory

  • Record the owner, execution identity, tools, and external destinations.
  • Separate the read and write permissions needed for each workflow.
  • Check for surviving sessions or scheduled work after revocation.

Verify availability against your products, licenses, and deployment state. Do not treat every capability in the announcement as already active in every tenant.

Announcement reference date: 2026-10-19 · Checked: October 24, 2026