Files: who can reach what you upload

A chat attachment is shared with that chat's members only. The sharing audiences are an account, an agent, a chat, admins, the workspace, or a public link.

A file's audience is set per file and per folder, and nothing becomes public unless a person explicitly makes it so. For uploading and browsing basics, see Files; this page is about who can reach a file.

Chat attachments

Attaching a file in chat shares it with that chat's members, people and agents alike. The share follows the chat's membership: someone added to the chat later can open the file, because a chat's history is shared with joiners, and someone who leaves the chat loses it, because leaving loses the chat. See Who can see what.

An attachment is not shared with the rest of any workspace, and browsing never surfaces it to people outside the chat, workspace admins included. The one reach beyond the chat is Message search: a file you send as a workspace account is part of what that workspace's admins can search, like the message it rode in on. See Workspaces, accounts, and limits. The file itself is stored in an uploads area (your personal one by default; the composer lets you pick another destination), but where it is stored does not widen who can open it.

Connected apps ride chats the same way a share does, and changing a chat's audience does not quietly widen them: when people join, app access that was granted to the chat is re checked rather than silently inherited, the add flow names it at pick time ("Joining this chat also grants: Trip planner"), and whoever granted the app gets a card. See Apps and running code.

A chat's working files stay with the chat

Files an agent creates while working in a chat, such as documents, presentations, diagrams, and anything it saves without being told a bucket, live in that chat's own file area. Only the chat's participants can reach them. They do not appear in the workspace's file browser, Recent, or search for anyone outside the chat, and that includes workspace admins. Someone added to the chat later can open them, like any chat share. Asking the agent to save into a named workspace bucket still puts the file there, where the usual workspace sharing applies.

Workspace admins have one recovery path for when access is genuinely needed, such as a departed teammate's work or a legal request: the Sealed buckets view in the workspace's Admin area. Revealing the list of sealed file areas, and granting yourself access to one, are each recorded in the workspace's Governance log and notify the other admins. Both actions take an optional note explaining why, and it reaches the other admins along with the notification and the log entry. Nothing is posted in the chat. The access granted is read, or read and write, chosen at the time, and never control over the files' sharing. You can remove your own access again from the file's access panel.

The sharing audiences

From the file browser's Add access dialog you can share a file with:

• a specific person, by one of their accounts
• a specific agent
• workspace admins
• everyone in the workspace
• anyone with the link (public)

Sharing with a chat happens by attaching the file there, or forwarding a message that carries it. Each share also carries a permission level: read (view and download), write (also edit and add), or admin (also manage access and share onward). A share on a folder covers everything inside it.

A share to a person names one of their accounts, not the person wholesale, and it follows that account's life. A share to someone's workspace account ends when that account does, so people who leave a workspace lose what they held through it. A share to a personal account has no workspace behind it and ends only when someone revokes it.

Checking who can see something

Select a file and its preview header shows a small badge reading Public, Workspace, or Restricted.

Click the badge to see who can reach it. The panel lists the sharing rules that apply, grouped by where each one was set: rules on the file itself, then on each folder above it, then on the bucket. That grouping matters, because access flows downward. A rule set on the bucket applies to everything in it, and removing that rule removes it everywhere, not just for the file you were looking at. The panel says so before you confirm.

If you can open a file, you can see who else can. Some rules may be set in a folder you do not have access to yourself; the panel tells you how many apply rather than showing them, so the list is never quietly incomplete.

Where you hold admin permission, each rule has a Remove control. Removing one takes away a single permission level, so if someone holds both read and write, removing write leaves read in place. The panel tells you when that is the case.

Being able to open something is not the same as finding it

A file shared into a chat shows up in Recent and search for that chat's members. Other people who have access can still open it from a link, but it will not appear in their browsing or search results. This keeps a chat's working files out of everyone else's way without changing who can read them.

The access panel points this out when it applies, and names the chats involved. Anyone granted access to the file directly also finds it normally, including whoever created it.

Public files follow the same idea. A public share means anyone with the link can open the file; it does not put the file in anyone's search results, Recent feed, or folder listings. A public file appears in your own search only after you have opened it, and drops back out for everyone if the public share is removed. People and agents you shared with directly are unaffected, since an explicit share is always findable. There is no way to browse or search for public files you have not been handed.

Public means anyone

A public share makes the file readable by anyone who has the link, signed in or not. It is the link that carries the access: the file stays out of search and browsing for people who have never opened it. Opening a private share link switches the browser to the file's plain address, so copying what is in the address bar afterwards does not pass the access on. Share it again from the Share dialog instead. The Share dialog asks you to confirm before creating one, and you can remove a public share later like any other. Live things agents serve have the same rule at a different threshold: publishing an app reaches the workspace (and the chat it was published from), and exposing anything to the open internet takes a person granting it in chat first.

Only a person can make something public. An agent always needs your say-so before letting the whole world see a file; it cannot do it alone, even for a file it created in its own folder and manages. When an agent wants something published it posts a request card in chat saying so, and the file stays private until someone with admin permission on it grants the request. Everything else about sharing is unchanged: an agent that holds admin can still share with a person, an agent, a chat, or the whole workspace on its own.

Agents also cannot add to or change anything inside a public folder, since that would publish it just the same. So if you keep a public folder and want an agent to update something in it, make the change yourself or unpublish the folder while the agent works. An agent can always remove public access without asking, because that narrows who can see something rather than widening it.

What a shared page can do

An HTML page someone shares with you opens on its own separate address (like workspace-bucket.bolter.page), not inside Bolter itself. Scripts run there, so a page can render interactive content, store data locally in your browser, and behave like any other web page. A page cannot install anything that outlasts closing the tab, cannot reach your Bolter account, and cannot write files back to the workspace (these addresses are read-only). Each bucket gets its own address, so a page from one bucket cannot read files from another bucket.

When you open a page, you are opening it under your own access. If the page is private, you see it because it was shared with you or because you are a member of the workspace. If it is public, anyone with the link can open it without signing in. The page itself does not know who you are unless it asks you directly.

Agents and file access

Agents follow the same access rules as people. An agent can read a file when the file is shared with a chat the agent is in, with the agent itself, or with everyone in the agent's workspace. When an agent needs a file it cannot read, it posts a request card in chat; only someone who holds admin permission on that file or folder can grant it. The same card is how an agent asks to make something public, and the card says which of the two it is asking for.