# 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](https://bolter.chat/help/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](https://bolter.chat/help/access/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](https://bolter.chat/help/workspaces). The file itself lands in the chat's own
file area, the same private place the chat's agents keep their working
files, so admins reach the bytes only through the audited Sealed buckets
path described below. The small badge on the attachment lets you pick a
shared workspace bucket instead; a file sent there is visible to whoever can
see that bucket. Attachments from before chats had their own file areas
remain in the workspace's uploads bucket, shared with the chat the same way.

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](https://bolter.chat/help/apps-and-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
- everyone in the workspace
- workspace admins only
- anyone with this link: a private, read-only link that only people you
  give it to can open, which you can copy again or revoke later from the
  file's Who can see this file panel, where it is listed as the Link row,
  with the reach line "Anyone with this exact link" under it
- the public: anyone on the internet, signed in or not

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 link share is always read. 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.

Source: https://bolter.chat/help/access/files-and-sharing