Permissions

Conduit decides “can this caller invoke this tool?” with one resolver, evaluated the same way for every identity on every route. This page documents that model — the org-member roles, the access-grant tiers, the exact precedence order, and the two things people most often get wrong: only owners bypass access controls (admins do not), and individual (BYOC) credentials never bypass org policy.

Two related pages go deeper on adjacent topics:

• Subtenant Model — the reseller → customer hierarchy and transitive admin.
• Security — credential isolation, tenant boundaries, and the audit log.

---

Two role spaces

Conduit has two disjoint role systems. A role in one space grants nothing in the other.

• Org-member roles — owner / admin / billing / member. Every organization has them. They govern who can manage that organization.
• Reseller-scope roles — reseller_owner / reseller_admin / reseller_billing_viewer / reseller_support_agent. These exist only on reseller organizations and govern authority down the customer hierarchy. See Subtenant Model § Two role spaces.

Org-member roles

Role	Rank	What it can do
owner	highest	Everything admin can do, plus change other members’ roles, transfer ownership to another member, and delete the organization. Owners also bypass all vendor/tool access controls — see below. The owner cannot be removed or demoted through the API.
admin	middle	Manage members (invite and remove), vendor connections, teams, access grants, and org settings. Can export the audit log. No billing access — admin is deliberately excluded from the subscription, invoices, and the Stripe portal, same as it’s excluded from bypassing access controls. Admins are subject to access grants and tool allowlists like any member — managing access and having access are different things.
billing	lowest for tool access, owner-level for billing	A delegated finance seat (bookkeeper, office manager, CFO) — manages the subscription and agreement, invoices, the invoice recipient, and the Stripe billing portal, with the same billing authority as the owner. Has no management capability and no elevated tool access — for vendor/tool access purposes billing is treated exactly like member.
member	lowest	Call the vendor tools their effective access permits. Read access to the org they belong to. No management capability.

A user’s role is per-organization. New users invited to an org join as member; promotion to admin or billing is an explicit, owner-only action.

Member-management guardrails

• Admins cannot remove other admins. Removing an admin is owner-only.
• Only the owner can change roles, including assigning or revoking billing. Admins cannot change roles at all.
• The owner is protected. The owner cannot be removed and the owner’s role cannot be changed through the API.
• You cannot change your own role. Even the owner.
• Ownership can be transferred. The owner can promote an existing member to owner; the previous owner becomes admin in the same action. See MSP Onboarding § Common operations.

All member-management and access-grant actions are written to the admin audit log — see Security § Audit Logging.

How tool-call access is decided

For a caller in an org context, every tool call is decided in this order, evaluated identically by the unified /v1/mcp router, the per-vendor /v1/:vendor/mcp router, the CLI router, the aggregated /mcp router, and the on-prem tunnel fork:

owner bypass → effective vendor tier (most-specific-wins: member > team > all_members; explicit deny is authoritative) → tool narrowing (per-grant custom tools; folded legacy allowlists during the migration window) → service/billing gate.

All of these must pass for a call to succeed — they combine with AND. The order above is the logical model for reasoning about why a call is allowed or denied; internally the checks run in a fixed sequence and the first one that fails determines the exact denial reason a client sees, so a single call can be blocked by only one of them at a time.

What’s live today

The tiered access-grant model below is the live enforcement path in production — not a preview of where enforcement is heading. The connection access panel reads and writes real grants, and those grants are the same data the resolver checks on every tool call:

• Live now: owner bypass, effective vendor tier (most-specific-wins across member/team/all_members grants, with explicit deny authoritative), per-tool tier classification (a caller’s tier must meet the specific tool’s required tier, not just clear the vendor-level bar), a grant’s custom_tools allowlist, and the legacy per-role tool allowlist (still AND-composed with grant tool lists during the migration window).
• Not yet enforced: the service/billing gate — a past-due org is not yet blocked from tool calls on this path. This is the one step in the sequence below that is not live.

The panel’s tools-by-tier detail is not aspirational — it reflects exactly what the resolver enforces on the next tool call, with the single exception of the billing gate above.

1. Owner bypass (owners only)

Org owners always resolve to full access (tier admin, all tools). This is the only role-based bypass. Admins do not bypass anything — an admin can be denied by a grant or narrowed by a tool list exactly like a member.

2. Effective vendor tier — access grants

Access to each connected vendor is controlled by access grants. A grant names who (the grantee), how much (a tier), and optionally which tools.

Tiers form a strict chain: none < read < write < admin. none is an explicit, representable deny. The live gate checks that a caller’s effective tier is at least read to reach a vendor at all, and that the tier meets each specific tool’s required tier. A classified tool uses its classified tier. An unclassified tool on a catalog server WYRE runs follows how that server describes the tool: something that deletes or overwrites data needs Admin, a read-only tool needs Read, and a tool the server has not described needs Write. An unclassified tool on a catalog server the vendor builds and supports follows a description the server has given, and a tool the server has not described stays off until an admin grants Write or Admin. An unclassified tool on any other server needs Admin.

Grantee levels, most-specific first:

1. member — one specific user,
2. team — every member of a team,
3. all_members — everyone in the org.

Resolution is most-specific-wins. The most specific level that has any applicable grant decides — resolution does not fall through to a broader level. That makes an explicit member-level deny (tier: none) authoritative: a broader all_members: admin grant cannot override it.

