Access Control

Control who can access which agents and what actions they can perform. Access control operates on three layers: workspace membership, team membership (if enabled), and per-agent access settings.

​

Workspace roles

Every user in your workspace has a role that determines their base level of access: Workspace admins automatically have Full Access to all agents in the workspace, regardless of agent-specific settings.

​

Agent access levels

Each agent has access settings that control what workspace members can do with it. There are four levels: The hierarchy is: Full Access > Edit > Use > Nothing

​

Default access vs. user-specific access

Agent access is controlled through two settings, found in the agent’s Settings > User access tab: Default access (top section) sets the baseline for everyone who can see the agent—all workspace members if the agent is not assigned to a team, or all members of that team if it is. If you set this to “Edit,” everyone in that scope can modify the agent. User-specific access (bottom section) lets you give individual users a different access level. For example, you might set the default to “Use” but give a specific colleague “Full Access”. To remove a user-specific override entirely and revert the user to the workspace default, click the red trash button next to their row. A confirmation modal prevents accidental removal.

​

Private agents

When you set the default access to “Nothing,” the agent becomes private:

• Other workspace or team members cannot see the agent—it won’t appear in their agent list
• Workspace administrators (and team administrators, if the agent is assigned to a team) can still see the agent in the management view — including its description, instructions, agent-to-agent connections, and exposure hooks (MCP server, HTTP API, webhooks, widget) — but cannot interact with it directly
• Only users with explicit user-specific access can interact with it

This is useful for agents that handle sensitive data or are still in development.

​

Inviting guests by email

The Invite by email section on the agent’s User access tab lets you grant access to this agent by email address — including to people who are not in your workspace yet:

• If the email belongs to an existing workspace member, they get the chosen access level directly.
• Otherwise an invitation is sent (the email is optional — the invite also appears when the person logs in). When they accept, they join the workspace as a Guest and receive the chosen access level on the agent.

Guests can log in but only see the agents they’ve been granted access to — no workspace, team, or member surfaces. They don’t count toward your plan’s member limit, and they’re only visible to workspace admins on the Members page (and to team admins in their teams). Pending guest invitations are listed on the agent’s User access tab, where they can be revoked.

​

Admin-restricted agents

In each agent’s Settings > User access tab, users with Full Access can narrow who in the portal can see and interact with the agent. There are three tiers: When a restriction is active, the agent — its chats, instructions, capabilities, and configuration — is hidden from anyone outside the chosen admin tier, regardless of any default or user-specific access rules above. Use the tighter tiers for agents that work with internal data — billing, analytics, member lists, audit logs — that the rest of the workspace or team shouldn’t see. Some capabilities (for example workspace and team analytics) are also gated behind the matching admin tier for the same reason.

​

Teams

For larger workspaces, teams add another layer of access control between the workspace and individual agents:

• Agents can belong to a team
• Users must be members of that team to access the agent (unless they’re workspace admins)
• Team admins can manage agents within their team

If an agent belongs to a team, access is determined by the user’s role in that specific team—not their workspace-wide role.

​

Agent-to-agent access

Agent-to-agent access is configured per agent in Settings → Agent Communication, and has two sides:

• Discoverability (inbound) — who is even allowed to reach this agent: No one, Team (agents in the same team, default), or Everyone (any agent in the workspace, including across teams).
• Outbound — which other agents this agent is configured to call. Picked explicitly per target from the communication graph.

Agents only exchange messages when both sides align: the target must be discoverable by the caller, and the caller must explicitly allow the target in its outbound list. Tightening a target’s discoverability (e.g. from Everyone back to Team) immediately blocks existing outbound connections from callers that can no longer reach it. See Multi-Agent Collaboration for more on agent-to-agent communication patterns.

​

Best practices

Start with restrictive defaults. Set the default access to “Use” or “Nothing” for sensitive agents, then grant higher access to specific users who need it. Use teams for scale. If you have many agents or multiple departments, teams make access management much simpler than per-agent user rules. Review access after membership changes. When someone leaves or changes roles, audit their access to ensure it’s still appropriate. Keep at least one user with Full Access. The platform prevents you from removing all Full Access from an agent—every agent needs at least one user with Full Access.

​

FAQ

​

Learn more