An agent handshake, a token and a question of authority

The connector works. An assistant discovers a document-search tool, sends a valid request and receives a structured response. That is a useful interoperability result. It is not yet evidence that the response contains only records the user may see, or that a later editing tool will act within the user’s authority.

The distinction can disappear during a demonstration because successful connection is visible and permission enforcement is often quiet. A connection error interrupts the experience. A missing access check may leave the interface looking successful. To understand what the new tooling enables, follow the request beyond the moment the plug fits.

This article uses a fictional document service to examine that journey. No real connector is accused of the failures described. The service supports several teams, each with its own records. A user asks the assistant to find and summarize a report from their team. The intended task is ordinary; the boundaries around it are where the interesting work begins.

The handshake establishes a conversation

The Model Context Protocol supplies a common conversation for discovering and calling tools. In its HTTP authorization arrangement, three roles are distinct: a client requests access, an authorization server issues the token, and the protected MCP server receives the resource request. The authorization server can be part of the same deployment or a separate service. The connector succeeding is not evidence that every one of those roles has made the required trust decision.

The protocol’s July 2026 authorization specification describes authorization for HTTP-based transports and distinguishes that arrangement from credentials supplied to a local standard-input/output integration. Authorization is optional for MCP implementations at the protocol level; the specified flow concerns implementations supporting it. A product’s actual transport and protection arrangement still matter. An MCP label alone therefore neither promises an OAuth flow nor describes the record-level access rules behind a tool.

For the fictional search, the first question is which service the client has reached. A familiar display name is insufficient if it is not bound to the intended endpoint and configuration. A user can approve a recognizable tool name while the application points somewhere else. Connection management needs an account of the actual service identity, rather than relying only on how a connector appears in a menu.

There is also an installation boundary. A local integration and a remote integration can have different access to files, network services and environment-provided credentials. The product should describe what it is enabling in the relevant arrangement. One reassuring screenshot of a remote authorization flow should not be used as proof of the behavior of every possible local tool configuration.

The token establishes a bounded claim

The authorization specification requires the client to identify the intended MCP server through the resource parameter in both the authorization and token requests. The server still needs to validate the received token’s audience and other requirements. A calendar token is not automatically a document-search token because both arrived through a working connector. Naming the recipient when asking for a token and checking the recipient when accepting it are complementary operations.

The MCP security guidance on token passthrough explains why accepting tokens issued for other resources and forwarding them downstream is an anti-pattern. Audience validation and correct handling of downstream credentials preserve different trust relationships. This is a concrete implementation responsibility, not something an assistant’s natural-language explanation can satisfy.

The fictional document service also needs to establish the person or principal on whose behalf the request is made. A connector’s own service identity and the end user’s identity can be different. Broad credentials belonging to the integration should not silently give every connected user the integration’s entire view of the organization.

NIST’s August 2026 discussion of agent identity places identity and authorization at the foundation of agentic systems. It is an institutional perspective on the problem, rather than a certification of any connector. The practical question for a deployment remains specific: which principal is responsible for this operation, and what evidence binds the operation to that principal’s permitted scope?

The search still needs to know which records belong in the answer

Authentication can succeed while resource authorization fails. In the fictional service, a user belonging to team A asks for a report whose stored owner is team B. The server must evaluate the authenticated principal against that report’s access policy; a model-supplied team=A argument cannot change the report’s owner. If the report is legitimately shared with A, the policy may allow it. Otherwise the same syntactically valid identifier must be refused. This is a resource decision after connection and authentication have succeeded.

This matters even for a tool called search or read. A read operation can disclose confidential information. A tool does not have to modify a record to have a consequential effect. An authorization design focused only on destructive actions can miss the central risk in a document assistant: putting the wrong material into the answer.

Filtering only after retrieval can be inadequate if unauthorized content has already entered the assistant’s context or another processing component. The system should examine where access rules are applied and which components receive data along the way. A user interface that hides an unauthorized source link does not retract information already used to produce a summary.

Permission changes need to propagate as well. A person may leave a team, a document may become restricted or a sharing arrangement may expire. A cached search result or long-lived session should not automatically preserve access beyond the intended grant. The relevant policy determines what should happen; the implementation needs a way to make that policy effective during ordinary operation.

The description helps the model choose; it does not enforce the choice

