Skip to main content
AgentRuntime separates workspace access from project access. Most day-to-day builder permissions come from your project role; workspace roles control billing, team invites, and workspace policy.

​
Workspace roles

Workspace email invites set only the workspace role. They do not attach a specific project. After accepting, members can access public projects at the default contributor level.

​
Project roles

Contributor

Create and edit workflows, run and control runs, manage connections and MCP instances, and view usage. Maps to the project_contributor role in the API.

Project viewer

Read workflows, runs, analytics, Autopilot chat, and work items. Cannot edit graphs, manage connections, or start runs.

Project admin

Everything contributors can do, plus manage project members and toggle public vs private visibility.

​
Capability matrix

Some API endpoints also require PAT scopes (for example, workflow:run or mcp:execute) in addition to the project role. See API authentication.

​
Public vs private projects

  • Public — Visible to all workspace members. Default access is Contributor unless you assign an explicit project role.
  • Private — Hidden from the project picker unless you are a member. Project admins (and workspace owners as a backup) add members from Project settings (project menu ⋮).
Workspace owners and admins can open private projects they are not members of, but by default they have read-only project access. Workspace admins can enable Full access on private projects under Settings → Team → Workspace access policy for IT-style workspaces that need elevated recovery access.

​
Managing access

​
API and PAT scopes

When calling the API with a personal access token, both the user’s project role and the token’s scopes must allow the operation: Create PATs from Settings → API keys.

​
Sysadmin access

Internal AgentRuntime operators use a separate sysadmin login path. Sysadmin capabilities are not available to customer workspace members.