# Shared Drives For Agents: Everything Available Runs On Your Identity, Granularity Comes From Segregation Rather Than Scoping, And Nothing Supports Per-Agent Keys

**version** v0.33.59
**date** 16 August 2026
**from** Research (executed for the project lead)
**to** Engineering, Product, Strategy

**type** Research brief

*Thirteenth of 16 August. Scored against public sources as of 16 August 2026. Answers a direct question about giving two agent sessions a shared working area, with permissions, identity, cryptography, cost and deployment mapped.*

---

## What This Is

A survey of ways to give two agent sessions a shared file area, and three findings that matter more than the option list: **the ecosystem's dominant recommendation is the opposite of the question, since the standard advice for running multiple sessions against one codebase is to isolate them with separate working directories so they behave like independent developers, which means sharing is against the grain of current tooling rather than a solved problem with several vendors; the permissions finding is the sharpest, because the widely used file service classifies its narrow scope as non-sensitive and its readable scopes as restricted, and the narrow one only exposes files the application itself created, so an agent using it cannot read anything you already had, while the broad one exposes everything the authorising account can see and cannot be narrowed, which leaves practitioners with one workable technique that is not scoping at all, namely creating a dedicated shared drive containing only what the agent should see, and that is granularity by segregation rather than by permission, which is the same conclusion this corpus reached on 14 August about vaults and keys; identity is the finding with the largest blast radius, since connector authorisation is per identity rather than per person and inherits the authorising account's permissions, so every agent session acts as you, is indistinguishable from every other session, and cannot be attributed, which answers the rogue-agent question directly because one compromised session reaches everything every other session can reach; nothing surveyed supports per-agent public and private keys, as every option authenticates with a bearer token or an application key, so the cryptographic scoping the memo asks about does not exist in any of them; on cost the range runs from free self-hosting with all features to a hundred and twenty-five a month for a hosted tier, with no option offering micropayments, so per-call agent economics are unavailable; and the distinction the memo draws between memory and raw files is not only correct but sharper than stated, because curated memory platforms extract facts and resolve conflicts on write, which is precisely the operation that destroys the provenance the memo wants to keep.** It is the thirteenth document of 16 August (cross-ref: the v0.33.59 NHI site brief, the v0.33.59 relay pattern brief, the v0.33.58 serialised pull request brief, the v0.33.56 plugins brief, and the v0.33.59 comparison pages brief). New contributions: **the four options mapped against the memo's own criteria, the scope paradox and segregation as the only real granularity, per-identity authorisation as the blast radius answer, the absence of per-agent keys, the cost and deployment tables, and curation identified as the thing that destroys provenance.**

## The Short Answer

**There is no option that provides per-agent identity, cryptographic scoping and raw provenance at the same time.** Four families exist, each answering part of the question:

| Option | Cross-machine | Per-agent identity | Scoped access | Raw files | Keys |
|---|---|---|---|---|---|
| Local shared folder via a protocol server | **No** | No | Path-level | Yes | No |
| Hosted drive connector | Yes | **No, acts as you** | Segregation only | Yes | No |
| Memory platform | Yes | Partial, by scope | Namespace | **No, curated** | No |
| Files in a versioned folder, built yourself | Yes | Whatever you build | Whatever you build | Yes | Whatever you build |

The rest of this brief is the detail behind that table.

## The Ecosystem Recommends The Opposite

Worth stating first, because it reframes the question.

The dominant published advice for running several sessions against one codebase is **isolation, not sharing**. The recommended pattern is a separate working directory per agent, so that several agents behave exactly like independent developers in separate branches, and the reasoning given is context confusion: when two sessions share a workspace they read each other's in-progress changes and make incorrect assumptions about the state.

So the memo is asking for something the tooling actively steers away from. That is not a reason not to want it, and it does explain why the options are thin.

## Option One: A Local Shared Folder Through A Protocol Server

