# Roles

What each role and API key scope can do

Every workspace [member](https://splits.org/docs/members) has exactly one of two roles: **Owner** or **Member**. Roles are stored offchain, govern what a person can see and do in the app, and are scoped to one workspace: the same person can be an Owner of one workspace and a Member of another. A role never grants signing authority: approving transactions belongs to an account's onchain signer set, and the boundary is drawn at [Signers](https://splits.org/docs/accounts/signers#signers-vs-membership).

[Agent members](https://splits.org/docs/members#agent-members) hold the same two roles. A related surface (**API key scopes**) governs what programmatic clients can do; see [below](#api-key-scopes).

## What each role can do

| Capability | Owner | Member |
| --- | --- | --- |
| View accounts, balances, and transactions | ✅ | ✅ |
| Propose transactions from an account | ✅ any account | Only accounts they're a signer on |
| Sign transactions | Only if a signer on that account | Only if a signer on that account |
| Reject pending transactions | ✅ | Only if a signer on that account |
| Create new accounts | ✅ | ❌ |
| Edit account settings (name, signers, threshold) | ✅ | ❌ |
| Invite, remove, and change roles of members | ✅ | ❌ |
| Edit workspace name and logo | ✅ | ❌ |
| Toggle [*Require memos*](https://splits.org/docs/transactions/memos#requiring-memos) | ✅ | ❌ |
| Toggle [*Auto-earn for workspace*](https://splits.org/docs/accounts/earn#automated-earn) | ✅ | ❌ |
| Create invoices | ✅ | ❌ |
| Create and manage automations and schedules | ✅ | ❌ |
| Onramp / offramp | ✅ | ❌ |
| Entity verification (KYB/KYC) and payment info | ✅ | ❌ |
| Manage recovery | ✅ | ❌ |

## Read-only members

A member with the **Member** role whose signing keys aren't signers on any account is effectively read-only: they can see the workspace's accounts, balances, and transactions, but can't propose or sign any. (Owners can propose from any account, so read-only requires the Member role.)

To set one up, [invite them](https://splits.org/docs/members#inviting) with the Member role and don't add them to any account's signer set. Useful for accountants, auditors, and anyone who needs visibility without the ability to move funds.

## Settings visibility by role

| Settings section | Owners | Members |
| --- | --- | --- |
| General | ✅ | ✅ |
| Members | ✅ | ✅ |
| API Keys | ✅ | ✅ |
| Networks | ✅ | ❌ |
| Gas | ✅ | ✅ |
| Recovery | ✅ | ❌ |
| Tokens | ✅ | ❌ |
| Banks | ✅ | ❌ |

## API key scopes

API keys power the [CLI and MCP](https://splits.org/docs/introduction/agents). A key is created in [Settings > API Keys](https://app.splits.org/settings/team/api-keys/), or granted to an agent when a member approves its [browser login](https://splits.org/docs/introduction/agents#sign-in-from-the-browser). Either way it carries one or more scopes:

| Scope | Grants | Who can grant it |
| --- | --- | --- |
| `read` | List accounts, transactions, balances, and other workspace data | Any member |
| `write` | Read, plus propose transactions and update memos/properties | Any member |
| `owner` | Admin operations (manage accounts, automations, invoices, and workspace settings) | Owners only |

Scopes don't include each other: an operation that needs two (an off-ramp needs `write` and `owner`) needs a key granted both. A key acts as a member: the person who created it, or the [agent member](https://splits.org/docs/members#agent-members) it was granted to. Operations the table above reserves for Owners (creating accounts, automations, and invoices, off-ramping, changing signers and networks) also require that member to hold the Owner role, and off-ramps require the workspace's [entity verification](https://splits.org/docs/banking#getting-verified); granting an agent the `owner` scope at login makes it an Owner.

Like roles, API key scopes never grant onchain signing authority by themselves: signing programmatically requires a [registered EOA signer](https://splits.org/docs/introduction/agents#sign-locally-with-an-eoa) on the account.