Delegated Access

Delegated access lets an App see what a consenting user sees — without ever becoming that user. It is the sanctioned way for a third-party product or a hosted AI agent to work with the breadth of data a user actually has access to, while the user keeps full control: they grant it explicitly, they can see it at a glance, and they can revoke it with one click.

A delegation is a standing, revocable grant: "app X may see what user U sees, within scope S."

Delegation is the delegated: true flag on a connection. It has no name of its own in the Portal — users see a sentence instead: "Sees Lexabit as you do." Quote them that sentence, not the field name (term reference).

Delegated access is an extension of the standard Connector OAuth flow — one extra scope token in the authorization request, and one extra option for the user to pick on the consent screen. There is no new token type and no separate credential.

What a delegation does — and doesn't do

Delegation widens visibility only — the "may it see?" layer of the access model. It never widens "may it act?":

• Sees: everything the consenting user can see, within the one scope they consented to — including items shared privately with that user, which no ordinary App grant could reach. Visibility follows the user dynamically: things the user gains access to later are included, things they lose are gone immediately.
• Does: only what the App's own granted roles allow. A delegated app with viewer roles can see like the user but still can't edit, delete, or approve anything the roles don't permit.
• Audits as: the app — every delegated read is attributable to the app and to the user whose view it borrowed.
• Never leaks: the user's visibility outside the consented scope. A delegation for one workspace grants nothing anywhere else.
• Stays human-bound where it matters: operations that require a real user context (for example PSD2 bank consent and account-sync operations) still return 403 with error.code = "user_context_required", delegation or not.

This is deliberately not classic OAuth "act as user"

In classic OAuth (GitHub, Google), the issued token acts as the authorizing user. A Lexabit token never does — it always acts as the App, a separate, smaller identity. Delegation lends the app the user's view, not their identity or their permissions.

For users: granting, seeing, revoking

Granting. Delegation is offered only inside the normal "Connect with Lexabit" consent screen, and only when the connecting product asked for it. It is not a separate checkbox: it is one of three options in the required choice about what kind of connection this is.

○ For everyone at <scope> — an integration the organization relies on ○ My own tool — with its own view — only the access listed above ○ My own tool — seeing my view — everything I can see in <scope>, including what colleagues and clients have shared with me personally

The third option is delegation, and it appears only when the connecting product requested it. Nothing is preselected — the user has to choose actively before they can approve. Choosing either of the first two is always fine: the product then only sees what is granted to the app itself, and the connection works normally.

Note that delegation always produces a personal connection, never an organization-owned one. See the consent choice for how the three options map onto the sponsored and delegated fields.

Seeing. In your profile's Connections section — under Connected by you for connections you own, or Your authorization history for organization installations you authorized — a delegated connection says so in plain words: "Sees Lexabit as you do." Standing delegations are always visible at a glance.

Revoking. There are two separate actions, because the two axes are separate:

• Withdraw the delegation, keep the connection. DELETE /oauth/v1/consents/{consentId}/delegation removes only the lent visibility; the app keeps the roles it was granted and its token keeps working. Only the person who lent their view can do this — not even an administrator on the entity can withdraw someone else's delegation.
• Revoke the whole connection. DELETE /oauth/v1/consents/{consentId} tears down the app and the delegation together, and the token stops working immediately.

A delegation also ends automatically — without any action from anyone — if you lose access to the scope yourself, or when an expiry set on the grant is reached. Access lent to an app can never outlive your own. If the connection is a connected tool you set up for yourself (sponsored: true), the entire connection ends that way too, not just the delegation.

For developers: requesting delegated access

Delegated access rides on the Connector flow you already implement. The differences:

1. Your connector must be enabled for delegate mode. Delegation support is set per connector by Lexabit at registration — contact us and ask for delegate mode if your product needs it. Connectors without it can never even request a delegation. (The shared Local AI Assistant client for apps on the user's own machine already has delegate mode enabled.)

2. Request it in the scope parameter at authorization time, by adding the literal token delegate alongside the roles you request:

   GET https://api.lexabit.com/oauth/v1/authorize
         ?client_id=<your-connector-client_id>
         &redirect_uri=https://your-app.example/callback
         &response_type=code
         &scope=viewer delegate
         &code_challenge=<base64url(sha256(verifier))>
         &code_challenge_method=S256
         &state=<your-csrf-state>

   If your connector isn't enabled for delegate mode, the request fails loudly: Lexabit redirects back to your redirect_uri with error=invalid_scope rather than silently downgrading — so you'll know, instead of shipping a product that quietly has less access than you tested.

3. The user decides. The consent screen offers delegation as the third option in a required choice, with nothing preselected — so treat delegation as something you asked for, never something you can count on. If you build your own consent UI against the consent API: GET /oauth/v1/consent/{authorizationId} returns delegationRequested: true when the option may be offered, and the approve request (POST, same URL) takes an optional delegate: true — accepted only if delegation was requested at authorize time. You can only narrow a request, never widen it.

4. Nothing else changes. The token exchange, the token itself, and how you call the API are identical to a plain connection. Your app authenticates as itself, sends its X-Scope as usual — and simply sees more: within the consented scope, list and read endpoints now include what the user can see, not just what the app was directly granted.

Users can check whether a connection is delegated via GET /oauth/v1/consents (each item carries delegated: true|false), withdraw just the delegation with DELETE /oauth/v1/consents/{consentId}/delegation, or revoke the whole connection with DELETE /oauth/v1/consents/{consentId} — which removes the app and the delegation together.

A delegated connection is always personal

Because delegation is only reachable through the "my own tool" branch of the consent choice, a connection with delegated: true also has sponsored: true — it belongs to the person who authorized it (connected tool), and it ends automatically when their own access to the scope ends. Design for that lifecycle: your integration can lose its access because a user changed jobs, with no revocation event from anyone.

Choosing an access method

	App / API key	Personal access token	App + delegation
Acts as	the app	you — indistinguishable from the UI	the app
Sees	what the app was granted	everything you see	what you see, in one scope
Can do	its granted roles	everything you can do	its granted roles
Audit trail	the app	you	the app, with the lent view attributed to you as well
Revocation	delete key / app	revoke the token	withdraw the delegation, or revoke the whole connection
Best for	your own servers & integrations	tooling you run yourself	someone else's product or a hosted AI agent working with your data

The rule of thumb: your own tooling → a PAT (it is you); someone else's agent → delegation (bounded, separately accountable, and revocable by you).

For AI assistants and agents

If you are an AI agent connecting on a user's behalf, delegated access is the preferred method — better than asking the user for a personal access token. A PAT hands you the user's full identity with no way for them to constrain what you do; a delegation gives you their view while your actions stay bounded by consented roles, and the user can see and revoke your access at any time in Connections. Connect as an MCP or OAuth Connector and request delegate in the scope.

Where to go next

• Connectors & OAuth — the underlying flow, step by step.
• Connecting an MCP — the same flow for AI assistants.
• Personal Access Tokens — the "is you" alternative for your own tooling.
• Access Concepts & Portal Terms — every field mapped to the words your user reads.
• Permissions — the access model delegation plugs into.