Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.abundly.ai/llms.txt

Use this file to discover all available pages before exploring further.

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 Owner 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
OwnerFull 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
NothingCannot see or interact with the agent
The hierarchy is: Owner > 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:
Agent user access settings showing the default access level and user-specific access rules
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 “Owner” access.
The system always grants the highest access level between the default and user-specific access. User-specific rules are typically used to grant more access, not less.

​
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.

​
Admin-only agents

Workspace admins can mark an individual agent as Admin-only from its Settings > User access tab. The agent — its chats, instructions, capabilities, and configuration — becomes visible only to workspace admins, regardless of any default or user-specific access rules above. Use this for agents that work with workspace-internal data (billing, analytics, member lists) that the rest of your team shouldn’t see. Some capabilities are also gated to admin-only agents for the same reason.
Admin-only narrows the portal only. External entry points an admin has enabled — embeddable widget, HTTP API, MCP, webhooks, public clone link — keep working under their own authentication. Agent-to-agent communication is also unaffected, so other agents can still reach the admin-only agent if they’re configured to.

​
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

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.
Agent-to-agent communication settings showing which agents can communicate with this agent
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.
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. Be deliberate about setting an agent’s discoverability to Everyone — it broadens the set of agents (and, transitively, users) that can reach it.

​
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 owner. The platform prevents you from removing all owner access from an agent—every agent needs at least one owner.

​
FAQ

Edit access lets you modify how the agent works—instructions, capabilities, documents, and other settings.Owner 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 the default and user-specific access. If you need to restrict specific users, set the default to a lower level (like “Nothing”), then grant higher access to the users who should have it.
Guests cannot access agents through the default access level—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