Managing access

Each connected vendor has an Access editor on its connection card. From there you set, in one place, who can use the vendor and at what level — and, if you need it, exactly which tools.

Availability and enforcement

The Access editor is available on Conduit deployments where access-grant management is enabled. On those deployments the grants you set here are exactly what the gateway enforces on every tool call — what the card shows is what’s enforced. Where it is not enabled, access is governed by your organization’s existing server-access and tool-allowlist controls. Your Conduit operator can confirm which applies to your deployment.

Read, Write, Delete, and Admin

The Access editor shows each grantee’s access as four checkbox groups — Read, Write, Delete, and a fourth, visually de-emphasized Admin — each with a “select all” checkbox and a collapsible list of the vendor’s individual tools in that group.

Group	Grants
Read	Read-only tools — list, get, search.
Write	Everything Read can do, plus tools that create or update data. Delete is a separate permission — Write no longer folds it in.
Delete	The write tools whose name implies deleting something (delete, remove, dismiss, archive). This is a display grouping only — these tools still enforce at the Write level; there’s no separate “delete” enforcement tier.
Admin	Everything Write and Delete can do, plus the vendor’s administrative tools — credentials, configuration, raw API access.

Check a group’s master checkbox to grant everything currently in it, or expand its tool list to hand-pick individual tools — checking any individual tool clears that group’s master checkbox, since a hand-picked selection is no longer “everything in the group.” Leave every checkbox unchecked for no access at all.

Each row’s footer summarizes the current selection — e.g. “Read + Write, no delete — 87 tools” — or “Custom access — N tools” once you’ve hand-picked specific tools instead of whole groups.

Delete is a grouping, not a new enforcement level

Under the hood the gateway still only ever enforces read, write, or admin on a tool call. Checking Delete without Write is allowed, but it grants access to only the delete-classified tools — not the vendor’s other write tools — because the underlying grant is stored as tier write narrowed to that exact tool list.

Read, Write, and Admin form a ranked chain — a higher tier includes everything below it (read < write < admin). A tool that isn’t classified yet depends on the server. On a catalog server WYRE runs, that tool is still usable: read-only when the server describes it as read-only, off until an admin enables it when the server describes it as something that deletes or overwrites data, and write when the server has not described it. On a catalog server the vendor builds and supports, a tool the server has described follows that description, and a tool the server has not described stays off until an admin grants Write or Admin. On any other server — a custom URL, a server you bring, or a hosted server that is not on that list — an unclassified tool still requires admin. A tool that is already classified uses that classification.

Set who can use a vendor

Start with the default for the whole connection: open Everyone’s row and check the groups you want every member to have. For many connections, checking just Read’s master checkbox is all you need.

Exceptions — per member or per team

To give specific members or teams a different level, add an exception: pick a member or a team, then check the groups you want them to have — Read, Write, Delete, Admin — or expand a group to hand-pick individual tools.

To revoke what the default would otherwise grant, uncheck every box for that member or team — the row’s footer reads “No access — 0 tools”. For example, if the default gives all members Read, unchecking every box on one team’s exception row takes Read away from just that team.

New member overrides start at Read — adjust from there using the same checkbox editor.

How exceptions resolve

The most specific grant wins:

