Operate

A project contains one body of work inside a Mobius organization. Its agents, loops, runs, tables, files, secrets, integrations, and software credentials stay together.

Start with one project. Add another only when work should not share data, credentials, history, or access. Common splits are production and testing, or two teams that operate different systems.

Projects are not separate customer accounts. Organization Owners and Admins can access and administer every project. Organization membership, billing, and shared organization definitions also cross project boundaries. Use separate organizations when two companies need independent administrators, membership, or billing, or when one company's administrators must never access the other company's data.

Choose the boundary

Tags help people find projects. They never grant or remove access.

Most project-owned resources cannot be used from another project. A project API key is also tied to its project. A key created in ridgeline-prod cannot call a project route for acme-prod.

Some things still cross the boundary:

• Organization Owners and Admins can access every project.
• Organization settings, membership, and billing are shared.
• Organization actions and skills are definitions available across projects.
• An external account may be able to see more data than the Mobius project using it.

That last point matters when an integration or custom action connects to a shared external system. A Mobius project 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.

Control who can see a project

Open Settings > Access in the selected project. Every project has one access mode:

Organization Owners and Admins bypass both modes. A Restricted project cannot hide data from them.

Visibility and permission are different. Visibility decides whether an identity can reach the project. Roles decide what it can do after it gets there. Assigning a role also gives that identity visibility into a Restricted project.

Every ordinary organization Member receives the organization's Member project floor in each project they can see. An Owner or Admin sets that floor to Viewer, Operator, or Editor under Organization > General > Mobius settings. Project roles add permissions; they never subtract permissions from that floor. There are no deny roles.

If one person needs less access than the current floor, lower the organization floor and add project roles where broader access is needed. Removing a project role alone will not remove permissions that still come from the floor.

New projects inherit the organization's New project access setting. Changing that setting does not change existing projects. When you change an existing project from Org open to Restricted, the app asks whether current organization members should remain visible. Review the resulting member list before adding sensitive data.

Roles and permissions

A role is a named set of permissions. Assign roles to people, agents, or API clients inside one project. Multiple roles are combined.

The built-in project roles are:

Viewer is read-only, not data-free. Do not give it to a person or reporting service unless reading project resources and runtime output is appropriate.

Organization standing uses the names Owner, Admin, and Member. That is separate from a role assigned inside one project. A project role named Admin does not make a person an organization Admin.

The app supports built-in and project-specific roles. Use the access-control API to inspect the current permission catalog or create a custom role when none of the built-in roles fits.

API clients and API keys

An API client is the project 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.

Prefer a project key for software that uses one project. Organization keys act across projects and are intended for trusted cross-project administration. Create them under Organization > API Keys only when project-specific clients would not work.

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 a project 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 Settings > Audit Logs for one project or Organization > Audit Logs for a cross-project view. Each audit 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.

Create and manage a project

You need organization Owner or Admin standing to create a project.

1. Open Projects and click New project.
2. Enter a name. Add a description or tags only when they help other operators recognize the boundary.
3. Click Create project.
4. Open Settings > Access and confirm the access mode before adding data, integrations, or credentials.

Mobius creates an immutable URL handle from the name. For example, Ridgeline Prod becomes ridgeline-prod. Use that handle in CLI commands and project API routes. Renaming the project later does not change it.

Software that provisions projects for another system should use a stable external_ref and verify the returned project before adding data. See Provisioning for the API contract and conflict rules.

Project-owned resources cannot be moved to another project. Recreate and verify them in the destination before archiving the original under Settings > General > Danger zone. Archiving blocks new work and removes the project from the normal list; it does not erase retained history.

Next

• Create a project API key.
• Manage custom roles with the access-control API.
• Provision projects from software with Provisioning.
• Inspect execution and recovery in Runs.