Per-request identity and the future of tool integrations for distributed assistants

Distributed assistants are rapidly becoming integration systems, not merely conversational interfaces. A single request may route through a specialist agent, call a knowledge service, inspect operational data, create a ticket, and hand context to another agent. In that model, the identity attached to a long-lived chat session is not enough to answer the questions that matter: who is authorizing this particular action, what resource is in scope, which agent is acting, and what evidence will exist after the action completes?

Per-request identity is emerging as the practical answer. It treats identity and authorization context as inputs to each tool invocation rather than as ambient properties of a connection. For platform engineers and teams operating MCP-connected agents, this change has architectural consequences: tools need explicit policy boundaries, orchestration layers need to preserve provenance during handoffs, and audit systems need to record both human and machine actors. The Model Context Protocol (MCP) authorization direction, alongside enterprise identity developments, points toward distributed assistants that behave more like governed enterprise software than loosely connected chat integrations.

Why session-level authorization breaks down in distributed workflows

Session authorization is convenient because it reduces friction. A user connects an application once, approves access, and expects the application to keep working. That approach can be adequate for a single product with a narrow integration surface, but distributed assistants have a much different execution model.

An orchestrator may select different specialist agents depending on a request. Those agents may call different MCP servers, use different tools on the same server, operate concurrently, or initiate work that outlasts the interaction that started it. The relevant authorization decision is therefore often not “may this user use this server?” but “may this actor invoke this tool, with these arguments, against this target, for this business purpose, at this moment?”

Ambient authority creates avoidable ambiguity

When a broad credential is attached to a session or server connection, downstream tools can inherit more authority than the current step needs. That makes it harder to apply least privilege, harder to distinguish a read from a write, and harder to explain why an action was permitted. It can also obscure whether a tool call was made directly by a user, delegated through an agent, or initiated after an orchestration handoff.

The problem becomes more acute when sensitive and low-risk capabilities live together. An assistant might need a public documentation search tool and a protected tool that changes a customer record. Treating the entire server as either authenticated or unauthenticated forces an unnecessarily coarse choice.

In a distributed assistant, the durable unit of governance is not the chat session. It is the attributable, policy-checked tool action.

MCP’s current authorization direction addresses this distinction directly. Its documentation describes both per-server authorization and per-tool authorization. Under the per-tool pattern, public tools can operate without a token, while OAuth is initiated only when a protected tool is called. The server verifies the token, extracts the user identity, and creates a per-request server instance with that authorization context.

This is more than a login-flow refinement. It makes authorization contextual to execution. A public capability stays simple, while a protected capability can demand the identity, claims, scopes, and policy checks appropriate to the operation.

What per-request identity means in MCP-connected systems

Per-request identity does not mean that every call must present a completely new human login. It means each protected invocation has an explicit, verifiable identity context that the server can use to make a decision. The context can include the authenticated user, a workload or agent identity, granted scopes, organizational policy, and request-specific information relevant to enforcement and auditing.

MCP Apps documentation frames this as a first-class deployment pattern. A server can expose public tools without authentication and protect other tools with OAuth only when they are invoked. Once the protected path is activated, the server validates the token, identifies the user, and handles the request in an instance created with that authentication context.

Separate authentication, authorization, and attribution

These concepts are often collapsed in agent designs, but they answer different questions. Authentication establishes whether an identity is genuine. Authorization determines whether that identity may perform a requested operation. Attribution records which identities and software components actually participated in execution.

• Human identity

  answers who requested, approved, or owns the business action.

• Agent or workload identity

  identifies the software principal executing a delegated step.

• Tool and server identity

  identifies the integration endpoint and capability that received the request.

• Request context

  captures the operation, arguments, target resource, correlation identifiers, and policy outcome.

A reliable system retains all of these where applicable. Recording only the human user loses the distinction between an approved request and an automated follow-on action. Recording only the agent loses the accountable business principal. Recording only a server session loses the fine-grained evidence required to investigate a particular tool invocation.

Tool scopes are useful, but not always sufficient

Fine-grained scopes are a major improvement over all-or-nothing server access. MCP working group discussions have addressed tool-scoped OAuth challenges, while also recognizing an important limitation: scopes do not always map one-to-one to tool calls when arguments matter.

For example, a tool named update_record could be permitted for one business unit but not another, or it could allow a status change but not an ownership transfer. The tool name alone cannot express the whole policy. Mature authorization therefore combines coarse grants, such as scopes, with server-side evaluation of the request arguments, resource attributes, organizational rules, and potentially the delegation chain.

