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

# Access Control

> **Controlled availability**
>
> Access Control is currently in Controlled Availability and may not be available in every workspace.

Agent Studio has two layers of access control:

<table>
  <thead>
    <tr>
      <th>
        Layer
      </th>

      <th>
        Question it answers
      </th>

      <th>
        Who it governs
      </th>

      <th>
        Where to configure
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        **Developer access**

         (this section)
      </td>

      <td>
        Who on my team can see, edit, and run the assets I build?
      </td>

      <td>
        Developers and admins working inside Agent Studio
      </td>

      <td>
        Roles, folders, and item-level permissions
      </td>
    </tr>

    <tr>
      <td>
        **End-user access**
      </td>

      <td>
        Who in my company can use the plugin once it ships?
      </td>

      <td>
        Employees chatting with the assistant
      </td>

      <td>
        [Launch rules and access strategies](/agent-studio/access-control/end-user-access-control)
      </td>
    </tr>
  </tbody>
</table>

This section covers the first layer: **role-based access control (RBAC)** for people building in Agent Studio. [End-User Access Control](/agent-studio/access-control/end-user-access-control) is separate. It controls which employees can use a published plugin.

> **Two layers, two purposes**
>
> A permission like **Use** controls whether a *developer* can run or test an asset while building. It does **not** decide which *employees* can use the resulting plugin. Use [launch rules](/agent-studio/access-control/end-user-access-control) for that.

## Why Access Control Matters

Before RBAC, every developer in a workspace could see, edit, and publish every plugin, action, and connector. As teams grow, two risks show up:

* **Sensitive connectors are open to everyone.** A connector to Workday, a finance system, or an HR backend is reachable by any developer, even ones who shouldn't touch that data.
* **Live plugins are easy to break.** A developer on one team can edit a widely-used, already-published plugin owned by another team.

Access control lets you choose which developers can reach which assets. You can keep sensitive connectors limited to the right people and protect published work from accidental edits.

> **Day 1 experience with access control**
>
> When access control is enabled, existing assets, including connectors, move to the Public folder. Everyone in the workspace can see and use Public assets, which matches the previous behavior. Admins can then move sensitive assets into restricted folders.

## How Access Control Works

### 1. Assets

An **asset** is any buildable component in Agent Studio: a plugin, action, connector, conversation process, or data type. Access control applies to assets. Connectors have a few extra rules, covered on [Connectors and Access](/agent-studio/access-control/connectors-and-access).

### 2. Folders

Every asset lives in exactly one **folder**, and the folder sets the default access for everything inside it. There are three kinds:

* **Public**: visible and usable by everyone in your workspace.
* **Personal**: your workspace for drafts and in-progress work. Each user has one.
* **Custom**: admin-created folders with their own access rules, such as "HR Integrations" or "Finance Automations."

See [Folders](/agent-studio/access-control/folders) for how inheritance and overrides work.

### 3. Permission Axes

A user's access to an asset has two independent axes.

```mermaid
graph LR
    subgraph Editing["Editing axis: authorship"]
        V[View] --> E[Edit] --> M[Manage]
    end
    subgraph Runtime["Runtime axis: execution"]
        U[Use]
    end
```

* **Editing** controls whether a developer can view, edit, or manage an asset's configuration. It cascades: `View` \< `Edit` \< `Manage`.
* **Runtime** controls execution through one permission: **Use**. Use lets a developer run, test, and reference an asset from another asset.

These axes are independent. An editing permission does not grant runtime, and runtime does not grant editing. For example, a developer can have `Edit` on a Workday action so they can update its logic, but still lack `Use`, which would let them fire real API calls with real credentials.

The Agent Studio UI bundles these axes into four named roles so you don't configure each axis by hand. See [Roles and Permissions](/agent-studio/access-control/roles-and-permissions).

## Where to Go Next

#### [Roles and Permissions](/agent-studio/access-control/roles-and-permissions)

The four roles, the two permission axes, and what each role can do.

#### [Folders](/agent-studio/access-control/folders)

How Public, Personal, and Custom folders set and inherit access.

#### [Connectors and Access](/agent-studio/access-control/connectors-and-access)

Why connectors are closed by default, and how dependency-aware execution works.

#### [End-User Access Control](/agent-studio/access-control/end-user-access-control)

The other layer: controlling which employees can use a published plugin.

## Glossary

<table>
  <thead>
    <tr>
      <th>
        Term
      </th>

      <th>
        Definition
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        **Asset**
      </td>

      <td>
        Any buildable component in Agent Studio: a plugin, action, connector, conversation process, or data type.
      </td>
    </tr>

    <tr>
      <td>
        **Folder**
      </td>

      <td>
        A container that holds assets and defines their default access. Public, Personal, or Custom.
      </td>
    </tr>

    <tr>
      <td>
        **View**
      </td>

      <td>
        A filtered lens over assets you already have access to (for example, 

        `Shared with me`

        ). A view does not grant access on its own.
      </td>
    </tr>

    <tr>
      <td>
        **Editing axis**
      </td>

      <td>
        Authorship permissions that cascade: 

        `View`

         \< 

        `Edit`

         \< 

        `Manage`

        .
      </td>
    </tr>

    <tr>
      <td>
        **Runtime axis**
      </td>

      <td>
        A single permission, 

        **Use**

        , that controls running, testing, and referencing an asset.
      </td>
    </tr>

    <tr>
      <td>
        **Role**
      </td>

      <td>
        A named bundle of permissions across both axes: Manager, Developer, Operator, or Viewer.
      </td>
    </tr>
  </tbody>
</table>

## Docs

- [End-User Access Control](https://docs.moveworks.com/agent-studio/access-control/end-user-access-control.md): 
- [Launch Permissions](https://docs.moveworks.com/agent-studio/access-control/end-user-access-control/launch-configuration.md): Choose who can use a plugin after it is published.
- [Roles and Permissions](https://docs.moveworks.com/agent-studio/access-control/roles-and-permissions.md): The four Agent Studio roles, the two permission axes behind them, and what each role can do.
- [Folders](https://docs.moveworks.com/agent-studio/access-control/folders.md): How Public, Personal, and Custom folders set default access, and how inheritance and overrides work.
- [Connectors and Access](https://docs.moveworks.com/agent-studio/access-control/connectors-and-access.md): Why connectors are closed by default, and how dependency-aware execution protects sensitive systems.
- [Access Control FAQs](https://docs.moveworks.com/agent-studio/access-control/faqs.md): Common questions about roles, folders, connectors, and drafts in Agent Studio access control.