> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.moveworks.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server.

# Roles and Permissions

Agent Studio uses two permission axes: editing and runtime. The UI bundles common combinations into four roles, so you can grant access in one step.

This page covers the roles and the permissions behind them.

This page covers per-asset roles, which control access to individual assets and folders. Workspace roles, such as Agent Studio Admin and Agent Studio Developer, control org-wide Agent Studio access. The per-asset **Developer** role and the workspace **Agent Studio Developer** role are not the same thing. For workspace roles, see [Manage roles and permissions for Moveworks applications](/service-management/administration/manage-roles-and-permissions-for-moveworks-applications).

## The Four Roles

When you grant access to an asset or folder, choose one of four roles.

<table>
  <thead>
    <tr>
      <th>
        Role
      </th>

      <th>
        What it grants
      </th>

      <th>
        Typical use
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        <strong>Manager</strong>
      </td>

      <td>
        Full control: run, edit, and manage access
      </td>

      <td>
        The asset owner or a folder administrator
      </td>
    </tr>

    <tr>
      <td>
        <strong>Developer</strong>
      </td>

      <td>
        Build, edit, and test the asset
      </td>

      <td>
        An active builder working on the asset
      </td>
    </tr>

    <tr>
      <td>
        <strong>Operator</strong>
      </td>

      <td>
        Run and reference the asset, but not edit it
      </td>

      <td>
        A consumer who runs or depends on the asset without modifying it
      </td>
    </tr>

    <tr>
      <td>
        <strong>Viewer</strong>
      </td>

      <td>
        Read-only
      </td>

      <td>
        A read-only observer
      </td>
    </tr>
  </tbody>
</table>

<img src="https://files.buildwithfern.com/moveworks.docs.buildwithfern.com/ba8d8ec68089d177ade5701e0a14b357c72a473095834ac9dafb7b95d1d12c43/docs/assets/images/agent-studio/access-control/role-picker.png" alt="Asset access role picker listing Manager, Developer, Operator, and Viewer roles" />

## The Two Permission Axes

Each role maps to editing access, runtime access, or both.

### Editing Axis (Authorship)

The editing axis controls who can read and change an asset's configuration and logic. Each level includes the levels below it:

`View` \< `Edit` \< `Manage`

* **View**: see the asset's definition and metadata.
* **Edit**: modify the asset's configuration and logic, publish it, and move it between folders.
* **Manage**: everything in Edit, plus delete the asset and change who can access it.

### Runtime Axis (Execution)

The runtime axis is a single permission:

* **Use**: run the asset, test it, view its execution logs, and reference it from another asset.

`Use` controls both build-time selection and runtime execution. Without it, you cannot pick the asset in a dropdown, run it, or test anything that would execute it.

### Why the Axes Are Independent

Editing and runtime answer different questions. Having one does not imply the other.

For example, a developer can have `Edit` on a Workday HTTP action. They can read and change the action's logic, but they cannot run it unless they also have `Use` on the action and the underlying Workday connector.

Teams can let more developers build while limiting execution to the right people.

`Use` decides whether a *developer* can run or test an asset while building. It does not control which *employees* can use a published plugin. For that, use [End-User Access Control](/agent-studio/access-control/end-user-access-control).

## How Roles Map to Axes

<table>
  <thead>
    <tr>
      <th>
        Role
      </th>

      <th>
        Editing
      </th>

      <th>
        Runtime
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        <strong>Manager</strong>
      </td>

      <td>
        Manage
      </td>

      <td>
        Use
      </td>
    </tr>

    <tr>
      <td>
        <strong>Developer</strong>
      </td>

      <td>
        Edit
      </td>

      <td>
        Use
      </td>
    </tr>

    <tr>
      <td>
        <strong>Operator</strong>
      </td>

      <td>
        View
      </td>

      <td>
        Use
      </td>
    </tr>

    <tr>
      <td>
        <strong>Viewer</strong>
      </td>

      <td>
        View
      </td>

      <td>
        None
      </td>
    </tr>
  </tbody>
</table>

## Permission Matrix

The table below shows what each role can do on a single asset.

<table>
  <thead>
    <tr>
      <th>
        Action
      </th>

      <th>
        Viewer
      </th>

      <th>
        Operator
      </th>

      <th>
        Developer
      </th>

      <th>
        Manager
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        View asset definition and metadata
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        See the asset name for reference
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Test or run the asset
      </td>

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Reference the asset in another asset
      </td>

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        View execution logs and analytics
      </td>

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Modify asset configuration and logic
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Publish the asset
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Launch a plugin to users
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Move the asset into a folder
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Export or import the asset
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Delete the asset
      </td>

      <td />

      <td />

      <td />

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Change the asset's access and sharing
      </td>

      <td />

      <td />

      <td />

      <td>
        ✅
      </td>
    </tr>
  </tbody>
</table>

Logs and analytics follow the `Use` permission. If you can execute an asset, you can see its execution data. Every user also needs a workspace-level Agent Studio role before per-asset permissions apply.

## What a Manager Can Do That a Developer Can't

Both roles can edit, publish, run, and reference an asset. Only a **Manager** can govern the asset itself:

* **Delete** the asset.
* **Change its access and sharing.**

To grant someone access to an asset, you need Manager on that asset. An admin can also grant access.

## Related

How folders set the default role for the assets inside them.

Why running an asset requires Use across its whole dependency chain.