The reference filesystem server exposes a structured interface over a directory tree, offering read, write, list, search and file information over a local transport. It is a different surface from an assistant's built-in file access, and its purpose is exactly this: letting processes other than the assistant read and write through a controlled interface.

**Four limitations, and the first two are decisive for the memo's case.**

**It does not span machines.** Community coordination servers built on this are explicit that they assume sessions share a common filesystem path and do not work across machines.

**It is not shared between sessions.** Each session spawns its own server subprocess. There is an open feature request asking for one process per workspace instead, which notes that four sessions with six servers currently spawn forty-two processes rather than six. So even locally, sessions are talking through the filesystem rather than through a shared service.

**It has no atomic operations**, which is stated plainly in its own documentation. Two agents writing the same file will interleave.

**And it carries no identity**, so nothing records which agent wrote what.

Community servers exist that add a little of this, including shared scratch spaces that record which agent created each entry, but they are small projects storing state in a single file.

## Option Two: A Hosted Drive, And The Scope Paradox

This is where the permissions answer lives, and it is the most useful finding in the research.

The widely used file service divides its authorisation scopes into sensitivity tiers. The narrow scope, which grants access only to files the application itself created, is classified **non-sensitive**. The read-only scope and the read-write scope are both classified **restricted**, the strictest tier.

**That produces a paradox with no middle ground.** The narrow scope is safe and means the agent cannot read documents you already have, which defeats the purpose of sharing an existing working area. The broad scope lets the agent read everything the authorising account can see, and **cannot be narrowed** to a folder.

So the practitioner answer that has emerged is not a permission at all:

> **Create a shared drive dedicated to the agent, and put in it only what you are comfortable with the agent reading.**

That is **granularity by segregation**, and it is worth noticing that it is exactly the conclusion this corpus reached on 14 August about vaults: when possession of access is binary, granularity comes from the shape of what you store rather than from a policy on top of it. The industry has arrived at the same answer for a completely different system, which is reassuring about the principle and unflattering about the tooling.

Two further limitations recorded in the same sources. The first-party connector can find, read, analyse and create files, but has **no tools for moving, renaming or reorganising**, and what it saves lands as an office-format file rather than a native document. And the connector returns whatever the authorising account can see, including anything sensitive in it, unless a separate protection layer is added.

## Option Three: Memory Platforms, And Why Curation Is The Problem

The memo anticipates this and its distinction is right, and sharper than stated. The project lead: **"this can also be mapped as agentic memory, but I think it's important that it's not just the memory, because the memory is a curated version of this. I also want raw file system, raw data, so you can also have provenance and explainability of what the agent is actually doing."**

**The curation is not incidental. It is the product.** These platforms extract facts from conversations and store the extraction rather than the source. One is described as offering automatic memory extraction with a self-editing model that resolves conflicting facts on write.

**Resolving conflicting facts on write is precisely the operation that destroys provenance.** After it runs, you have the resolved fact and not the two things that disagreed, nor which agent said which, nor when. For personalisation that is the desired behaviour. For the explainability the memo wants, it is the failure mode.

The scale of the compression is visible in a published dispute between vendors, where one claims the other's memory footprint can exceed six hundred thousand tokens per conversation against its own figure of roughly one thousand eight hundred. Whatever the truth of that, both numbers describe aggressive curation.

The comparison literature itself names the alternative, and it is worth quoting for what it describes: **maintain the knowledge as files, usually markdown, in a versioned folder, index them, and give agents a query interface and optionally a write-to-a-review-folder interface.** The stated advantages are that knowledge stays portable, humans maintain it with normal tools, and cost is infrastructure only.

That is the fourth option, and it is what the memo already has.

## Identity: Everything Acts As You

The answer to the memo's most important question, and it is unambiguous.

**Connector authorisation is per identity, not per person**, and the connector inherits the authorising account's permissions: it sees what that account can see and nothing more, which is also nothing less.

Three consequences follow directly, and they answer the memo's questions in order.