A tool exposes a name, description and input structure. These help a client or model understand how to call it. The MCP tools specification also discusses behavior annotations and cautions clients about their trustworthiness. A descriptive hint and an enforced restriction are different mechanisms, even when they use similar words.

For the fictional service, a tool described as read-only should still have an implementation whose permitted behavior matches that description. The label cannot substitute for the service’s actual operations. A client that uses annotations to simplify its interface should know which server it trusts to supply them and what other controls remain necessary.

Input validation addresses another part of the boundary. A schema can ensure an identifier is a string or that a required field is present. It does not necessarily show that the identifier belongs to an authorized record, or that the proposed operation is appropriate. Structural validity is useful evidence about the request’s form; access rules still need to evaluate its meaning in context.

Tool results need careful interpretation too. A returned document may contain instructions written by someone outside the user’s authority. It remains source material, not a new permission grant. Connecting more tools can increase the useful work an assistant can perform, while also increasing the consequences of confusing a document’s content with the user’s instruction.

The edit is a second decision

Suppose the user later asks the assistant to update the report. This is a new kind of operation with a visible effect. The service needs to check whether the user may edit that particular record and which changes are permitted. Prior permission to search should not become unlimited permission to modify everything that search can find.

An appropriate review step, where required by the product’s policy, should show the actual target and proposed change. A generic permission to use a connector can be too broad to communicate the consequence of a particular edit. The approval should remain bound to what was reviewed if the assistant changes the target or content before execution.

Concurrency introduces a different issue. Another person may edit the report between retrieval and update. The system needs a defined way to avoid silently overwriting changes or acting on stale assumptions. A successful network request is not sufficient evidence that the intended update was applied to the intended version. The response and subsequent verification should establish the relevant outcome.

Retries require similar care. A lost response can leave the client uncertain whether an edit succeeded. Repeating an operation may be harmless in some designs and create a duplicate effect in others. The application should distinguish those cases, use appropriate mechanisms for the operation and report uncertainty honestly when it cannot yet establish the external state.

The audit should describe what happened, not only which model spoke

A useful record connects the requesting principal, target resource, proposed operation and actual outcome. It should distinguish an access refusal from a tool failure, and a completed action from an attempted one. An incident cannot be understood from a transcript that merely says the assistant thought it had permission.

Logging itself needs a boundary. Retaining every document and credential in diagnostic records can create another exposure path. The team should retain what it needs to operate and investigate the service under its applicable policy, with appropriate access and retention. More detail is not automatically a better audit if the record becomes an uncontrolled copy of the information the service was meant to protect.

Version changes belong in the record too. A connector update can add a capability, change a description or alter the backend arrangement. A permission review performed for an earlier configuration may not cover the new one. The product needs to know which changes require evaluation rather than treating every update as a transparent replacement of identical behavior.

What a connected demonstration can now prove

The fictional service can be tested with users from different teams and harmless records designed for the evaluation. Search should return the allowed material, cross-team requests should receive the defined response and permission changes should take effect through the intended process. Edits should be checked separately, including stale versions and uncertain responses. These are concrete cases the deployment can demonstrate.

The point is not to make every useful integration cumbersome. Standard interfaces can make well-designed services easier to connect, and good authorization can remain mostly invisible during routine work. The objective is that the invisible part continues to work when a request is mistaken, ambiguous or outside the user’s scope.

The test should examine partial disclosures, too. A service might hide a report’s body but still reveal a sensitive title, author or search-result snippet. Whether those details are permitted depends on the access policy. Treating an empty download as proof that no information was exposed can miss what the search already returned. The accepted result needs to follow the information through each response, rather than inspect only the final document endpoint.

Permissions also need a defined effect during work already in progress. If a grant changes between search and edit, the service should apply its current operation policy at the point of execution. An earlier successful read should not be treated as permanent evidence for a later action. The exact handling may vary by application, but it should be deliberate, testable and visible in the operation’s result. This gives administrators an actual control rather than a setting whose effect is postponed indefinitely by existing sessions.

The plug fitting is worth celebrating as an engineering milestone. The service becomes dependable when the right identity, resource and action remain bound together after the connection succeeds. A protocol can carry that conversation. The organization operating the tool still has to decide—and enforce—what the conversation is allowed to accomplish.