Skip to main content
Fleet gives you the control layer for scaling agents across your organization: tiered permissions, credential management, human-in-the-loop oversight, and an audit trail for agent actions.

​
Permissions and sharing

Fleet provides granular control over every agent in two dimensions: who gets access and what they can do.
  • Who: Share with individual users or your entire workspace.
  • What: Three permission levels:
    • Clone — copy and customize the agent
    • Run — use without modifying
    • Edit — full access to change instructions, tools, and settings
You can layer these permissions. Give a core team edit access, share run-only with the broader organization, and revoke at any time. For setup instructions, see Change access to the agent.

​
Agent identity and credentials

Fleet offers two credential models that control how agents authenticate with external tools:
  • Fixed credentials (“Claws”): The agent uses a single set of credentials regardless of who runs it. Use for shared-resource agents like a team Slack bot where everyone interacts through the same account.
  • User credentials (“Assistants”): The agent acts on behalf of the individual user who invokes it. Each user authenticates with their own account via OAuth. Use for tools where users have different access levels, like a personal email assistant.
This is configurable per agent, so you can choose the right model for each use case. For setup instructions, see Agent identity.

​
Tool access control

Fleet provides layered access control for tools, covering both custom MCP servers (user-added, workspace-scoped) and built-in integrations (platform-provided, such as Gmail, Slack, and GitHub):
Tool access control is an Enterprise feature. If you are interested in this feature, contact our sales team.

​
Role-based permissions

Role-based access control (RBAC) grants or denies access to all MCP servers and integrations in a workspace based on a user’s role. Configure roles in Settings > Roles. The following permissions are available for MCP servers and integrations:
PermissionDescription
mcp-servers:readDiscover and list MCP servers and integrations
mcp-servers:invokeExecute tools from MCP servers and integrations, including OAuth connect/disconnect
mcp-servers:createCreate new MCP server configurations
mcp-servers:updateModify MCP server configurations
mcp-servers:deleteRemove MCP server configurations
A role with mcp-servers:read and mcp-servers:invoke can see and use all MCP servers and integrations in the workspace.
For more on RBAC, see Role-based access control.

​
Create a role with tool permissions

1

Open role settings

Navigate to Settings > Roles and click Create role.
2

Configure MCP Servers permissions

Expand the MCP Servers section and select the permissions to include. For example, grant Read and Invoke for users who need to use tools but not manage server configurations.
3

Assign the role

Assign the role to users in the workspace in Settings > Members.

​
Attribute-based access control

Attribute-based access control (ABAC) adds resource-level granularity on top of RBAC. Admins can tag individual MCP servers or integrations and create policies that grant or restrict access based on those tags. ABAC operates on two resource types for tools:
Resource typeApplies to
mcp_serverCustom MCP servers added to the workspace
fleet_integrationBuilt-in integrations (Gmail, Slack, GitHub, etc.)
A role with no mcp-servers:* RBAC permissions can still be granted access to specific tagged resources (e.g. only Notion and Gmail) via an ABAC allow policy. Conversely, a role with broad RBAC access can be restricted from specific resources via an ABAC deny policy.
For details on policy structure, operators, and managing policies via the API, see Attribute-based access control.

​
Workspace integration policy

Built-in integrations have an additional control layer: a workspace-level enable/disable toggle managed from Settings > Integrations > Access control. This acts as an admin-controlled baseline that runs before per-user RBAC and ABAC. If an integration is disabled at the workspace level, no user can access it regardless of their role or ABAC policies.
The Access control page is only visible to admin users (requires workspaces:manage permission).

​
Policy evaluation order

The three layers evaluate in sequence. The evaluation order differs slightly between custom MCP servers and built-in integrations: Custom MCP servers: 
ABAC deny → RBAC → ABAC allow
Built-in integrations: 
Workspace policy gate → ABAC deny → RBAC → ABAC allow
At each step:
  1. Workspace policy gate (integrations only): If the integration is disabled, access is denied. No further evaluation.
  2. ABAC deny: If a deny policy matches, access is denied. Deny always wins.
  3. RBAC: If the user’s role grants the required permission, access is allowed (unless step 4 is needed).
  4. ABAC allow: If RBAC does not grant access, an allow policy can still grant it for specific tagged resources.

​
Observability and audit trail

Agent actions in Fleet are captured in a structured LangSmith trace, including tool calls, decisions, and outputs. You can inspect, search, and export traces. Combined with agent identity and permissions, tracing tells you which agent acted, on whose behalf, with what credentials, and what it did at each step.

​
Human-in-the-loop oversight

Fleet provides a central inbox for reviewing agent actions across all your agents. You can configure agents to pause and request approval before taking specific actions, then review, approve, edit, or reject from one place. For setup instructions, see Human-in-the-loop.
Edit this page on GitHub or file an issue.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.