Skip to main content
Control who can access which agents and what actions they can perform. Access control operates on three layers: organization membership, group membership (if enabled), and per-agent access settings.
Team page showing members with their organization roles (Admin or Member) and group memberships

Organization roles

Every user in your organization has a role that determines their base level of access:
RoleDescription
AdminFull control over the organization—can manage members, billing, capabilities, and all agents
MemberStandard team member—can access agents based on agent-level settings
GuestLimited access—can only access agents they’ve been explicitly granted access to
Organization admins automatically have Admin access to all agents in the organization, regardless of agent-specific settings.

Agent access levels

Each agent has access settings that control what team 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

Team access vs. user-specific access

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

Private agents

When you set team access to “None,” the agent becomes private:
  • Regular team members cannot see the agent—it won’t appear in their agent list
  • Organization 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.

Groups

For larger organizations, groups add another layer of access control between organization and agent:
  • Agents can belong to a group
  • Users must be members of that group to access the agent (unless they’re organization admins)
  • Group admins can manage agents within their group
If an agent belongs to a group, access is determined by the user’s role in that specific group—not their organization-wide role.
Groups are an enterprise feature. Contact support@abundly.ai to enable them for your organization.

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 team access to “Use” or “None” for sensitive agents, then grant higher access to specific users who need it. Use groups for scale. If you have many agents or multiple teams, groups make access management much simpler than per-agent user rules. Review access after team 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 team access and user-specific access. If you need to restrict specific users, set the team default to a lower level (like “None”), then grant higher access to the users who should have it.
Guests cannot access agents through team 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 group, you must be a member of that group to access it. The exception is organization administrators, who automatically have access to all groups.
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 organization 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