An AI agent inventory should follow every route to action

Start an AI agent inventory with a completed business action. Pick a document it retrieved or a record it changed, then ask which account the destination system saw. If that account differs from the employee who requested the task, the inventory needs to explain how their authority is connected.

For an identity lead, the useful unit is the action path: agent, tool, connection, executing identity and target resource. An agent-level entry can hold the sponsor and purpose, but it should not hide several different sources of permission behind one name.

One agent, two different authorities

Consider a hypothetical service-desk assistant. It reads a procedure as the signed-in employee, then creates a customer record through an integration account. The employee’s document access constrains the first action. It does not automatically constrain the integration account’s ability to write records.

Microsoft Copilot Studio makes this a practical configuration question. Its tool authentication documentation distinguishes user authentication from agent-author authentication. It recommends user authentication where access must be restricted to particular users or groups, and documents channel-specific support. Inventory the configuration actually deployed for each tool and channel, rather than copying the agent’s sign-in setting into every row.

Likewise, the Microsoft identity platform distinguishes delegated access, where the application and user must both be authorised, from app-only access, where the application acts without a signed-in user. The distinction belongs in the inventory because it changes what removing a user’s access can accomplish.

Build the entry from the outside in

At the agent level, record the business sponsor, service owner, deployed version, environment and people or events allowed to invoke it. A sponsor should be able to confirm that the work remains necessary; an operational owner should be able to stop or repair it. These may be different people.

Under that entry, create a row for each tool-to-resource path. The following example continues the fictional service-desk workflow.

Action path	Authority and limit	Evidence and stop route
Retrieve a procedure from the document service	User-delegated identity; approved read scope and the user’s resource access	Correlate the request with retrieval; test withdrawal of the user’s access and connection
Create a customer record	Integration identity; permit the intended record type and validated fields	Join the initiating request to the target write; disable the tool route and restrict the integration principal
Run a scheduled follow-up	Explicit background authority; no assumption that the initiating user remains present	Identify scheduler, credential issuer and cancellation owner; test queued work after shutdown

For each real row, add the tool endpoint, connection owner, permission grant, accessible data, action limits, credential expiry or renewal mechanism, and retirement trigger. Reference the protected credential store rather than copying secrets into the inventory.

Separate what is technically possible from what policy permits. “May update only assigned accounts” is an intended limit. The record should identify the application check or resource permission that enforces it. A statement in the agent prompt is useful context, but it is not evidence that the destination rejects an out-of-scope write.

Test attribution and stopping as separate capabilities

Run an allowed action and a deliberately disallowed action in an approved test scope. Inspect the agent trace, connection or gateway record and destination audit event. Establish whether an investigator can link the requester, proposed operation, executing principal and actual result.

A shared account is not automatically unacceptable, but its destination log alone may be insufficient to identify the originating task. If the application adds a correlation identifier, check that it survives retries and cannot be casually supplied as a false identity claim. Record any gap as a limitation to resolve before expanding the permitted work.

Then test the stop route. Disabling the agent interface may leave scheduled work running. Removing a user may leave app-only permissions intact. Revoking a connection may not undo an action already accepted downstream. Identify which controls stop new requests, prevent further execution and support recovery from completed effects.

Record the observed delay and scope of stopping, including any already-issued credentials. Do not replace that evidence with a universal “instant revocation” flag.

Keep the inventory tied to deployment changes: a new tool, authentication mode, target system or broader permission should trigger an update. Begin with one agent that can write to a business system and trace all of its action paths. The result will also expose the access-governance decisions that a list of accounts alone cannot settle.