Guides
Members & roles
Bring your colleagues into your organisation and give each the right level of access. Roles split building work from deciding on it, so you can put a real human check between an agent's proposal and the outside world.
Inviting members
Go to Settings → Members, enter a colleague's email, choose a role (Viewer by default), and send the invitation. They receive an email with a link:
- New to SyftOS? They create an account with that email address and verify it, then accept the invitation — so a new teammate always ends up with their own account, never a shared login.
- Already have an account? They simply sign in with the invited address and accept.
Invitations expire after seven days; send a fresh one if it lapses.
The five roles
Rather than one long ladder, the roles separate building from deciding:
- Viewer: read-only. Sees agents, runs and approval requests; changes nothing.
- Operator: the builder/runner. Creates and edits agents, runs agents and workflows, and manages documents and memory. Doesn't decide approvals; publishing, integrations and member management are Admin-level.
- Approver: the decision-maker. Reviews and decides approval requests and sees the audit log. An oversight role: it can view agents and runs but isn't a builder.
- Admin: everything Operators and Approvers can do, plus publishing and archiving agents, managing tools, workflows, integrations, triggers, governed repositories and members.
- Owner: full control, including billing and organisation settings.
Changing & removing
From the Members list an admin can change anyone's role at any time, and remove a member when they move on. A few safeguards:
- You can have as many Owners and Admins as you like — but you can't remove or demote the last Owner; make someone else an Owner first.
- Removing a member ends their access to this organisation only. Their SyftOS account and their place in any other organisation are untouched.
If your organisation signs in through SSO, members are provisioned, suspended and reinstated automatically by your identity provider. There's nothing to manage by hand here.
Segregation of duties
Under Settings → Organisation there's a "Separate proposer and approver" setting, on by default. With it on, the person who started a run cannot approve that run's actions — the decision controls are hidden for them, with an explanation, though they can still see the request. That guarantees a genuine second pair of eyes on everything an agent proposes.
For Code Governance the rule is stronger and always on: whoever authored or triggered an AI-written change can never be the one who approves it. See Code Governance.