Permission Design Best Practices to Prevent "I Shared It But They Can't See It" in Amazon Quick's Chat Agent and Space

I'm Satoru Ishikawa from the Cloud Business Headquarters. In Amazon Quick, in addition to assets inherited from the former Amazon QuickSight, such as dashboards and datasets, you can now work with new resources such as spaces, knowledge bases, and chat agents. However, these new resources are not covered by the bulk permission management of conventional shared folders, and permissions must be granted to each one individually.

If you deploy a custom chat agent to your team without understanding this difference, problems occur such as "I shared the agent, but the dashboards in the space can't be referenced and an error occurs." This article explains the mechanism behind this problem and the permission design best practices that Quick Suite administrators should keep in mind.

Conclusion first

To summarize the conclusion up front:

• Spaces, knowledge bases, and chat agents are not covered by shared folder permission inheritance, and Owner / Viewer must be granted individually for each resource
• Sharing a space does not automatically grant access to the dashboards or knowledge bases linked within it. A chat agent's responses are also evaluated within the scope of the permissions held by the user themselves
• To prevent "I shared it but can't see it," share the agent itself, the linked space, the assets in the space, and the knowledge bases with the same group that will use the agent
• Before publishing, verify with a test user who has no extra permissions that Resource unavailable does not appear

Below, we explain the mechanism behind this conclusion and the operational points in order.

Differences in the permission model between conventional assets and new resources

Permission management in Amazon Quick is broadly divided into two models depending on the type of resource.

Conventional assets (dashboards, analyses, datasets, data sources, topics) inherit the folder's permissions once added to a shared folder. Therefore, if you shared a folder with a department or team group, permission management was complete just by adding assets.

On the other hand, spaces, knowledge bases, and chat agents cannot be added to shared folders, so Owner or Viewer permissions must be granted individually to users or groups for each resource.

Why "I shared it but can't see it" happens

Sharing a space does not grant access to the resources inside it

There is a restriction that users who do not have access to a resource cannot access the topics or dashboards in a space. Even if you share a space, access to the assets in it is not automatically granted.

In other words, even if you share a space with Viewer permission, permissions to the dashboards, topics, and knowledge bases linked to the space are required separately. The exception is files uploaded directly to the space, which can be referenced by everyone who has access to the space. The reason is that they are resources belonging to the space.

Chat agents are evaluated with the user's own permissions

The same principle applies to custom chat agents. An agent's Viewer "can receive responses within the scope of resources they have access to," and if they do not have access to a linked resource, that resource is displayed as Resource unavailable.

After sharing a chat agent, you need to individually share each resource linked to the agent. Sharing the agent itself merely provides the entry point, and permissions to the knowledge and data that form the basis of the answers are evaluated for each user.

The diagram below illustrates this relationship. For the group that uses the agent, you need to grant not only the share shown by the solid line (①) but also shares to the resources connected by dotted lines (② to ④).

Best practices for permission design

1. Grant permissions to groups as a rule

Sharing of spaces, knowledge bases, and chat agents supports both users and groups. Accumulating grants to individual users makes management harder as the number of resources grows, so the principle is to "create groups by department, team, project, and so on, and share all resources with the same group." Changes in membership are completed simply by adding or removing members from the group.

2. Grant the "same group" to the agent and the linked resources

Once you have decided the unit (group) to which the agent will be published, share with that group in the same way:

1. The chat agent itself (Viewer)
2. The space linked to the agent (Viewer)
3. The dashboards and topics linked to the space (individual sharing or via a shared folder)
4. The knowledge bases linked to the space (Viewer)

At this time, also be sure to check the permissions on the datasets underlying the dashboards and the row-level security (RLS) settings. If even one link in the permission chain—agent, space, asset, dataset, in that order—is missing, it becomes the cause of "can't see it."

3. Continue to manage folder-compatible assets with shared folders

For folder-compatible assets such as dashboards and topics, it is efficient to manage them in bulk with shared folders as before and share those folders with the group that uses the agent. If you share an "agent asset folder" with the group, then when you increase the assets linked to the space, simply adding them to the folder gives them the same permissions.

4. Use direct uploads to spaces for static documents

Files uploaded to a space can be referenced by everyone who has access to the space, so no individual permission grants are needed. For manuals, FAQs, and other content that is rarely updated, operating through file uploads can shorten the permission chain. However, conversely, it means "anyone who can see the space can always see them," so take care not to mix in highly confidential documents.

5. Verify behavior with a test user without extra permissions before publishing

The agent creator (Owner) can access all resources, so permission gaps cannot be noticed in the creator's own testing. Using a test user with the same permissions as the target group, confirm that Resource unavailable or errors do not appear for the expected questions before publishing.

6. Control who can create with custom permissions

Quick Suite administrators can control permission to create chat agents through custom permissions (Custom permissions) profiles. This is a so-called guardrail strategy. When anyone can create agents and spaces, permission design tends to become a dead letter, so we recommend limiting creators and controlling this together with naming conventions and publishing workflows.

Notes

• Knowledge base sharing supports the Viewer role for all types, but only administrator-managed Microsoft SharePoint Online and Google Drive knowledge bases can be shared as Owner. Also, the creator is always an Owner and cannot be removed.
• Sharing of data source connections can be performed only by Quick Suite administrators and is limited to administrator-managed (service credentials) connections.
• Even if a resource linked to a space is deleted externally, space users are not notified and are only shown an unavailable message. We recommend detecting this through periodic inventory reviews.
• The maximum number of resources that can be linked to a space is 20 per resource type (dashboards, topics, knowledge bases, actions).

In closing

In Amazon Quick, spaces, knowledge bases, and chat agents are outside the scope of shared folder permission inheritance, and individual grants for each resource are required. Because an agent's responses are evaluated with the user's own permissions, sharing the same group across "the agent itself, the space, the linked assets, and the knowledge bases" is the most reliable way to prevent permission errors.

Why not consider an operation that lets you deploy agents with confidence, based on the principle of group-level permission grants, combined with test user verification before publishing and periodic audits?