Organizations and access
Set up the company boundary, then authorize people, assistants, and software for the work they should do.
An organization is one Mobius tenant. Its assistants, sessions, routines, tables, files, integrations, and software credentials stay together, and every person and every piece of software that works in Mobius does so inside one organization.
Use separate organizations when two companies need independent administrators, membership, or billing, or when one company's administrators must never reach the other company's data. Everything short of that is a question of roles, not of tenants.
Some things need a narrower boundary than the organization itself:
- An external account may be able to see more data than the Mobius organization using it.
- A person can keep work private, share it while remaining responsible for it, or hand it to the team. Organization administration does not grant a hidden read into private conversations and output.
That first point matters when an integration or custom action connects to a shared external system. Mobius does not reduce the permissions of an OAuth grant or API key in that system. Configure the external account to return only the intended data, or enforce the customer boundary in the service that receives the request.
Keep account access separate
An organization can know that a Gmail account is connected without giving every assistant the mailbox. The account has one manager: the person who connected it, or the team. That manager chooses which assistants may use the exact account and which Mobius conversation or routine audiences may retain the returned tool result.
Organization administrators can manage a team connection without gaining a hidden way to read its provider content. A person's connection remains theirs, and only that person's Mobius audience may use it and retain its tool results, even when the assistant is shared. This result audience does not inspect an external recipient, channel, or other destination supplied to an action.
An assistant also needs the right role and tool before it can act through an account. These checks solve different problems. Read Connect accounts for the complete connect and access flow.
Standing in the organization
Every person in the organization has one standing:
| Standing | What it means |
|---|---|
| Owner | Governance. Only Owners delete the organization or grant, revoke, and demote Owner access |
| Admin | Day-to-day administration of settings, membership, access, and team resources, plus billing reads |
| Member | Ordinary use of the organization, shaped by the default member access and any assigned roles |
Invite people and change their standing under Settings > Team.
Every ordinary Member also receives the organization's Default member access. An Owner or Admin sets it to User or Viewer under Settings > General. Roles add permissions on top of that default; they never subtract from it. There are no deny roles.
If one person needs less access than the current floor, lower the floor and add roles where broader access is needed. Removing a role alone will not remove permissions that still come from the floor.
Roles and permissions
A role is a named set of permissions. Assign roles to people, assistants, or API clients. Multiple roles combine.
The built-in roles are:
| Role | Use it for |
|---|---|
| Owner | Full control of the organization, including billing and Owner access |
| Admin | Use and build resources, administer the organization and team resource posture, read billing, and execute actions |
| User | Work, chat, automate, and build configuration under the person's own eligible custody |
| Worker | A machine identity that reads organization context, claims work, and executes actions |
| Viewer | Read reachable resources without using or changing them |
Viewer is read-only, not data-free. Do not give it to a person or reporting service unless reading shared resources and runtime output is appropriate. A role never opens another person's private conversation or output.
Underneath the roles, mobius.resource.view is the floor.
mobius.resource.use and mobius.resource.build each imply view but are
independent of each other. mobius.org.admin implies all three resource
permissions. Billing, the worker job protocol, and action execution are separate
permissions, so a custom role can grant one without silently granting the
others.
Create a custom role under Settings > Access when none of the built-in roles fits. Use the access-control API to read the live permission catalog or manage roles from software.
Narrow who can reach an assistant
Roles decide what someone may do with the resources they can see. A single assistant can also be narrowed to a few named people or to one person, so a team's accumulated knowledge stays with that team. See Who an assistant is for.
Resources themselves also say who is responsible for them and whether they are private, shared, or owned by the team. See Your work and the team's work.
API clients and API keys
An API client is the identity for software you operate, such as a backend, CI job, script, or self-hosted worker. Mobius creates other software identities for assistants and managed workers; you do not create another API client for those.
Create a separate API client whenever two processes need different permissions, separate audit attribution, or the ability to be disabled independently. Production and testing should not share one. Replicas of the same deployment may share one client when they have the same access and lifecycle.
Three records work together:
| Record | What it answers |
|---|---|
| API client | Which software is acting? |
| Role assignment | What may that software do? |
| API key | Which secret did it use to authenticate? |
One API client can have several keys. This lets you create a replacement key, deploy it, verify it, and then delete the old key without changing the client's identity or roles.
Mobius shows the full mbx_... key only once. Put it in the deployment's
secret manager immediately. Never put a key in browser or mobile code, source
control, URLs, logs, tickets, or screenshots. Anyone with the full token can act
with its authority until the key expires or is deleted.
Use Create an API key for the app and CLI steps. For routine rotation, create and deploy a second key, verify every deployment uses it, wait through the longest scheduled or offline interval, then delete the old key. If a key may be leaked, delete it immediately instead of allowing an overlap. Disable the API client when you need to stop all of its keys at once.
Audit changes
Use two different records for two different questions:
| Question | Open |
|---|---|
| Who changed access, credentials, integrations, or other configuration? | Audit logs |
| What did an assistant do while it worked? | The session transcript |
Open Settings > Audit logs. Each entry identifies the acting person or software, the credential when one was used, the affected resource, the time, and a redacted summary of the change.
Audit entries are append-only. Mobius does not offer an operation to edit or delete an individual entry. Use the filters to narrow an investigation by time, resource, action, or actor. An audit entry proves that Mobius recorded a change; it does not by itself prove why the change was made or satisfy a specific compliance requirement.
Next
- Create an API key.
- Manage custom roles with the access-control API.
- Connect accounts and grant assistant access with Connect accounts.
- Understand private, shared, and team resources in Your work and the team's work.
- Give assistants stable identities from software with Provisioning.
- Read what an assistant actually did in assistant sessions.