An AI assistant workflow combines model output with retrieval or actions performed through connected applications. Each connection adds an executing identity, a resource scope and permitted operations to the workflow.

Requester identity and connector identity

A requester asks the assistant to perform a task. A connector calls another system under an executing identity. Those identities can have different permissions.

Take an assistant service that can read 100 accounts and a requester permitted to view five. Authentication of the assistant service establishes its identity to the connected system. It does not establish the requester’s right to the other 95 accounts.

If the connector returns all 100 accounts solely because its service identity can access them, the workflow has expanded the requester’s effective access. A perfectly accurate summary of those accounts would still cross the intended permission boundary. Model accuracy does not determine resource entitlement.

Retrieval and actions require separate decisions

Reading a balance, retrieving a document and submitting a payment are different operations. A connector offering all three capabilities needs an authorization decision appropriate to each requested action and resource.

Desktop context illustrates a narrower interaction. An application can pass a selected instrument or client context to another application. The context identifies what the user is considering; it does not establish authority to trade the instrument or move the client’s assets.

The composed assistant needs to preserve that distinction. Converting a retrieved instruction into a proposed action does not turn the document into an authorization record. The execution boundary still needs evidence that the action is permitted for the requester and account.

Why adding a connector changes the control scope

A connector changes the set of resources or operations the assistant can reach. That change can occur without changing the language model, its accuracy or the user interface.

The mechanism has two premises: the assistant can call connected applications, and its executing identity can have broader permissions than the requester. Under those conditions, a workflow that checks only the executing identity can expose resources outside the requester’s scope. Preserving the requester’s scope requires a resource and action decision along the composed path.

A permission check at the first application is insufficient if a later connector broadens the resource set. The relevant evidence follows the requester, target resource, requested operation and policy decision through the actual sequence.

Authorized composition as the countercase

A connector that already enforces requester-scoped authorization can preserve the boundary. Separate connections can also expose narrowly bounded capabilities with no broader resource reach. Adding a connector therefore does not inherently cause unauthorized access.

The consequence depends on the authorization design. A correctly bounded workflow can gain useful capabilities while preserving the original user’s permissions. The point of evaluating the composition is to establish that property for the real path, rather than inferring it from individual logins or model quality.

Scope of assistant evaluation

Factual accuracy, retrieval quality and authorized execution require different tests. A retrieved answer can be correct but unauthorized. An authorized response can still contain an inaccurate calculation. A permitted action can fail operationally after authorization.

What changes with connected applications is the reachable information and action space. The stable requirement is that the complete workflow preserve the authorized relationship among requester, resource and operation. The model’s ability to describe an action is a separate capability from the system’s authority to execute it.

Questions about delegated authorization

Does an accurate AI answer prove the user was entitled to its data?

No. Accuracy and resource authorization are separate properties.

Does adding a connector always violate permissions?

No. Requester-scoped enforcement and bounded capabilities can preserve the authorization boundary.

Can permission to read an account authorize a payment?

No. Reading information and initiating a financial action require separately defined permissions.