Operate

An organization is one Mobius tenant. Its agents, 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.

Standing in the organization

Every person in the organization has one standing:

Invite people and change standing under Organization > Team.

Every ordinary Member also receives the organization's Member permission floor. An Owner or Admin sets that floor to Viewer, Operator, or Editor under Organization > General > Mobius settings. Roles add permissions on top of the floor; 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, agents, or API clients. Multiple roles combine.

The built-in roles are:

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 is a small permission ladder. mobius.org.view is the floor; mobius.org.run and mobius.org.edit each imply it and are independent of each other; mobius.org.admin implies all three. Admin is deliberately not implied by edit, so someone who can build things cannot widen their own access. Two permissions sit outside the ladder: mobius.agent.invoke for sending messages to agent sessions, and mobius.work.execute for the worker protocol.

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 agent

Roles decide what someone may do with the resources they can see. A single agent 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 agent 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 agents 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:

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:

Open Organization > 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.
• Understand private, shared, and team resources in Your work and the team's work.
• Give agents stable identities from software with Provisioning.
• Read what an agent actually did in Agent sessions.