Agent identity and user delegation: whose access is granted, and where it ends

The same agent can have different document access for different users

Consider an agent that finds and summarizes internal documents. A sales representative looking for a customer's contract and an employee in another department asking the same question may be entitled to different results. This is the article's hypothetical example. Using the same agent does not justify giving both people the same document access.

Adding external delivery creates a second decision: permission to read and permission to send. The user's ability to sign in, the ability to identify the agent, and authorization to send a particular document are distinct questions. Authentication at the entrance may not preserve individual access boundaries if the downstream connection can read documents for the whole organization.

In my interpretation, agent identity matters beyond giving software a name. It can make the authority used for a request, and the point where that delegation can be revoked, objects of management. This article separates dedicated identity, user delegation, and downstream authorization, then follows them through changes in responsibilities and permissions.

Use identity as a unit for granting access, stopping work, and investigating

At Build 2025, Microsoft introduced an Entra Agent ID preview assigning unique identities to agents created in Copilot Studio or Azure AI Foundry. Its Ignite 2025 Entra announcement describes a preview through Agent 365 covering inventory, lifecycle management, and protection of resource access. These illustrate an expansion from identifying software to managing it.

The permissions attached to a registered identity still require a decision. In the document-search example, stopping search alone differs from stopping delivery by the same agent as well. Without a correspondence between identities, connections, and permitted operations, a name in a management screen may not let an operator isolate the intended work.

Conventional service accounts can also help when separated by workload, granted narrow permissions, and associated with traceable activity. A dedicated agent identity is not automatically superior. Sharing one powerful credential across several jobs can make stopping one interrupt the others, or make it difficult to identify what must stop. The useful comparison concerns the units available for grants, suspension, and investigation.

Those units should also connect to human responsibilities. Establishing who defines the purpose, configures connections, and reviews continued use helps determine whether an unused permission still has a reason to exist. This is the article's operating recommendation, not a product guarantee that registration discovers every unnecessary permission.

Separate scheduled workload permissions from authority borrowed from a user

A nightly job saving a fixed report to a specified location has a different basis for permission from a search of contracts its requester can read. One possible design gives the first dedicated workload permissions for an organizationally defined purpose and destination. The second needs to preserve access conditions corresponding to the requester. This is a design comparison, not a claim that every product implements the paths identically.

AWS's July 2025 AgentCore announcement describes Identity creating a unique workload identity and supporting access scoped to user or agent context. It discusses access to external services on behalf of users or with pre-authorized consent, along with a vault for user tokens. The announcement's architecture example does not establish equivalent enforcement across every external service.

A token is a credential presented to an access target. Delegation does not require placing long-lived external-service credentials in the model's conversation. Auth0's Token Vault explanation describes centralized management of provider tokens: the application obtains the access token it needs without directly handling that provider's refresh token. It provides a concrete example of separating credential storage and renewal from the model interpreting the assignment.

This mechanism leaves a problem if the resulting permissions are too broad. A task does not necessarily need every document its requester can read, and readable documents cannot necessarily be sent to any recipient. After establishing who requested the work, narrowing the relevant resources and operations aligns delegation with its business purpose.

Access to MCP and access to its downstream API belong to different connections

The MCP 2025-11-25 authorization specification defines an authorization flow for HTTP connections. Servers must validate that presented tokens were issued for them. A call to another API uses a separate token issued for that API; the server must not pass through the token received from its client.

For document search, examine the agent-to-MCP connection separately from the MCP-to-storage connection. Identifying the user on the first leaves a further question if the second can retrieve organization-wide documents: where are that user's access conditions enforced? The design needs to explain whether storage permissions make this decision or the search service restricts the documents it returns.

The specification requires 401 for invalid or expired tokens and 403 for insufficient permissions. Converting these failures into zero search results obscures the distinction between missing and inaccessible material. It mixes cases requiring permission changes with cases requiring another search. Separately control whether an explanation may reveal the title or content of inaccessible documents.

Authorization is optional for MCP implementations overall, and this OAuth procedure is not imposed uniformly on local standard-input/output connections. An “MCP-compatible” label establishes neither the authentication method nor permission scope. Inspect the actual transport and access conditions.

Connect four questions for each operation

Apply these distinctions to the hypothetical path from search to external delivery. The following four questions are the article's review framework; they do not require placing all the information in a single token.

These relationships help distinguish revoking a user's delegation from disabling a particular connection. Increasing permissions is only one aspect of management. Preserving necessary work while isolating unwanted resources or operations also demonstrates what can be controlled.

After disconnecting, check issued credentials and previously retrieved information

A staff member transfers departments, a user withdraws delegation, or a recurring job loses its purpose. Each change requires deciding which access should end. A search borrowing the user's authority and a report the organization intends to continue can require different treatment after the same transfer. Continuing the latter requires reviewing its purpose and next responsible operator.

Removing a connection in a management interface does not establish that every issued credential immediately becomes unusable. RFC 7009 on OAuth token revocation discusses propagation delays and differences between access-token designs. It also notes configurations in which revoking a refresh token does not immediately invalidate an access token.

The check proposed here distinguishes preventing new credential acquisition from refusing access with credentials already issued. It also measures the interval from requesting suspension to access being refused, and identifies which connections received the change. This is a condition to verify in each implementation, not a measurement of the named products' revocation delays.

Invalidating credentials does not necessarily delete previously retrieved documents or summaries. Decide how stored material is retained or removed, and prevent results saved for one user from being reused for another without the appropriate access conditions. Stopping future access and handling information already held each need their own checks.

Access decisions and content inspection serve different purposes

Generated-content inspection cannot replace this permission design. Checking a summary for problematic language and deciding whether its source may be read examine different things. Retrieval with valid permissions still leaves the accuracy of the summary and purpose of sharing to be assessed.

As a product example separating operation permission from the model's response, AgentCore Policy, generally available from March 3, describes evaluating tool access and input conditions through Gateway, outside agent code. It illustrates handling identity and permission for a particular call through distinct mechanisms. Controls attached to that Gateway cannot be presumed to cover another connection path or the treatment of previously retrieved material.

Comparing enterprise products is easier when identity issuance, operation authorization, content inspection, and record management are treated as separate functions. For our search example, compare who enforces the user's document access, who constrains recipients, and where access is refused after revocation. The useful question is whether the required decisions are placed along the actual work path.

Continue permitted work while ending delegation that is no longer needed

A trial should include two people with different document access using the same agent. Check that search results and saved summaries do not mix, and that accessible and inaccessible documents are correctly distinguished. Add an attempt to send an accessible document to an unauthorized recipient, and identify which component refuses it.

Then revoke delegation or disable the connection and separately examine new retrieval, access with issued credentials, and reuse of saved results. Also verify that users and recurring jobs outside the suspension continue their necessary work. This is the article's proposed test, not a claim that a particular product passed it. The operator should be able to explain the scope of suspension and what remains unresolved from its results.

Agent identity management has value beyond the moment access is granted. It matters when a change in purpose or responsibility still leaves people able to decide whose authority is used, what continues, and what ends. A configuration that meets those conditions can let an operator stop one delegation while preserving the other necessary work.