> For the complete documentation index, see [llms.txt](https://docs.mediafier.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mediafier.ai/trust/per-user-connector-authorization.md).

# Per-User Connector Authorization

When a connector acts as the individual user, what is authorized, and what is charged.

> **Some connector surfaces may need to act as the individual user rather than the organization. When a person connects their own account to such a connector, Mediafier stores a per-user credential and injects *****that person's***** authorization at call time — the tool acts within the access the person already has, and every call is attributed to all three identities: the person, the organization, and the external account. Mediafier is validating this pattern on an initial delegated connector.**

***

## Two ways a connector gets its credential

Mediafier connectors resolve their upstream credential in one of two modes. The mode is a property of the binding, resolved server-side — a caller never chooses it at request time.

| Mode               | Whose access the tool uses                                                                                                | Typical use                                                                                 |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| **Org-bound**      | One credential shared by the organization (a stored secret or an org-level OAuth grant), used by every authorized member. | Back-office systems where the org, not the individual, is the actor.                        |
| **User-delegated** | The **acting person's own** authorization, connected once via OAuth and stored per user. The tool acts *as that person*.  | Systems where individual identity and permissions matter — issue trackers, docs, messaging. |

This page is about the second mode. It is the model behind "connect *your* account," where the tool should see precisely what you can see and act only where you can act.

***

## What "user-delegated" means, precisely

When you connect your own account to a user-delegated connector:

1. **You authorize once, through OAuth.** You approve the connection directly with the provider. Mediafier receives a per-user access token scoped to what you granted.
2. **The token is stored as *****your***** credential, bound to *****you*****.** It is held server-side, associated with your Mediafier profile and your organization. In the delegated path, Mediafier keeps credential bytes out of audit metadata and does not return the token in tool responses.
3. **At call time the gateway resolves and injects your token — server-side.** When you (or an agent acting on your behalf in a person-present session) invoke the tool, the gateway resolves *your* stored token and injects it just before dispatch. The runtime does not store or resolve credentials itself; it only consumes the gateway-injected credential and forwards it upstream.
4. **The upstream sees you.** The call reaches the provider as *you*, so the provider's own permissions apply. Reads return within what your account can access, and writes are attributed to your account. Linear issue discovery supports explicit filters but adds no implicit assigned-to-you restriction.

> **Directional, not shipped.** User-delegated binding is a proving ground — it is being validated on a first connector before it becomes a general capability. What is described here is the substrate and the guarantees, not a launched, self-serve feature for every connector.

### Removing the grant removes the access

Your delegated grant is a single, revocable authorization under your control. Disconnect it in Mediafier — or revoke it at the provider — and the access is gone; no fallback or shared credential is substituted. See [Disconnecting](#disconnecting) below for exactly how calls behave after removal.

***

## Why this is safe

User-delegated auth inherits every guarantee of the platform's identity and gateway model, and adds a few of its own.

* **Identity is still server-derived.** You authenticate to Mediafier with Auth0 exactly as everywhere else; the gateway derives who you are and which organization you're acting in from that token — never from a client-supplied claim. The delegated provider token is a *resource* credential, not an identity claim.
* **Authorization is checked at the surface.** Being connected is not the same as being allowed. Each tool surface is independently authorized; a connected user can still be denied a specific surface (for example, an approval-gated write) even when the connector itself is reachable.
* **Writes can require explicit approval.** A user-delegated write surface can be **approval-gated**: the gateway pauses the call and surfaces a draft for review, and nothing reaches the provider until a person approves. The credential is injected only *after* approval — a paused call never touches your token or the upstream system.
* **The credential stays out of band.** In the delegated path the token is used only on the server-side request to the provider; it is kept out of tool responses and out of the audit record, which stores the three identities but no credential bytes.
* **Person-present by design.** Delegated resolution is scoped to sessions where a person is present. A machine-to-machine caller with no acting user cannot drive a user-delegated tool; it fails closed.

***

## Three identities on every delegated call

The value of acting-as-you is only real if it is *provable* after the fact. Every user-delegated dispatch records three identities on its audit trail, with no credential material anywhere in it:

| Identity             | What it answers                                                                                        |
| -------------------- | ------------------------------------------------------------------------------------------------------ |
| **Person**           | Which Mediafier user acted.                                                                            |
| **Organization**     | Which tenant the action belongs to.                                                                    |
| **External account** | Which provider-side account the call ran as (the provider's own subject id for the connected account). |

Together these let a reviewer answer "*who* did *what*, in *which* organization, as *which* external account" — the complete picture an individually-scoped action requires. The three identities are recorded alongside the platform's standard tamper-evident audit; see [Audit, Observability & Compliance](/trust/audit-observability-and-compliance.md).

***

## Disconnecting

Because your grant is a single stored credential bound to you, removing it is decisive: if the delegated credential is removed or becomes unusable, subsequent calls fail closed as "not connected" until a valid credential is connected again. Provider-side revocation has the same effect — the next call cannot resolve a usable credential and stops before dispatch, rather than degrading to a shared or default credential.

***

## How it's billed

A user-delegated call runs on *your own* authorization to the upstream provider, so there is no platform-funded upstream vendor cost to mark up — no per-tool metered price applies. These connectors are **not free**, though: each call is charged a **flat facilitation fee** (the platform default is 0.1 credit per call), the same flat-fee model as bring-your-own-key connectors. Wherever a user-delegated connector's pricing is shown, you will see no per-tool price plus an explicit flat-fee disclosure — a charged surface is never presented as free. The platform's usual [Credits & Billing](/overview/credits-and-billing.md) model applies to the fee; the broader marketplace economics model is covered in [Provider Earnings & Marketplace Economics](/partners/provider-earnings-and-marketplace-economics.md) and is out of scope here.

***

## Where it fits

User-delegated authorization sits between the platform's identity boundary and its connector surfaces:

* [Identity & Authentication](/trust/identity-and-authentication.md) — how the gateway establishes *who you are* (the prerequisite for acting *as you*).
* [MCP Access](/connect/mcp-access.md) — pointing a harness at the gateway and reaching governed tools.
* [Gateway](/platform/gateway.md) — the enforcement chain that resolves identity, authorizes the surface, injects the credential, and audits the call.