Shared drives for agents: everything acts as you

The site's thesis, tested against a concrete scenario: give two agent sessions a shared working file area — whose identity does it run on, can one rogue session reach the other's data, can you attribute an action, and do per-agent keys exist? The answer, scored against public sources: everything available runs on your identity, the only granularity is segregation rather than scoping, and nothing supports per-agent keys. Three requirement rows come back empty — which is the finding, not an omission.

The short answer

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

Notably, the ecosystem's dominant advice is the opposite of the question: isolate parallel sessions in separate working directories so they behave like independent developers. Sharing runs against the grain of the tooling — which is not a reason not to want it, and does explain why the options are thin.

Identity: everything acts as you

The finding with the largest blast radius. Connector authorisation is per identity, not per person, and inherits the authorising account's permissions. Three consequences, answering the scenario'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 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 — and multi-account sign-in can confuse even that record.

This is the two-populations thesis in a single scenario: these are rented agents, nothing can be attested, and the one lever is the credential handed over — which turns out to be your entire identity. It is also the authorization-closure problem in its purest form: the grant says "the drive", the closure is "everything your account can see".

The scope paradox, and granularity by segregation

The widely used file service classifies its narrow scope (files the application itself created) as non-sensitive, and both readable scopes as restricted — with nothing in between. The narrow scope means the agent cannot read anything you already had, defeating the purpose of a shared working area; the broad scope exposes everything the account can see and cannot be narrowed to a folder. 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: when possession of access is binary, granularity comes from the shape of what you store, not from a policy on top of it. The corpus reached the same conclusion about vaults and keys on 14 August — the industry has arrived at the same answer for a completely different system, which is reassuring about the principle and unflattering about the tooling. The cost is real: one drive per trust boundary multiplies quickly.

Cryptography: nobody

Nothing surveyed supports per-agent public and private keys. Drive and file services authenticate with bearer tokens; memory platforms with application keys; repository hosts with tokens. In every case the credential is a shared secret, and possessing it grants whatever it is scoped to. The model where a step is encrypted to a recipient and signed by a sender — so only the intended agent can read or write it — is not available in any of them.

Memory platforms: curation destroys provenance

Curated memory is not raw shared files, and the difference is sharper than it looks: memory platforms extract facts and resolve conflicting facts on write — which is precisely the operation that destroys provenance. After it runs you have the resolved fact, not the two things that disagreed, nor which agent said which, nor when. For personalisation that is the desired behaviour; for explainability it is the failure mode. The alternative the comparison literature itself names — markdown files in a versioned folder, indexed, with a query interface and a write-to-review-folder — keeps the raw record, stays portable, and costs only infrastructure.

The gap, stated carefully

Anybody who can fill an empty row refutes this usefully — tell us. The three empty rows are what a per-agent key registry would address: the design for one, derived from the documented 2019 keyserver failure, is scoped in the PKI section — identity and mandate as separately revocable signed statements is the direct answer to "everything acts as you".

What to do with this, today

1. Use segregation, whatever else happens. A dedicated drive containing only what an agent should see is the only granularity actually available on hosted services. It costs nothing and bounds the blast radius that per-identity authorisation otherwise leaves unbounded.
2. Do not expect attribution from the platform. If knowing which agent did what matters, it must come from the content: agents writing to their own paths, signing what they write, or both. A design decision to make now, not a feature to wait for.
3. Treat the isolation-vs-sharing tension as real. The ecosystem recommends separation; some tasks genuinely need sharing. Both can be right for different tasks.

Sources and re-run method

All fourteen sources — the scope-tier documentation, the connector permission analyses, the memory-platform pricing surveys, the isolation guidance, and the protocol-server limitations — are cited in the source brief, readable on its document page. Re-run method: re-check each cited page's claims against the vendor's current documentation, and re-score the two tables above; the figures move monthly.