In the previous article on autonomy and authority, I explored the difference between allowing an agent to choose a task's next steps and granting it authority to produce external effects. I used the Controlled Autonomy Lab as an example: the model could decide which evidence to consult, but the available tools and execution boundaries remained defined by the application.
The text ended with a question that deserves separate examination: if an action requires authorization, which identity is actually exercising that authority?
The answer seems simple when there is only one authenticated user, one application, and one API. The situation changes when the request passes through an orchestrator, is delegated to another agent over A2A, and ends in a tool exposed through MCP.
Every component can be correctly authenticated, yet the architecture can still allow an operation the user was not authorized to perform. This happens when the identity of the person requesting the work, the identity of the service making the call, and the permissions actually granted stop being treated as different things.
One request, several identities#
Imagine a corporate assistant receiving this request from an authenticated user:
“Check my company's pending payments, find which ones are due this week, and prepare those that need approval.”
The main assistant identifies the intent and delegates the analysis to a remote financial specialist over A2A. That specialist uses an MCP server to query payments and another service to prepare approval requests.
The topology looks relatively simple, but there are distinct identities. The user has a corporate identity associated with the companies, accounts, and operations they may access. The main assistant runs under a workload identity, used to authenticate its service in integrations. The remote specialist has its own workload identity. The MCP Server must identify the principal authorized for the requested operation and apply the corresponding controls before accessing financial systems.
Enlarge ↗The workload identity proves which component is calling the service. It does not, by itself, demonstrate that the component is authorized to act on behalf of a particular user.
This distinction matters because service-to-service authentication and authorization over business data can operate at different layers. A token obtained using Client Credentials, for example, normally represents an application acting on its own behalf. It does not automatically come to represent the user who started the conversation.
The risk emerges when a broadly privileged service token ends up substituting for these checks. If the specialist uses a credential capable of changing payments for any company, but the legitimate request involves only one of them, there is a difference between the credential's technical reach and the operation's authority.
If isolation between companies depends solely on a company_id parameter generated by the LLM, the security boundary will be particularly fragile. The model may select the wrong company, misinterpret the context, or receive malicious instructions in a consulted source. The server must associate the requested resource with the authenticated and authorized principal. The identifier sent as a tool argument is data to validate, not proof of permission.
Delegating a task should not transfer every permission#
A2A provides a mechanism for agents to discover capabilities and exchange messages, tasks, and results. Its specification includes authentication requirements announced in the Agent Card, with schemes that can use OAuth, OpenID Connect, and other security mechanisms.
This solves part of the communication. The main agent discovers how to authenticate to the remote agent, and the A2A server identifies the caller. Authorization remains the responsibility of the party receiving the request. The protocol does not specify that an agent automatically inherits all permissions of the party delegating the work.
I would treat the call between the orchestrator and the specialist as a first boundary. The A2A service would validate the caller's identity and permission to request that capability. The next call, from the specialist to the MCP Server, would cross a second boundary: the identity and permissions presented must be appropriate for the protected resource.
I would not indiscriminately reuse the same access token throughout the chain. A token intended for the A2A service should not be accepted by the MCP Server simply because they belong to the same platform. Nor should a credential for querying payments, by extension, authorize transfers.
The RFC 8707 defines Resource Indicators, a mechanism by which a client tells the authorization server which resource it is requesting access to. The desired property is that each resource accepts only credentials intended for its security boundary, with appropriate permissions.
When it is necessary to preserve who initiated the request and which workload is acting on their behalf, RFC 8693, on OAuth 2.0 Token Exchange, offers another mechanism. It specifies token exchanges and distinguishes delegation from impersonation. In profiles using this semantics, sub may identify the original subject and act the delegated actor.
Enlarge ↗This does not mean every OAuth provider offers the flow. Issuing composite tokens, delegation policy, and token-exchange support depend on the authorization server. When that support is absent, an app-only operation with specific authorization may be appropriate, provided the application's identity is not presented as equivalent to the user's.
I would also avoid confusing delegation with impersonation. When the downstream service sees only the user, it may lose information about which workload actually acted. This distinction matters for investigation, segregation of duties, and accountability.
The MCP Server needs to authorize the tool at call time#
I developed two open-source templates to explore the authentication boundary between MCP client and server: mcp-client-auth-template and mcp-server-auth-template. They are reference implementations with OAuth/OIDC, token validation, permission separation, and negative checks, such as rejecting an incorrect audience.
An important decision in the templates is to separate transport admission from authorization for each operation. A valid access token helps identify the principal, but the service still needs to check the permissions and business constraints relevant to the request.
In the financial example, the MCP server could expose list_pending_payments, prepare_payment and execute_payment. The first allows queries within the scope of authorized companies. The second prepares a request pending approval. The third produces financial effects and crosses a distinct boundary.
I would not assign all three operations the same permission level merely because they belong to the same domain. A policy may automatically allow queries, prepare payments under certain conditions, and require explicit authorization tied to the concrete operation before execution.
Enlarge ↗The MCP Server would perform the check before dispatch. The financial API, in turn, would remain responsible for its own authorization controls, transaction limits, and consistency. An MCP proxy does not automatically secure an API that indiscriminately accepts its intermediary's technical credential.
In the MCP HTTP authorization specification, the client uses OAuth and must request tokens intended for the appropriate resource; the server validates that the token was issued for it. The security considerations prohibit directly forwarding inbound tokens to downstream APIs.
I would also distinguish authentication errors from authorization errors. A missing or invalid credential normally implies 401. An authenticated token without sufficient permission may result in 403 insufficient_scope. This may trigger an additional authorization flow, but does not mean the agent should silently expand its privileges whenever a tool denies access.
The technical ability to request more scopes is not a justification for granting them. The decision remains subject to policy, resource, and, when necessary, user interaction.
The boundary needs to survive the next agent#
Now imagine the financial specialist receives the payment list and delegates document checking to a third agent. That agent needs to consult receipts and related invoices, but does not need to access balances in other accounts, change beneficiaries, or execute transactions.
Delegation should keep the work possible without unnecessarily expanding privileges. I would represent the task in a contract with the requested capability, permitted resources, and constraints. That contract would not, on its own, be a security credential: its attributes would need to be bound to verifiable authorization.
Enlarge ↗A generic role named financial_agent may make sense as part of the policy, but does not determine what the agent may do in a specific execution. Amounts, accounts, beneficiaries, company, purpose, and operation timing require more contextual decisions.
An implementation may separate the authorization decision into a policy component (PDP) and application of the result into an enforcement point (PEP), whether in the gateway, MCP Server, or API. Location depends on the architecture, but every boundary needs clear responsibilities.
There is also a consequence for long-running tasks. An agent may receive authorization at the beginning and try to complete the operation hours later. In that interval, the user may lose access, the policy may change, or an approval may expire. Issuing a token through exchange does not automatically guarantee that a later revocation of the original token reaches the credential already issued.
For sensitive operations, I would require revalidation of authorization at the moment of effect, limited credential lifetimes, and appropriate revocation mechanisms. Authority granted at the beginning of a process should not be considered permanent.
An auditable execution must identify who requested and who acted#
In previous articles on execution identity and distributed observability, I discussed identifiers such as execution_id, delegation_id and trace_id. They help reconstruct the path between components, but do not represent security identities.
A request can cross the orchestrator, A2A, and MCP in a single trace and still perform an unauthorized operation. A coherent technical history does not, by itself, prove that the principal had permission over the accessed resource.
For relevant operations, I would record authorization evidence correlated with the execution: the subject who originated the request, the workload that acted, the action requested, resource, policy applied, decision, evaluation time, and reference to the external effect, when there is one.
Enlarge ↗This allows an operation executed using a legitimate technical credential to be distinguished from an operation legitimately authorized for a particular user and account. The investigation needs to see both the path and the legitimacy of the effect.
At the same time, I would avoid recording tokens, secrets, or full financial payloads in telemetry. Opaque identifiers, appropriate hashes, and decision references normally offer a safer path, provided they are accompanied by defined retention, custody, and access control.
The MCP templates exercise this separation between identity, authorization, and observability. This demonstrates properties of the implemented path, but does not mean an A2A architecture built around them already has end-to-end delegation of authority solved.
Where I would place the boundary#
For the financial case, I would preserve the agent's freedom to consult information, select specialists, and prepare analyses within an authorized scope. Moving to an operation that changes financial state would require another check.
The specialist could produce a structured payment proposal. A component outside the model's reasoning path would check the requester, account constraints, approval validity, and the correspondence between what was authorized and what will actually be executed.
If any check fails, the action does not proceed. I would also not consider it acceptable to silently fall back to a more privileged service credential to bypass the denial.
In some architectures, the agent does not even need to receive the execution tool. It prepares the request, and a separate transactional service, with its own identity, policies, and controls, produces the effect. This introduces complexity: per-workload identities, resource-bound tokens, contextual authorization, and operational evidence create dependencies. An internal read-only tool may not need the same structure as a service that moves money or accesses multiple companies' data.
When agents cross multiple security boundaries and can generate high-impact effects, however, that complexity already exists in the business process, even if a simplified architecture tries to hide it.
When integrating agents over A2A and tools over MCP, I would begin by identifying each trust boundary. At every one of them, the system needs to be able to demonstrate who is calling, on whose behalf, with which permissions, and to produce which effect. The agent may choose the tool or delegate part of the work; the infrastructure must remain capable of verifying whether that identity has authority for the requested action.