Define Access Policies and Visibility Rules

Access policies decide who can see, use, and edit resources. Use Users and Roles to assign tenant-level responsibilities, then apply resource access through agent configuration, teams, and each resource's sharing settings. The practical model is: keep work private while building, share to specific teams for rollout, and use organization-wide access only for approved general resources.

Share the Pilot Safely

Treat sharing as a release step, not part of initial configuration:

1. Keep the data collection, agent, and any new connection private while the owner runs the first tests.
2. Create or confirm one pilot team and add only the intended users before changing resource access.
3. Review the agent, collection, skills, and connections as separate access boundaries. Sharing the agent does not justify broader access to its data or external systems.
4. Grant the pilot team Can Use. Reserve Can Edit/Write for the named agent and data owners who are responsible for reviewing configuration changes.
5. Test with a real pilot member in normal user mode. Confirm that the member can find and run the agent, retrieve only the intended collection, and cannot edit production behavior.
6. Verify the external identity used by every attached live tool. Provider permissions still apply even when the Siesta resource is visible.
7. Review the pilot conversations, feedback, retrieval evidence, and any Tool Executions before adding another team or enabling organization-wide access.

Choose the connection identity from the ownership of the external work:

External scope	Connection posture	Required control
Team-owned dataset, queue, shared mailbox, or operational system	Shared connection using an admin-managed service or team identity	Name an owner, minimize provider scope, document rotation, and never substitute an employee's personal account merely for convenience
A user's own mailbox, calendar, Drive, or individually attributable action	Private per-user authorization	Allow only the required private connection type and require each user to connect and verify their own account

The agent may offer both patterns when the use case needs them, but a shared credential must not silently stand in for user intent and a private credential must not be made shared. Before rollout, verify that the pilot agent remained private through its tests and that its data access matched the intended audience. Once that boundary is accepted, apply the same identity rules when adding MCP and other live tools.

How Access Works

Plan around these rules:

• If an access-controlled resource has no sharing mode, treat it as private.
• The creator can access the resource they created.
• Owner/Admin mode can review organization resources where the user's role allows it.
• Organization access can allow use or write access for everyone in the tenant.
• Team policies can allow Can Use or Can Edit/Write for selected teams.
• External provider permissions still apply. Siesta access does not give a user access to Gmail, Drive, Jira, HubSpot, or another provider if the provider rejects the action.

Where To Configure Access

Resource	Where to review	What to decide
Users	Users and Roles	Who can administer the tenant, invite users, and manage roles
Teams	Teams	Which people share the same operating boundary
Agents	Agents > Access	Private, shared, organization-wide, and team edit rights
Connections	Connections and Organization connection governance	Who can use credentials and which functions run
Workflows	Workflows > Access / Sharing	Which teams can run or edit the workflow
Data and Memory	Data, Memory collections, and collection access	Which agents and teams can retrieve the content
Graphs	Graphs > Settings and Agent Configuration > Graph assignments	Who can inspect or edit connected knowledge and which Agents may read or write it
Conversations and recordings	Organization Security and sharing settings	Whether public sharing is allowed

Use vs Edit/Write

Use access lets someone run a resource. Edit/write access lets someone change behavior, prompts, tools, workflow nodes, sharing, or data linkage. Treat edit/write access as an operational responsibility, not a convenience.

Use this default:

• Give Can Use to users who should run the agent or workflow.
• Give Can Edit/Write only to owners who can approve behavioral changes.
• Keep draft agents private until prompts, tools, and data are reviewed.
• Share pilots to one team before organization-wide release.
• Recheck access after every credential rotation, team restructure, or workflow change.

For Graphs, keep the resource private during design, assign it to an Agent with read-only behavior first, and enable Allow writing to Graphs only after extraction guidance and review ownership are defined. Graph assignment cannot expand the current user's or Agent's effective access. See Graphs for the lifecycle and Agent configuration for assignment controls.

Admin Mode

Admins may use an Admin switch in the application header. With normal mode, the product applies the admin's ordinary user visibility. With Admin mode, elevated organization visibility is used where the role permits it.

Use Admin mode to troubleshoot:

• whether a resource exists,
• whether a user is missing team access,
• whether an agent is private,
• whether a workflow is shared incorrectly,
• whether conversations, tool executions, or data collections need review.

Admin mode does not bypass external provider permissions, private connection ownership, disabled functions, confirmation requirements, or organization security policy.

Troubleshooting Missing Resources

When a user says "I cannot see it":

1. Confirm the organization in the app header.
2. Confirm the user exists and has the expected role.
3. Confirm team membership.
4. Open the resource in Admin mode and check the access policy.
5. Confirm the resource is not still private to the creator.
6. Confirm organization access or team access grants Can Use.
7. If the user needs to edit, confirm Can Edit/Write explicitly.

Troubleshooting Tool Access

When an agent cannot use a connection:

1. Confirm the connection is assigned to the agent as shared or private.
2. For private tools, confirm the current user owns the required private connection.
3. Confirm the organization has not disabled the connection type.
4. Confirm the function is not disabled by organization governance.
5. Confirm the user or team can use the connection.
6. Confirm the external provider credential is still valid.
7. Open Tool Executions to inspect status, arguments, result, and approval state.

Public Access

Public chat, public conversation sharing, public recording sharing, API keys, webhooks, and recordings can be blocked by organization policy. If a page is configured correctly but public behavior fails, check Organization > Security before editing the agent.

For public agents, review:

• public chat enabled at organization level,
• public chat enabled on the agent,
• privacy link,
• feedback and file-upload settings,
• allowed tools,
• prompt boundaries,
• retention and sharing settings,
• whether the widget or public page should use a production agent.

Policy Examples

• Company help agent: organization Can Use, AI Admins Can Edit.
• Support ticket agent: Support Can Use, Support Leads Can Edit, Jira write functions require confirmation.
• Finance reporting agent: Finance Can Use, Finance Admins Can Edit, no organization-wide access.
• Website widget agent: public chat enabled, narrow prompt, reviewed privacy link, limited tools, monitored feedback.
• Experimental workflow: private to creator until read and write Tool Executions are reviewed.

Apply these rules while you configure shared and private connections and before you publish agents or workflows.