Within a single level (a user in several granted teams), grants combine: the tier is the MAX, and the tool lists UNION (an unrestricted grant — no tool list — wins).

No access until you grant it, with a floor for catalog servers someone else runs: no applicable grant at any level means no access, except on a catalog server WYRE runs or a catalog server the vendor builds and supports. Those start with access for everyone when no row exists: read and write, or read only if WYRE has set this deployment that way. A server that moves money or sends email or messages starts read-only. An admin can allow changes. A tool that isn’t classified yet, and that the server describes as deleting or overwriting data, stays off until an admin grants Admin. On a catalog server the vendor builds and supports, a tool the server has not described stays off until an admin grants Write or Admin. On a catalog server WYRE runs, a tool the server has not described needs Write. A tool that is already classified uses that classification. An explicit row always wins, including Everyone set to No access. Clearing Everyone stores No access so the default does not come back. A server you connect yourself — a custom URL, or one you bring — and a hosted server that is not on that catalog list have no floor.

3. Tool narrowing

A grant may carry a custom tool list — the grantee can then only call those tools (within what the tier already permits). This is how you keep credential-retrieval and delete-class tools away from callers who don’t need them. This is enforced today.

Custom tool lists are a normal, first-class editor state, not a legacy holdover: the grouped Read/Write/Delete/Admin checkbox editor creates one any time a selection doesn’t match a whole-group shape — a partial group, a hand-picked subset, or Delete checked without Write. There’s no “legacy” marker on these lists; they’re plain, fully editable checkbox state either way.

Legacy per-role tool allowlists still apply and AND-compose with grant tool lists (both must permit the tool). They are being folded into grants and will be retired.

4. Service/billing gate

An org whose subscription is past the dunning grace window is blocked at this final gate. This gate is not yet enabled — a past-due org is not currently blocked from tool calls on this path. It is the one enforcement step that is not live; every other step above is enforced today.

Every identity, same rules

Identity	Org context	Policy
Human, org member	their org	full gate sequence above
Human, no org	none	individual connections only; no org gates apply
Service client (svc: token)	baked into the token	same precedence humans use — an explicit service_client grant wins, then the client’s team memberships, then all_members; an explicit service_client: none grant is still authoritative (most-specific-wins)
On-prem tunnel call	resolved org	same gate sequence as cloud — vendor tier checked
Platform admin	n/a	separate operator plane; never composes with org permissions

BYOC does not bypass policy. When a member calls tools in an org context, the org’s gates apply regardless of whose credential is used. An individual (bring-your-own) credential selects which API key is injected — never which policy applies.

Seeing and editing access — the connection access panel

Access is read and edited per connection, on Connections → “Edit access”. The panel shows grouped Read / Write / Delete / Admin checkboxes per grantee — the org default (“Everyone”), each team, then any member overrides — plus a read-only tools by tier listing (what Read/Write/Admin actually include for that vendor) and a persistent “Check a member’s access” section, which resolves one member through the same resolver that decides every tool call and prints the “why” trace: the exact grant, override, legacy-allowlist row, or no-access default that produced the answer.

The Access Matrix page is removed

The member/team × vendor grid at /org/access has been removed — it grew unreadable at real org sizes. /org/access now redirects to the Catalog (/org/catalog), Conduit’s single connections surface. Everything it did (effective tier, why-trace, editing) lives in the per-connection panel above.

Edits take effect immediately in the grant data and are audit-logged, and per-tool enforcement of those edits is live on the very next tool call — see the note above.

Resellers manage a customer’s access from the customer’s own Connections page, which requires entering customer context (“Manage on behalf of”); every on-behalf change is audit-tagged with the acting-as identity.

Tool naming

Tool names must let an admin infer the tier a tool requires — read the name, know the blast radius:

Tier	Meaning	Typical name tokens
Read	Search and view data. Get, list, and search tools only.	get, list, search, check, status
Write	Everything in Read, plus create, update, and delete records.	create, update, delete, set, resolve
Admin	Everything in Write, plus credentials, configuration, and raw API access.	raw, execute, credential, offboard

A CI guard (src/access/tool-naming.guard.test.ts) compares every classified tool’s name against its declared tier and fails on unexcepted mismatches. Pre-existing oddballs are grandfathered in src/access/tool-naming-exceptions.ts with per-tool justifications; new tools must conform or ship with a justified exception.

Connection scoping (credential resolution)

Independent of permission, a vendor credential can be stored at user, team, or org scope; resolution picks the most specific credential available to inject. This affects only which API key is used — see Security § Credential Resolution Hierarchy. Permission is always decided by the resolver above.

Reseller-scope roles

Reseller organizations carry an additional, disjoint role space. These roles do not grant org-member authority — a reseller_admin is not automatically an admin on a customer org.

Reseller role	What it grants
reseller_owner	Top-level authority over the reseller’s entire customer estate, including managing all reseller member roles.
reseller_admin	Administer customers and their sub-customers transitively. Cannot touch reseller_owner rows or elevate anyone to owner.
reseller_billing_viewer	Read-only access to billing data across the reseller’s estate.
reseller_support_agent	Read-only; can act on a customer only through a short-lived, audit-logged support grant.

The mechanics are covered in full in Subtenant Model.