Define Access Policies and Visibility Rules
Access policies determine what users can see and use in Siesta AI. Plan these rules across Users, Roles, Teams, agent Access, workflow Access / Sharing, data collections, and organization Security settings.
What Policies Should Cover
- Which teams can see each agent.
- Which teams can use each connection.
- Which data collections are visible.
- Which tools can perform write actions.
- Which workflows require review or approval.
- Which users can manage organization settings.
Where Access Is Configured
- Users: create users and assign Owner, Administrator, or User roles.
- Roles: edit permission groups such as Users, Roles, Agents, and Feedback.
- Teams: group users who need the same agents, workflows, connections, and data.
- Agent Configuration > Access: set visibility to Organization, Shared, or Private.
- Workflows > Access / Sharing: set Visibility, Organization Access, and Team Access.
- Memory Collections: use collection permissions for team or organization sharing.
- Organization > Security: review authentication methods, retention, anonymization, and conversation or recording sharing.
Visibility Planning
Users should only see resources that are relevant to their role. If a user can see an agent, they may assume they are allowed to use it for real work. Keep sensitive agents, workflows, and data collections limited to the teams that need them.
Use Private while building an agent or workflow. Switch to Shared for team pilots. Use organization-wide access only for approved general-purpose agents, such as a company knowledge assistant or helpdesk assistant.
For entities with Organization Access, Team Access, or individual user access, choose between permissions such as Can Use and Can Edit carefully. Give Can Edit only to owners who are allowed to change behavior, tools, data, or workflow logic.
Review Triggers
Review policies when you add a new team, add a new connection, change an API credential, publish a workflow, or onboard a new department.
Good policies are simple enough to explain. If a rule is hard to describe, split the access into smaller teams or more specific resources.
Admin Access Mode
Users with the Owner or Administrator role may see an Admin switch in the application header. This switch controls the access mode used for internal Siesta AI requests.
When Admin mode is off, Siesta AI applies normal user-level visibility. This is useful when an admin wants to test the product as a regular user, confirm whether a resource is available through ordinary sharing, or reproduce a user's access issue.
When Admin mode is on, Siesta AI applies elevated organization visibility where the user's role allows it. Admins can review tenant-wide resources such as agents, workflows, connections, data collections, Memory, conversations, tool executions, teams, and users without being limited only to resources they personally created or that were shared with their team.
Admin mode does not bypass security controls. External provider permissions, private connection ownership, disabled functions, approval requirements, and write confirmations still apply. For example, if a connection function requires approval before sending, editing, deleting, or overwriting data, that approval requirement remains active in Admin mode.
For technical troubleshooting, internal API requests carry the selected access mode so the backend can apply either normal user visibility or elevated admin visibility consistently across access-filtered resources.
User Cannot See An Agent
When a user reports that an agent is missing:
- Confirm the user is in the correct organization.
- Check the user's role and team membership.
- Open the agent and review Access visibility and team sharing.
- Confirm the source template or source agent was not private to another owner.
- Check whether required connections, data collections, Memory, or system tools are limited to a different team.
- Ask the user to refresh and confirm they are not filtering the agent list.
System Tools Governance
System Tools are built-in capabilities assigned to agents. They are not the same as ordinary user-created connections, and some can change how agents work inside Siesta AI.
| System tool | User-facing use | Admin risk |
|---|---|---|
| Task Management | Creating tasks | Task clutter or inappropriate tasks |
| Grounding with Google Search | Current web research | Unverified external sources |
| Web scraper | Reading specific URLs | Sensitive URLs or scraping policy issues |
| Code interpreter | Data analysis, files, output files | Data exposure, generated files, runtime behavior |
| Platform Tools | Managing agents and platform objects | Agent configuration changes |
| Orchestration | Batch sub-agent calls | Cost, call volume, unclear results |
| JavaScript executor | Scripts, Excel operations, orchestration | High autonomy, computation or logic errors |
Recommended defaults: enable Task Management, Grounding with Google Search, and Web scraper only when an agent has a clear use case. Enable Code interpreter for data or power-user agents. Keep Platform Tools, JavaScript executor, and Orchestration for admin or power-user agents.
Practical Policy Examples
- Give all employees Can Use access to a general HR knowledge agent, but only HR admins Can Edit.
- Share a HubSpot connection only with the Sales Operations team.
- Keep Gmail and calendar connections private unless a workflow explicitly needs a shared service account.
- Restrict ticket-creating Jira workflows to support and operations teams.
- Use connection token limits for teams or users running high-volume research or automation through shared model connections.