read.file.host
Read any file the account can reach. Its effect is no: cannot be undone.
What this id is made of
This is not a string. It is read↗.file↗.host↗, three nodes joined by three edges, and each of them has an address, a page and a JSON file. Follow any of them and you get the query for that word rather than a definition of it.
| Node | Edge | Reads as |
|---|---|---|
read↗ | has_verb | this capability has the verb read |
file↗ | acts_on | this capability acts on file |
host↗ | reaches | this capability reaches host |
filesystem↗ | in_family | this capability is in the filesystem family |
no↗ | has_undo_class | this capability has the undo class no |
The gloss above is a convenience, not the definition. A node carries no inherent meaning: what
read.file.hostis emerges from the edges traceable from it. The strongest case ishost↗, where the deployment shapes that use it do not agree about what it means, and the page keeps the disagreement rather than averaging it.
In 11 of 17 published shapes
| Deployment shape | Barrier there | Known by | Whose material | Note | |
|---|---|---|---|---|---|
| ● | Claude Code on the web (a remote session container) | none (not a control) | observed | not stated | any file in the container - the attached clone, the harness's state, the system. Not your machine's files (the assess tree's 'home: boundary') |
| ● | Claude Code (the CLI, on your own machine) | none (not a control) | derived | not stated | everything your account can read, because a shell as you reads as you |
| ● | Claude Code (the CLI, on your own machine) | none (not a control) | derived | not stated | everything your account can read, because a shell as you reads as you |
| ◐ | Claude Desktop (a desktop app with local tools) | setting (not a control) | derived | not stated | |
| ○ | Claude (in the browser, with connectors switched on) | boundary | derived | not stated | a drive connector: your other files, as scoped |
| ○ | Claude's Microsoft 365 connector (Outlook, SharePoint, OneDrive, Teams) (contributed by riskmandate.ai) | boundary | documented | mixed | "SharePoint search requires Sites.Read.All permission. Site-specific permissioning (using *.Selected permissions) is not supported because the underlying search is tenant-wide." Everything the user can already open, across the tenant. |
| ○ | The official Dropbox MCP server (contributed by riskmandate.ai) | boundary | documented | mixed | "Extract text from PDFs, Word documents, and other text representable files"; "Search files and folders by name or content". Everything the account can open, team folders included. |
| ● | A scheduled job running as a service account | none (not a control) | derived | not stated | |
| ● | Actions runner (a hosted CI job) | none (not a control) | observed | not stated | the runner's user with passwordless escalation: every file on the ephemeral machine |
| ○ | An assistant connected to a personal Google Drive with drive.readonly (contributed by riskmandate.ai) | boundary | documented | mixed | drive.readonly - "View and download all your Drive files." The default corpus of a listing is "files owned by or shared to the user"; whether shared drives are included is open, below. |
| ○ | The Google Workspace MCP servers (Gmail, Drive, Docs, Sheets, Slides, Calendar, Chat) (contributed by riskmandate.ai) | boundary | documented | mixed | drive.readonly - "View and download all your Drive files." A Drive listing's default corpus is "files owned by or shared to the user": everything any colleague, client or counterparty ever shared. |
| Barrier | What stands in the way | Is it a control | |
|---|---|---|---|
| ● | none | nothing in the way | no |
| ◉ | expectation | a rule in prose, enforced by nobody | no |
| ◐ | setting | a switch the agent's own account can flip | no |
| ○ | boundary | enforced above the grant, out of the agent's reach | yes |
What the starting mandates say about it
| The mandate says | Which mandates |
|---|---|
| authorised | Chat, with connectors switched on, A scheduled job under a service account, A reader on my drive, Search our tenant, read-only, Find and read my files, An assistant over my Workspace, reading |
| refused | A coding assistant on my machine, Chat in the browser, nothing connected |
| unstated | A coding assistant in a container on the web, The desktop app, with local tools switched on, A CI job on a hosted runner, A browser extension I installed, A reader on my mailbox, Find things in the inbox, draft replies, never send, A sandbox: build and run one AI-agent workflow, What the agent inferred it was authorised to do, from one session |
Unstated is not authorised. A mandate that never mentioned a capability did not authorise it, and the delta on every example page counts it as excess and says which kind it was.
What would move it to the fourth barrier
| What | What it costs | The barrier afterwards |
|---|---|---|
| run the agent in a container with only the project mounted, or under a separate user account | an afternoon, then ongoing friction (container) · days, and it fights you (account) | boundary |
This is a published reduction, not a recommendation. Whether it is worth doing depends on the assets and the consequences, which are not in this document and are not this site's to guess. Since v0.4.3 it is also a node,
setting/read.file.host, in the deployment shape universe↗: it narrows this capability and moves it to the barrier named in the third column, which is the path the prohibitions table's last column is a projection of.
The capability grammar↗ · This primitive as JSON↗
Site index for agents↗ · HTML version↗