**Whose identity?** Yours. There is no agent identity in any of these options. Every session authenticated through your connector is you.

**If one agent goes rogue, can it affect the others?** **Yes, entirely.** All sessions share one identity and one permission set, so a compromised or misbehaving session reaches everything every other session can reach. There is no boundary between them because there is nothing to draw one with.

**Can you attribute an action?** **No.** Two sessions writing to the same drive are indistinguishable in the audit trail, because the audit trail records the account. Sources also note that being signed into several accounts at once can confuse the connector about which identity it is acting as, which makes even the account-level record less reliable than it appears.

The practical mitigation available today is the approval prompt: leaving read actions on always-allow while keeping create, edit and delete behind a per-action approval. That is a human in the loop rather than a permission model, and it does not scale to two agents working in parallel.

## Cryptography: Nobody

The memo asks about public and private keys. The project lead: **"whether they support PKI, public and private keys, because that's a great way to implement security, so we can make sure that only the right agents can read, only the right agents can write."**

**None of the surveyed options support it.** Drive and file services authenticate with bearer tokens obtained through delegated authorisation. Memory platforms authenticate with application keys. Repository hosts use tokens. In every case the credential is a shared secret, and possessing it grants whatever it is scoped to.

So the model the memo describes, where messages are encrypted to a recipient and signed by a sender so that only the intended agent can read or write a given step, **is not available in any of them.** That is a genuine gap rather than an oversight in the research, and it is the same gap the brief written earlier today on the relay pattern addresses from the other side.

## Cost

Published figures, and they should be re-verified since this market moves monthly.

| Option | Free tier | Paid | Micropayments |
|---|---|---|---|
| Local protocol server | Free, open source | None | No |
| Hosted drive | Included with the account | Existing subscription | No |
| Memory platform A | 10,000 memories | 19, 79 and 249 per month | No |
| Memory platform B | Self-host free, all features | 20 per month for hosted | No |
| Memory platform C | None; self-hosted edition retired | 125 per month | No |
| Memory platform D | Fully permissive licence, nothing gated | Not applicable | No |
| Edge platform | Private beta | Unpublished; model the underlying units | No |

**No option offers micropayments or per-call billing.** Everything is a subscription or a usage tier billed monthly, which means the per-agent economics the memo is interested in are not currently purchasable. That matches the finding from the payments work of 6 August, that sub-cent settlement is newly possible at the protocol layer and has not yet reached products.

## Deployment

| Option | Self-host | Your cluster | Open source |
|---|---|---|---|
| Local protocol server | By definition | Yes | Yes |
| Hosted drive | No | No | No |
| Memory platform A | Yes | Yes | Core is open |
| Memory platform B | **Yes, free, all features** | Yes | Yes |
| Memory platform C | **No, self-hosted edition retired** | No | Graph engine only |
| Memory platform D | Yes | Yes | Fully permissive |
| Edge platform | No | No | No |

Two things worth noting for the memo's deployment question. **One vendor retired its self-hosted community edition**, which is a reminder that self-hosting is a product decision somebody else can reverse. And **one is free to self-host with every feature**, which makes it the cheapest route to full control if a curated memory model is acceptable.

## The Gap, Stated Carefully

The research answers the memo's question and the answer is that **no available option provides per-agent identity, cryptographic scoping and raw provenance together.**

| Requirement | Best available today |
|---|---|
| Two sessions share files | A hosted drive, or a folder on one machine |
| Each agent has its own identity | **Nothing** |
| One agent cannot reach another's data | **Segregation only: a separate drive per agent** |
| Attributable record of who did what | **Nothing, at the agent level** |
| Encrypted to a specific agent | **Nothing** |
| Raw files with full history | Build it, or a versioned folder |
| Per-call cost | **Nothing** |

Three of those rows are empty, which is a finding rather than an omission.

