> For the complete documentation index, see [llms.txt](https://docs.sail.money/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sail.money/protocol/concepts/roles.md).

# The three roles

Sail separates three roles that exist implicitly in any managed-account structure. Keeping them distinct is what lets an agent transact without ever being able to take custody or rewrite its own mandate.

| Role                  | Authority                                                                                                          | Held by                                           | Code identifier                  |
| --------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------- | -------------------------------- |
| **Owner**             | Holds the Safe. Custodies the SMA's capital. Always self-custodial. Can always revoke the manager.                 | The LP, who owns the Safe.                        | the Safe's own owners/threshold  |
| **Permission Signer** | Authorizes the mandate. Signs registration, configuration, replacement, and revocation of permissions via EIP-712. | The Owner, or a separate signing key or multisig. | `AccountConfig.permissionSigner` |
| **Manager**           | Executes transactions within bounds. Cannot exceed what the registered permissions allow.                          | EOA, multisig, MPC wallet, or autonomous agent.   | `AccountConfig.manager`          |

These three are stored per account in the kernel's `AccountConfig` (alongside the `feePolicy`, the canonical `feeAsset`, and the `sessionActive` flag).

## What each role can and cannot do

* The **Owner** controls the Safe and its assets directly, through the Safe's own threshold. The kernel reads custody from the Safe; it never holds funds. The Owner can rotate the manager (see below) and can remove the kernel module entirely.
* The **Permission Signer** decides *what the manager may do* by signing permission-registry operations. It **cannot move assets** — it never signs a dispatch.
* The **Manager** decides *which authorized action to take, and when*, by signing dispatches. It **cannot register or revoke permissions**, and it **cannot exceed** any registered permission's bounds.

This separation is a security property: a compromised manager key cannot widen its own mandate, and a compromised permission-signer key cannot move funds.

## The submitter is not a role

The address that pays gas and submits the manager's signed dispatch is **not** an authority. Any address may submit a dispatch; authority derives entirely from the manager's signature, the registered permissions, and the kernel's evaluation. This makes Sail natively compatible with relayers, paymasters, and ERC-4337 bundlers. The permission can still read `ctx.submitter` and gate on it if it chooses.

## Retail vs. institutional setups

* **Retail:** all three roles collapse to one key or wallet. The owner deploys a Safe, registers permissions as Permission Signer, and signs dispatches as Manager.
* **Institutional:** the roles separate. A fund firm holds the Manager key; an independent compliance officer or the client holds the Permission Signer key and controls what the manager can trade; the Safe signers (Owner) retain custody and can always revoke.

## Manager rotation

The Safe itself (`msg.sender == account`) can rotate the manager via `setManager(newManager)`. Rotation **clears every registered permission atomically** — no mandate silently transfers authority approved for the old manager to a new one — and bumps the manager nonce epoch so any dispatch the old manager pre-signed is invalidated. The owner re-approves each mandate for the new manager through the normal registration flow.

Next: how those permissions form a [mandate](/protocol/concepts/mandate.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.sail.money/protocol/concepts/roles.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.