Descope announced Envoy on November 4, 2026, offering retailers and consumer-app operators a separate sign-in route for customers’ AI assistants. The aim is to let an assistant act for a customer without treating its activity as the customer’s own login.
Descope says businesses can distinguish the customer from the assistant, limit the assistant’s permissions and revoke its access without signing out the customer. That separation could help a business admit an assistant for a specific task without handing it the customer’s full account access.
Access is restricted for now. The Agent Login documentation says the feature is in early access, requires an Enterprise license and must be enabled by Descope Support or the customer’s assigned engineer. Enterprise pricing is quote-based; the public page does not establish a numerical Envoy price. The general platform’s cheaper plans should not be read as Envoy offers.
Choose the customer task before the sign-in system
For a first pilot, a retailer could let an assistant retrieve an order’s status while keeping purchases, refunds and payment changes out of scope. That is a proposed starting point, not a reported customer deployment. It gives the business a concrete decision: which information may this assistant read, and which actions must it never take?
The distinction matters because sign-in alone does not supply the service. Descope’s responsibility guide says the business must expose an API—the software interface an assistant calls—that accepts the assistant’s access credentials, known as tokens, and enforces its permissions. A site offering only public browsing may not need delegated account access at all.
Access is also separate from being discovered inside an assistant. For app owners weighing that question, Google’s Connected Apps preview covers distribution into Search and Gemini. Envoy addresses identity and permission; it does not by itself establish a Google integration.
Decide when the customer must approve
There are three different decisions: letting an assistant connect, deciding how long its permission lasts, and approving a particular purchase or account change. They should not be treated as one checkbox.
Descope advertises customer approval for selected sensitive actions, with businesses choosing what triggers a request. But its consent-flow documentation distinguishes recording permission from displaying an approval screen. With automatic approval of requested permissions enabled, consent can be recorded without that screen. Previously granted permissions can also be reused without another prompt; new permissions or expired consent can require a fresh decision.
The practical implication is that a promise such as “you approve every purchase” needs a transaction-specific approval rule. Before a pilot, specify what the customer sees, which action their approval covers, how long it remains valid and what happens if they decline. Do not infer those protections merely from a successful agent login.
Make disconnection work beyond the settings page
Descope’s approved-agent list initially uses a wildcard, allowing any agent to connect. A pilot can replace it with named agent domains. Narrowing that list controls new connections, however; removing a domain does not itself revoke identities that already have access.
Revocation is a separate step. The Agent Login guide says it invalidates the agent’s access and refresh tokens while leaving the customer’s own session intact. An agent can continue signed out, so revoking account access is not necessarily a ban on reading public pages.
There is also an enforcement choice. Descope’s token-introspection documentation explains that a server checking a token locally can continue accepting it until expiry after access is revoked. Asking Descope for its current status on each request provides fresher authorization information but adds a network call. Caching those answers reintroduces a period of possible staleness.
For a business that needs a prompt cutoff, the decision therefore includes how each relevant API checks access—not just where the disconnect button appears. A token’s remaining lifetime matters if validation is local only. Ending access should not be assumed to reverse a completed purchase or cancel work already queued in another system.
Keep the existing login, but budget for integration
Businesses using another sign-in provider can retain it, according to Descope’s existing-login guide. Their backend must identify the customer account to Descope, using a stable account identifier, and their APIs need a way to accept, validate or exchange Descope-issued tokens. Customer-facing controls for listing and disconnecting assistants also need to be connected to the business’s account settings.
The setup guide adds an operational detail worth checking with the identity team: enabling Agent Login turns on Device Authentication across the whole Descope project, not just for the new agent application.
Confirm the assistant and the cost before committing
Envoy uses the Personal Agent Protocol, also called Poppy, to help assistants discover services and sign in. The official changelog still labels version 0.3 an in-progress draft with breaking changes. Descope’s JavaScript SDK is marked pre-release and currently supports Device Sign-In, not every sign-in route. Confirm the exact assistant, protocol version and supported flow before promising customers compatibility.
Ask Descope to confirm Enterprise enablement and quote the planned usage, including which users, permissions and token exchanges count toward charges. Its public pricing table lists several usage measures but does not settle the total cost of an Envoy deployment.
A limited pilot makes sense when there is a useful account task, a compatible assistant and an owner for permissions, approvals and disconnection. If those pieces are not in place, defer customer-account access. The meaningful result is a task completed within the customer’s intended limits, not simply an agent that can sign in.