**The participant note applies**, per the discipline settled earlier today: vaults with per-agent keys address several of those rows, and this brief is written by a party with an interest in that. So the table above is offered as a set of checkable claims rather than a conclusion, each verifiable against the cited sources, and anybody who can fill an empty row refutes it usefully.

## What To Do With This

Three recommendations, in order of what they cost.

**Use the segregation technique today, whatever else happens.** A dedicated shared drive containing only what an agent should see is the only granularity actually available on hosted services, it works now, and it is what the practitioner literature recommends. It costs nothing and it bounds the blast radius that per-identity authorisation otherwise leaves unbounded.

**Do not expect attribution from any of these.** If knowing which agent did what matters, it has to come from the content rather than from the platform: agents writing to their own paths, signing what they write, or both. That is a design decision to make now rather than a feature to wait for.

**And publish this.** It is the concrete instance of the thesis proposed for the identity site earlier today, that the industry answers the question for agents you run and not for agents you rent. This research is that thesis with a specific scenario and checkable evidence behind it, which is exactly the shape that brief asked for.

## What This Does Not Try To Be

- **Not a vendor recommendation.** Four families, mapped against the memo's own criteria.
- **Not a claim that nothing works.** Sharing files works; identity, scoping and attribution do not.
- **Not neutral.** Written by a participant, with the claims made checkable instead.
- **Not durable.** Prices and capabilities here move monthly and should be re-verified.
- **Not the answer.** It is the map; the answer for this case is a design decision.

## Honest Tensions

| Tension | Note |
|---------|------|
| Segregation as the technique | It is the only real granularity available and it means one drive per trust boundary, which multiplies quickly |
| Curated memory | The curation is what makes it useful and it is exactly what removes the provenance being asked for |
| Self-hosting | Two options offer it free and one has already withdrawn it, so it is a product decision somebody else controls |
| The empty rows | They are the finding and they are also what our own work addresses, which is why the claims are made checkable |
| Approval prompts | They are the current mitigation for a missing permission model and they do not survive parallel agents |
| Dated figures | Everything here moves monthly, so the research is only useful with the re-verification discipline attached |

## Open Questions

| Question | Notes |
|----------|-------|
| Does the narrow file scope suffice if the agent creates everything? | It would give real scoping, at the cost of the agent never seeing prior work |
| Can separate authorising accounts give per-agent identity? | One account per agent is segregation applied to identity, and it is worth testing |
| What does the audit trail actually record? | The account is recorded; whether anything distinguishes sessions should be tested rather than assumed |
| Which memory platform preserves sources? | Some may retain the raw alongside the extraction, which would change the provenance answer |
| What would per-call billing require? | Nothing offers it, so it would have to be built on the settlement work from 6 August |
| Is the isolation advice right for this case? | The ecosystem recommends separation and the memo wants sharing, and both may be correct for different tasks |

## Relationship To Previous Briefs

| Date | Document | Relationship |
|---|---|---|
| 16 Aug | `v0.33.59__strategy-brief__nhi-site-two-populations-industry-answers-only-agents-you-run.md` | The thesis this research is a concrete instance of |
| 16 Aug | `v0.33.59__arch-brief__relay-pattern-encryption-signing-and-ordering-are-three-mechanisms.md` | Per-agent keys addressing the empty rows, from the other side |
| 14 Aug | `v0.33.58__strategy-brief__sgit-serialised-pull-request-is-the-headline-publish-the-sample-vaults.md` | Over-broad agent credentials, of which per-identity authorisation is the same problem |
| 6 Aug | `v0.33.56__arch-brief__sg-send-plugins-are-capability-grants-ambient-authority-is-the-injection-root-cause-instrument-before-enforcing.md` | Ambient authority, which is what acting as you means in practice |
| 16 Aug | `v0.33.59__strategy-brief__sgit-comparison-pages-as-reproducible-tests-privileges-is-the-missing-column.md` | The participant discipline and the dating requirement applied here |

---

## Key Claims