• a member exception overrides a team exception overrides the all-members default.
• The most-specific level’s checkboxes apply as-is; nothing checked there means no access, even if a broader default would otherwise grant it.
• If a member qualifies through two teams at the same level with different selections, the highest tier applies — access is additive, never a silent downgrade. Their tool allowlists at that level are combined (union).
• If nobody has been granted access and there is no Everyone default, there is no access, except on a catalog server WYRE runs or a catalog server the vendor builds and supports. Those start on for everyone (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. A hosted server that is not on that list has no access until you grant it. Setting Everyone to No access still wins.
• The editor’s persistent Check a member’s access panel states this rule directly: “Most specific wins: member override > team > organization default. Owners always have full access.”

Service accounts count as team members too. Add a service account to a team from the Teams page, and it resolves access through the same chain as a human member: an explicit grant on the service account wins, then its team memberships, then the all-members default. An explicit No access grant on the service account is still authoritative.

A new service account starts with no explicit grants, so it resolves exactly like a new member: on each vendor it gets the Everyone default — which may be No access — until you add it to a team that has a grant on that vendor, or add an override for it from the editor’s add-override picker (service accounts are listed under their own heading). If your Everyone rows are permissive, scope the account before you hand out its credentials. Its overrides live in the editor’s Service accounts section, with the same checkbox editor and ✕ Restore inherited chip as a member override. The one exception is a Microsoft 365 Copilot connector client, which is created with Read on every vendor connected at that moment — see the Copilot guide.

Service accounts created before September 2026 that were never scoped still carry an Admin override per vendor

Earlier releases seeded every new service account with an explicit Admin grant on each vendor connected at the time. Because an explicit grant is the most specific level, that row outranks any team grant — the account keeps full access no matter what its team allows. The September 2026 release removed those seeded rows from every account that was already in a team, or whose org has an all-members default for the vendor, so those accounts now follow their teams or the default. An account that was in no team and had no default was left as it was, so it keeps working. When you scope such an account later, its Admin rows appear under Service accounts in the vendor’s Access editor: click ✕ Restore inherited to remove the override, or narrow it with the checkboxes, and the team grants apply.

Restrict to specific tools

By default, a group’s master checkbox grants every tool currently in it. To narrow it, expand the group’s tool list and check only the specific tools you want to allow — checking any individual tool clears that group’s master checkbox, and the row’s footer switches to “Custom access — N tools.”

A hand-picked selection is a snapshot: it won’t automatically include a tool the vendor adds later — the editor flags this with a note under the selection (“A custom selection won’t auto-include tools this vendor adds later — re-save to refresh it”). A grant that already had a specific tool list — whenever it was set — shows up the same way: plain checked/unchecked tools, fully editable, with no “legacy” marker.

Check a member’s access

Every connection’s Access editor includes a persistent Check a member’s access panel. Pick any org member and it resolves their effective access through the exact same logic the gateway uses on every tool call, then shows why: each rule evaluated, which one decided the answer, and — for someone with an explicit override — what they’d fall back to without it.

The panel ends with the rule that governs every resolution: “Most specific wins: member override > team > organization default. Owners always have full access.”

Personal connections: requesting write access

Everything above governs org-shared connections through the Access editor. A personal connection — your own individual credential to a vendor, set up from /org/catalog or /settings/profile — works differently: it’s either Read-only or Read & write, and there’s no grant resolver or per-tool list to configure. See Vendor connections for what a personal connection is and how to create one.

On your connected vendor’s card, the tier shows as a badge (Read-only or Read & write) alongside a button:

• Make read-only — always self-serve. Drop your own connection back to read-only any time.
• Enable write access — self-serve, if your organization doesn’t require approval for this.
• Request write access — if your organization requires approval. Filing a request emails your org’s admins and owners, and the button is replaced with Approval pending until an admin decides.

There’s no separate action to cancel a pending request — it resolves when an admin approves or denies it.

For admins: approving requests

Pending requests appear on the Policies modal, opened from /org/members, under Pending access requests — one row per request, with the requesting member, the vendor, when it was filed, and Approve / Deny buttons. Approving flips the member’s personal connection to Read & write immediately; denying leaves it Read-only. Neither decision sends an email — the requester finds out by checking their own connection’s tier.

Admins and owners also get a passive heads-up: a bell icon with a pending-request count appears in the top nav once there’s at least one open request (access or member-join). It polls in the background and only shows for org admins/owners.

Turning off the approval requirement

The same Policies modal has a Permission changes require admin approval checkbox, under Member defaults. Unchecked, members can flip their own personal connections to Read & write immediately — no request, no approval, no admin email. The modal’s Individual connection default access setting controls the tier a new personal connection starts at (Read-only or Read & write), separately from this escalation-approval toggle.

Reseller: managing a customer’s access

As a reseller admin, you manage a customer organization’s access by switching into it: from Customers (/org/customers), click Manage on the customer’s row. This puts you into acting-as mode on the customer’s own organization — you land on their /org pages and use the same Access editor described above, scoped to their connections (/org/catalog). You must be a reseller admin who owns the customer; every access-grant change you make while acting-as is recorded in the customer’s audit log, attributed to you as the real actor.

Where to find it

The Access editor lives on each connection card under Connections (/org/catalog).

• Permissions — the underlying role and permission model.
• Vendor connections — connecting a vendor before setting access.
• Subtenant model — how access works across reseller and customer orgs.