That design keeps a useful boundary in place: clients request access, but servers remain responsible for enforcing the final decision close to the protected resource.

Enterprise-managed authorization changes the operating model

Repeated OAuth consent is a poor fit for enterprise agent deployments. It creates friction for users, makes onboarding inconsistent, and can lead to account-selection mistakes. MCP’s Enterprise-Managed Authorization became stable in June 2026, according to MCP’s blog, enabling organizations to centrally provision MCP server access through their identity provider. Users can receive connected servers on first login without completing per-application OAuth flows.

Central provisioning changes who controls integration access. Instead of each agent application independently prompting users and maintaining its own connection assumptions, the enterprise identity provider can apply organizational policy. That is especially important where access should reflect employment status, group membership, device posture, application assignment, or an approved integration catalog.

Preventing the work-and-personal-account collision

MCP has identified a concrete risk: work and personal accounts can blur together in existing flows, and some flows do not provide a way to require a corporate identity. In an enterprise environment, this is not just a usability issue. A personal account may be outside retention policies, may not follow offboarding controls, and may not represent the legal or operational identity that should authorize access to company systems.

Per-request enforcement helps contain that risk. A protected tool can validate the presented token and evaluate claims that identify the enterprise tenant, user, groups, and applicable policy. The server does not need to assume that a previously connected account remains the right account for every consequential operation.

1. Centralize connection policy.

   Define which teams, applications, and environments may receive a given MCP server integration through the enterprise IdP.

2. Require corporate identity where the resource demands it.

   Avoid treating consumer and workforce identities as interchangeable for internal tools.

3. Make authorization tool-aware.

   Keep broadly safe capabilities available where appropriate, but protect data access and mutation capabilities independently.

4. Log the policy decision.

   Preserve the issuer, subject, relevant claims, requested operation, and allow or deny result in an auditable record.

This model does not eliminate the need for a thoughtful user experience. A user still needs understandable explanations when access is unavailable or additional approval is required. But it replaces ad hoc consent behavior with a predictable enterprise control plane.

Standard OAuth and OIDC patterns are replacing custom agent auth

MCP’s June 2026 authorization specification emphasizes PKCE and inbound token validation. These are significant signals because they align agent-tool authentication with established OAuth and OpenID Connect practices instead of creating bespoke agent identity mechanisms. Standard patterns give security teams familiar primitives to assess and give platform teams a better chance of interoperating across clients, servers, identity providers, and gateways.

PKCE is relevant to authorization flows because it helps protect authorization-code exchanges, particularly for client types that cannot safely hold a confidential secret. Inbound token validation is equally important: a server should not treat possession of an opaque-looking credential as proof of authorization without validating the token appropriately and evaluating the claims it relies upon.

Validate where the decision is made

In a distributed topology, an orchestrator may be trusted to route work but should not become the only enforcement point for protected resources. The MCP server that owns the tool boundary should verify the credentials and make the authorization decision for the call it receives. This reduces reliance on implicit trust between layers and limits the impact of routing mistakes or incomplete context propagation.

A practical server-side validation design should account for the token issuer, intended audience, expiration, signature or introspection result as applicable, subject, tenant or organization claims where relevant, and granted scopes. It should also determine whether the call’s arguments and resource target comply with local policy. Exact implementation choices depend on the token format, IdP, and resource architecture, but the core principle is stable: validate the credential and enforce policy at the resource boundary.

Use extensions without building permanent exceptions

MCP’s March 2026 extensions post describes extensions as a testbed for patterns that may later become protocol behavior. OAuth Client Credentials and Enterprise-Managed Authorization are described as live authorization extensions, and MCP’s extension support matrix lists support for OAuth Client Credentials and Enterprise Auth. This suggests that enterprise identity capabilities are becoming standardized across clients rather than remaining isolated vendor experiments.

For builders, the right response is neither to avoid extensions nor to hard-code assumptions around one implementation. Treat extension support as a capability to discover and govern. Maintain clear fallbacks, document the required client and server behavior, and keep authorization semantics at the server boundary so that future protocol evolution does not force a redesign of every tool.

Machine identity is essential when agents act without direct supervision

Human identity alone cannot govern autonomous execution. Cloudflare’s 2026 Security Signals report describes an “autonomous enterprise” in which agents and agentic workflows execute end-to-end business processes with minimal or no human intervention. The report argues that enterprises still often govern identity as though people are the primary actors, even as software agents take on operational work.

