Skip to main content
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 page showing members with their workspace roles (Admin or Member) and team memberships

​
Workspace roles

Every user in your workspace has a role that determines their base level of access:
RoleDescription
AdminFull control over the workspace—can manage members, billing, capabilities, and all agents
MemberStandard workspace member—can access agents based on agent-level settings
GuestLimited access—can only access agents they’ve been explicitly granted access to
Workspace admins automatically have Admin 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:
LevelWhat it allows
AdminFull control: delete agent, change access settings, edit configuration, interact
EditModify instructions, capabilities, documents, and interact with the agent
UseInteract with the agent (chat), but cannot change anything
NoneCannot see or interact with the agent
The hierarchy is: Admin > Edit > Use > None

​
Workspace access vs. user-specific access

Agent access is controlled through two settings, found in the agent’s Settings > Workspace access tab:
Agent workspace access settings showing default access level for workspace members and user-specific access rules
Default workspace access (top section) sets the baseline for all workspace members. If you set this to “Edit,” everyone in the workspace can modify the agent. User-specific access (bottom section) lets you give individual users a different access level. For example, you might set workspace access to “Use” but give a specific colleague “Admin” access.
The system always grants the highest access level between workspace access and user-specific access. User-specific rules are typically used to grant more access, not less.

​
Private agents

When you set workspace access to “None,” the agent becomes private:
  • Regular workspace members cannot see the agent—it won’t appear in their agent list
  • Workspace administrators can still see it exists (for administrative purposes)
  • 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.

​
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.
Teams are an enterprise feature. Contact support@abundly.ai to enable them for your workspace.

​
Agent-to-agent access

Control which agents can communicate with each other. This is configured in each agent’s settings under “Agent-to-Agent Communication.”
Agent-to-agent communication settings showing which agents can communicate with this agent
By default, agents cannot communicate with each other. You must explicitly enable communication between specific pairs. This prevents unintended interactions between agents with different security profiles. See Multi-Agent Collaboration for more on agent-to-agent communication patterns.
Agent-to-agent communication can create indirect access paths. If Agent A can talk to Agent B, and Agent B has access to sensitive data, users who talk to Agent A may be able to access that data indirectly.

​
Best practices

Start with restrictive defaults. Set workspace access to “Use” or “None” 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 admin. The platform prevents you from removing all admin access from an agent—every agent needs at least one administrator.

​
FAQ

Edit access lets you modify how the agent works—instructions, capabilities, documents, and other settings.Admin access includes everything in Edit, plus the ability to delete the agent and change who else can access it.
No. The system always grants the highest access level between workspace access and user-specific access. If you need to restrict specific users, set the workspace default to a lower level (like “None”), then grant higher access to the users who should have it.
Guests cannot access agents through workspace access—they need explicit user-specific access to each agent. This makes the Guest role useful for external collaborators who should only see specific agents.
Yes. If an agent belongs to a team, you must be a member of that team to access it. The exception is workspace administrators, who automatically have access to all teams.
Only if you explicitly configure agent-to-agent communication between them. By default, agents are isolated—they can’t see each other’s documents, databases, or conversations.
Remove them from the workspace in the Members page. They’ll immediately lose access to all agents and data. Their past conversations and actions remain in the logs.

​
Learn more

Agent Management

Workspace-level agent and capability controls

Teams

Organize agents and users by department or function

Multi-Agent

How agents collaborate and communicate