| # | Claim |
|---|-------|
| 1 | The ecosystem recommends isolating agents rather than sharing, so the question runs against the tooling |
| 2 | The local protocol server does not span machines, is spawned per session, and has no atomic operations |
| 3 | The narrow file scope is classified non-sensitive and exposes only files the application created |
| 4 | The readable scopes are classified restricted and cannot be narrowed to a folder |
| 5 | The only real granularity is a dedicated drive containing what the agent should see |
| 6 | That is granularity by segregation, the same conclusion this corpus reached about vaults and keys |
| 7 | Connector authorisation is per identity, not per person, so every session acts as you |
| 8 | A rogue session therefore reaches everything every other session can reach |
| 9 | Actions cannot be attributed to an agent, because the audit trail records the account |
| 10 | Nothing surveyed supports per-agent public and private keys |
| 11 | Costs run from free self-hosting to a hundred and twenty-five a month, and nothing offers micropayments |
| 12 | Curated memory resolves conflicting facts on write, which is exactly what destroys provenance |

---

## Sources

- The reference filesystem server exposing read, write, list, search and file information over a local transport as a controlled interface for processes other than the assistant, and its documented lack of atomic operations: https://www.iamraghuveer.com/posts/mcp-filesystem-server/
- The open request for protocol servers to be shared across concurrent sessions, noting that four sessions with six servers currently spawn forty-two processes rather than six, and the community coordination server that assumes a common filesystem path and does not work across machines: https://github.com/anthropics/claude-code/issues/28860 and https://dev.to/sahil_kat/coordinate-multiple-claude-code-sessions-on-a-shared-repo-1dh4
- The recommendation to isolate parallel sessions with separate working directories so agents behave like independent developers, and the stated reason of context confusion when sessions share a workspace: https://www.mindstudio.ai/blog/parallel-agentic-development-claude-code-worktrees
- The scope sensitivity tiers, with the application-created-files scope classified non-sensitive and both readable scopes classified restricted, the observation that the readable scope cannot be narrowed, and the recommended mitigation of a dedicated shared drive containing only material you are comfortable with the agent reading: https://note.com/kenichiro/n/nbec8bbac1cf2?hl=en
- The scope paradox in which narrow scopes prevent the agent reading documents the user already has while broad scopes trigger verification requirements, and the separate permission models for personal and shared drives: https://tapauth.ai/blog/connect-claude-code-to-google-drive-oauth
- Connector authorisation being per identity rather than per person, the absence of tools for moving, renaming or reorganising files, and the office-format output: https://www.usecarly.com/blog/can-claude-access-google-drive/
- The connector inheriting the connected account's permissions and returning whatever that account can see including sensitive content, and the approval-prompt posture of leaving reads on always-allow while gating writes: https://www.strac.io/blog/google-drive-mcp-server and https://www.wiredcio.com/insights/connecting-claude-to-google-drive-scoping-access-and-the-multi-account/
- Memory platform pricing and deployment, including a free tier of ten thousand memories with paid tiers at nineteen, seventy-nine and two hundred and forty-nine per month, free self-hosting with all features against twenty per month hosted, a hosted plan at one hundred and twenty-five per month with the self-hosted community edition retired, a fully permissive licence gating nothing, and an edge offering in private beta with no published pricing: https://ecorpit.com/ai-agent-memory-mem0-zep-letta-cloudflare-comparison-2026/ and https://techsy.io/en/blog/best-ai-agent-memory-tools
- Automatic extraction with a self-editing model resolving conflicting facts on write, and the vendor dispute over memory footprint per conversation: https://evermind.ai/blogs/mem0-alternative and https://fountaincity.tech/resources/blog/agent-memory-knowledge-systems-compared/
- The build-it-yourself alternative described as markdown files in a versioned folder with a local index, a query interface and an optional write-to-review-folder, with knowledge staying portable and cost being infrastructure only: https://fountaincity.tech/resources/blog/agent-memory-knowledge-systems-compared/

---

This document is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0).