Its recommendation is direct: every AI agent needs a verifiable cryptographic identity, alongside strong authentication, scoped authorization, and lifecycle controls. This aligns with the operational reality of distributed assistants. If an agent is allowed to retrieve information, invoke tools, or continue a task after a person has left the interface, the system must be able to distinguish the agent’s authority from the initiating user’s authority.

Delegation should be explicit, bounded, and inspectable

A useful mental model is that an agent acts under a bounded delegation, not as an unrestricted substitute for the user. The human may authorize a business objective, while the agent identity is authorized to execute defined steps through approved tools. Each step should remain within the scope, duration, and target constraints of that delegation.

• Bind a workload identity to each deployed agent or execution environment rather than sharing a generic credential across unrelated agents.

• Use short-lived credentials and lifecycle controls appropriate to the environment.

• Carry a correlation identifier across orchestration handoffs and tool calls.

• Record both the initiating principal and the executing workload when a tool acts on delegated authority.

• Require an additional approval or separate policy path for irreversible, high-impact, or privileged actions.

This is not an argument for treating every agent as a fully independent employee identity. It is an argument for making machine actors visible and governable. A cryptographically verifiable workload identity gives policy engines, MCP servers, and auditors a dependable principal to evaluate.

Stateless tasks and parallel tools make request context more important

Identity design cannot be separated from execution design. MCP’s July 2026 release candidate describes a direction toward a protocol that is “stateless, cacheable, routable, and globally scalable.” The same release says UI-initiated actions use the same audit and consent path as direct tool calls. That convergence matters because users should not receive a weaker governance model simply because an action originated in an interface component rather than a plain tool request.

The release candidate also reflects a shift away from an always-on session state machine. A server can answer tools/call with a task handle, and the client can drive progress through tasks/get, tasks/update, and tasks/cancel. This server-directed, session-light approach is well suited to distributed execution, but it requires careful treatment of context continuity.

A task handle is not an authorization blank check

A task may outlive a browser connection, a model turn, or the particular worker that initiated it. Systems should therefore avoid interpreting task continuation as unlimited continued authority. The task lifecycle needs a clear association with the identity and delegation under which it was created, as well as rules for expiry, cancellation, reauthorization, and policy changes.

For long-running work, evaluate which decisions can safely remain bound to task creation and which must be checked again when the task performs a later sensitive operation. A status poll may be low risk. A delayed write to a production system may warrant a fresh policy evaluation, especially if the user’s role, the agent’s deployment state, or the target resource has changed.

Parallel calls require independent authorization decisions

Parallel tool calling is becoming a central scaling concern. A February 2026 arXiv paper focused on scaling parallel tool calling for deep research agents, reflecting the field’s effort to increase concurrent integration use. Concurrency improves responsiveness and can enable richer workflows, but it also creates failure modes when shared session credentials or mutable context are treated as the source of truth.

Each parallel call should carry its own request identity context, request identifier, target information, and authorization result. An orchestrator should not assume that approval for one branch applies to another merely because both arose from the same user request. This is particularly important when one branch is read-only and another branch can mutate data, or when branches route to different tenants, regions, or systems of record.

Caching and routing need identity-aware boundaries

As tool workloads grow, teams will optimize repeated calls. A January 2026 arXiv paper argues that redundant and repeated tool calls remain a major challenge and that conventional cache policies do not fit tool-calling workloads well. MCP’s direction toward cacheable and routable interactions reinforces that caching will be part of the distributed assistant stack.

However, caching an answer is not the same as caching authorization. A result produced for one user, tenant, resource scope, or policy state may be inappropriate for another. The value of a cache depends on whether the response is public, user-specific, organization-specific, permission-filtered, time-sensitive, or derived from a mutable system.

Design cache keys around security semantics

Do not key a protected tool result only by the natural-language prompt or tool arguments. Include the security-relevant dimensions needed to prevent cross-principal reuse, such as tenant, entitlement class, resource scope, locale where it affects policy, and a policy or authorization version when available. For highly sensitive data, the correct choice may be not to share cached results across identities at all.

Likewise, route requests using explicit identity and policy metadata rather than inferring access from a connection’s history. A globally scalable system needs request-level information that allows a compatible server instance or gateway to enforce the same decision regardless of which node receives the call.

A practical control-plane blueprint for specialist agents

An AI agent orchestration workspace is a natural place to coordinate specialist agents, preserve context, and run tool-backed workflows, but it should not become a black box that hides identity transitions. The control plane should make routing decisions and handoffs observable while allowing MCP servers to remain authoritative for their protected tools.

OpenAI’s enterprise report illustrates why this matters operationally. It reports more than 7 million ChatGPT workplace seats in use, ChatGPT Enterprise seats up roughly 9x year over year, and about 20% of Enterprise messages processed through a Custom GPT or Project. The report also says widely deployed GPTs codify institutional knowledge into reusable assistants or automate workflows through integrations with internal systems. As reusable workflows spread, their authorization model must be reusable and inspectable too.

Build the request envelope deliberately

Before an orchestrator hands work to a specialist agent or MCP server, construct a request envelope that is sufficient for policy, tracing, and safe execution. Avoid passing raw credentials to every component when a bounded assertion, token exchange, or server-mediated authorization flow is more appropriate for the architecture.

• Initiator:

  the authenticated user, service, or automation that started the workflow.

• Executor:

  the specific agent or workload identity performing this step.

• Delegation:

  the purpose, scope, expiry, and approval state associated with the action.

• Operation:

  the selected tool, sanitized arguments, intended target, and risk classification.

• Trace:

  workflow, task, parent-request, and tool-call identifiers that connect events across systems.

• Policy evidence:

  the applicable decision, challenged scopes if any, and reason codes suitable for operators.

Adopt a staged implementation path

1. Inventory tool boundaries.

   Identify public, read-only, sensitive-read, write, and privileged tools. Do not classify an entire server as one risk category if its tools serve materially different purposes.

2. Connect enterprise identity.

   Use standard OAuth/OIDC patterns and enterprise IdP policy where supported. Establish corporate-account requirements for internal systems.

3. Introduce tool-level challenges.

   Allow public tools to remain low-friction while requiring authorization only for protected capabilities.

4. Give agents workload identities.

   Make every production agent execution attributable and apply lifecycle controls to those identities.

5. Instrument before expanding autonomy.

   Capture request-level decisions, task transitions, tool results, denials, and cancellations before allowing broad unattended execution.

6. Test adverse paths.

   Test expired tokens, incorrect tenants, revoked access, account mismatch, task resumption after policy change, concurrent calls, and denied argument combinations.

This approach favors incremental hardening over a large identity rewrite. It also aligns with MCP’s broader roadmap direction: interoperable discovery, token validation, policy controls, and extension-based validation rather than custom authorization glue for every agent vendor and integration.

How to measure whether the design is trustworthy

Trustworthiness in agent integrations is demonstrated through operational evidence, not declarations that an assistant is secure. Teams should be able to reconstruct an important workflow, identify the initiating and executing principals, show the tool-level authorization decision, and explain how a task or handoff remained within policy.

Useful review questions include the following:

• Can operators determine which identity authorized a specific protected tool call?

• Can they distinguish the human initiator from the agent or service that executed it?

• Does the protected MCP server validate inbound authorization context rather than relying entirely on an upstream session?

• Can public and protected tools coexist without granting broad access to the whole server?

• Are resumed tasks and parallel branches bounded by explicit identity and delegation context?

• Can cache and routing behavior prevent data from crossing tenant or entitlement boundaries?

• Can security and operations teams revoke access, disable an agent identity, and investigate prior calls without relying on informal application logs?

These questions support E-E-A-T in a practical technical sense. Expertise appears in correct use of established identity patterns. Experience appears in operational testing of failure cases and handoffs. Authority comes from enforcing policy at the systems that own protected resources. Trustworthiness comes from verifiable identities, clear consent and policy paths, and durable audit evidence.

Per-request identity is not a cosmetic protocol feature. It is the foundation for making multi-agent, tool-backed execution accountable as assistants move from answering questions to carrying out business processes. MCP’s per-tool authorization model, enterprise-managed authorization, standard OAuth/OIDC direction, task-oriented execution, and extension ecosystem together support a future in which identity follows the work rather than being assumed from a persistent session.

For teams building distributed assistants, the immediate priority is clear: model every sensitive tool call as a distinct, attributable authorization event. Centralize enterprise policy, give agents verifiable workload identities, retain delegation context through routing and task lifecycles, and keep enforcement close to the tool server. That architecture enables faster integration growth without sacrificing the control, auditability, and least-privilege discipline enterprises require.