Data Rooms for AI Agents: What to Let an Agent Do, and What Never to Let It Do

An AI agent data room is a data room an agent can drive with a key and a command instead of a browser: it reads which documents are still missing, finds them, uploads each one against the item it satisfies, and re-reads the list to confirm the gap closed. That access exists today at several vendors, so the interesting question is no longer whether an agent can operate a room. It is which actions an agent should be permitted to take at all, and how the credential is scoped so it cannot take the others.

Start with that split, because it is the entire design.

The line has nothing to do with how capable the model is. It tracks which actions are additive and reversible, which are destructive, and which disclose confidential material or put a decision on the record. An agent that files a document in the wrong folder costs someone two minutes. An agent that emails a share link to the wrong address ends a deal.

Why the permission line falls where it does

Three categories, and they behave differently under failure.

Additive and reversible. Uploading, creating folders, attaching a document to a checklist item, reading an inventory. When the agent is wrong, the room holds an extra file in the wrong place. A human sees it, moves it, and nothing left the building. This is where an agent earns its keep, and it is the most tedious part of standing up a room.

Destructive. Deleting a document or a folder. The failure mode is silent, and recovery depends entirely on what the product does with a deletion. Ask every vendor the same question: when a folder is deleted, what happens to the documents inside it? In our data room, deleting a folder moves its documents to Unsorted and never deletes them, and the client asks for confirmation unless you pass a flag saying you know what you are doing. That design predates agents, but it is the reason an agent can hold a delete permission without it being reckless.

Disclosive or on the record. Granting access, sending an invitation, changing what a share link permits, or marking a diligence item complete. Each one either puts confidential documents in front of a human being or records a judgment the other side will rely on. These are not agent actions at any capability level, and the last section explains why that is structural rather than a limitation waiting to be lifted.

Which data rooms can an agent actually reach today?

More than the "nobody has built this" framing suggests. Everything below was read on August 1, 2026.

Datasite states on its diligence product page that you can connect Claude, ChatGPT, or Microsoft Copilot through MCP, with data staying inside Diligence. Its public AI organization also publishes an agent skills repository describing eight coordinated skills for sell-side deal teams, including index setup and matching an information request list against room content, and its stated requirements name Claude Code as a supported host.

Ideals promotes an MCP connector in the top banner of its homepage, connecting Claude, Copilot, and ChatGPT to the data room. On its pricing page, that connector and an API integration add-on sit under the Enterprise tier, which is worth noting: at some vendors, agent reach is a pricing decision rather than a product one.

DealRoom advertises an MCP integration on its pricing page for connecting deal data to any MCP-compatible AI.

Papermark, a data room vendor, publishes an MCP server on npm from its own scope and its own repository, declaring a runnable executable, last published on July 27, 2026.

Two observations about the shape of that race.

First, MCP and a command line client are different access surfaces, and no established deal VDR publishes a command line client on npm, checked August 1, 2026; the vendor-by-vendor check is in our piece on the data room command line client. Do not read that as a moat. Box publishes an official command line interface for the Box API on npm under its own maintainer accounts, last published June 1, 2026, and Box sells a virtual data room for managing mergers on its own site. Read "data room vendor" at its plain meaning and the gap closes.

Second, look at who published the package. A CLI named papermark-cli exists on npm and describes itself as an agent-first CLI for data room workflows, but an individual publishes it from a personal repository, not the vendor. That distinction matters more for an agent than for a person: a community wrapper holds your credential, tracks the vendor's API on its own schedule, and answers to nobody when it breaks mid-process.

How do you scope a credential so an agent cannot touch the wrong room?

This is where a design either exists or does not, and it is the question I would put first in any vendor call.

In our data room, an agent needs one environment variable and nothing else. Set MAGE_API_KEY and skip the login step entirely; the client discovers which room the key belongs to on first use. That is the documented path for agents and for continuous integration, and the reason it matters is negative rather than positive: the agent never holds a browser session, never drives a UI, and never runs as you.

What a room-scoped key can and cannot do:

• It acts in its own room only. It cannot reach another room in your organization.
• It carries the permission set chosen when it was minted, and those permissions are immutable. Widening a key means minting a new one, which is a deliberate human act with its own record.
• It cannot delete the room.
• It cannot change room settings, people, or sharing without a Manage room permission that is not granted by default.
• It cannot fetch document contents without a Download permission. Reading the document list and reading the bytes are two different grants.
• Revoking it under Settings, API keys kills it everywhere instantly.

The secret itself is returned exactly once, at creation. What the room records is: the room binding, who minted it, a snapshot of its permissions, and the audit trail. On a developer's machine, the client keeps its credential in a config file readable only by that user.

The practical version is short. Mint the narrowest key the task needs, hand it to the agent, revoke it when the task is done. A browser login cannot offer that, because it carries every permission you hold in every room you can see, for as long as the session lives.

Does agent access break the audit trail, or improve it?

It improves it, and this is the claim I expect to argue about.

Consider the honest baseline in a live process. An associate is signed into an account several people know the password to. A session is open on a laptop in a conference room. Views and downloads land on the room's log attributed to whoever's session it was, which is frequently not the person who did the work. Nobody calls that an audit failure because it is what everyone has always done.

A scoped key inverts it. The credential is minted for one purpose, named for the machine it lives on, listed in the room's settings with its permission set and the person who created it, and revocable in one click. Every file it downloads lands on the room's access audit trail like any other. When something goes wrong, three questions have answers a shared login cannot produce: what was this credential allowed to do, what did it actually do, and who authorized it.

The serious objection is not that agents are unaccountable. It is that they act quickly and at volume, so a mistake propagates before anyone notices. That is real, and its answer is the same mechanism: narrow the permission set, keep revocation one click away. Both are properties of the credential, not of the model.

What the loop actually looks like

Four steps, and the third is the only one that is not obvious.

1. mage readiness --json returns the room's checklist as machine-readable items. Each carries an id, a label, a status of missing, partial, or present, and a hint describing what the item should contain.
2. The agent finds those documents with its own tools, wherever they live.
3. mage upload <file> --for-item <itemId> uploads the file and attaches it to that checklist item in one call.
4. mage readiness --json again, to confirm the item closed. Repeat until nothing required is missing.

Every command accepts --json and emits machine-readable output on stdout. That is the boring detail the whole loop rests on. A tool an agent has to screen-scrape is a tool an agent cannot verify, and an agent that cannot verify its own work is just a faster way to produce a mess.

Step three changes the character of the work. Uploading a file is a blind action; uploading it against the item it satisfies is a claim that can be checked. When the agent finishes, the room's own checklist is the report card, in the same view a human would have read anyway.

The product ships the prompt, so nobody has to write one. The key-based version reads:

Fill my Mage data room. With MAGE_API_KEY="<key>", run npx @magelegal/cli readiness --json to see which checklist items are missing, find those documents in my files or other services, and upload each one with npx @magelegal/cli upload <file> --for-item <itemId> until nothing required is missing.

A realistic task on top of that: pull last year's tax return from our accounting system and satisfy the missing tax items in the readiness checklist.

The client is @magelegal/cli, MIT licensed, public source, Node.js 20 or newer, and runnable with npx without installing anything. The command reference, flags, and the human-at-a-terminal walkthrough live in the Mage data room CLI. One boundary worth stating plainly: this client drives the data room only. Mage's diligence platform has no command line surface, and I would rather say that here than have you discover it after a purchase.

Why does a browser-only room become the bottleneck?

Because everything on either side of it is already scriptable.

The documents originate in systems with APIs. Cap tables, financial statements, payroll exports, signed agreements, board consents: they live in software an agent can already reach. Downstream, review is software too. What the room does to a document once it lands, meaning typing, filing, numbering, and gap-checking, is covered in AI data rooms, and the handoff from a full room into diligence is covered in from data room to diligence workflow. The room in the middle is the only step that has traditionally required a person, a mouse, and an afternoon. When the two steps around it are automated, the manual one stops being a step and starts being a queue.

There is a worse version of solving this, which is pointing a browser-driving agent at the room's UI. It works in a demo. It is brittle against any interface change, it is slow, and above all it runs inside a human's full session, which puts you back at every permission that person holds in every room. UI automation is not agent access. It is a person's credential with a robot's hands.

What must a human still sign off on, and why is that permanent?

Because models produce confident wrong answers, and in diligence a confident wrong answer is worse than no answer. A tool that says nothing is missing, and is wrong, does not merely fail to help. It removes the item from the reviewer's attention. That asymmetry does not go away with a better model, so the design has to absorb it.

Three things stay human in our room by construction rather than by policy.

Who gets access. Invitations mint one personalized link per recipient and email it to them, and every view on that link is attributable to the person it was issued to. That is a decision about who sees confidential material, which means it belongs to a person who can be asked why.

What a link permits. Whether it requires an NDA, whether it carries a watermark, whether it allows download, whether printing is allowed separately from download, and when it expires. These are per-link settings a human chooses. On the watermark specifically: per-viewer stamping puts the viewer's identity and the date on every page, and it is a deterrent, not an access control. Anyone selling watermarking as leak prevention is selling you something.

Telling other people the room changed. Reading the readiness checklist and curating individual items accept a room-scoped key, which is what lets an agent attach what it uploads. Triggering a recompute and notifying people are gated to a signed-in human. The split is deliberate: an agent may do the work, and a person decides when the work is announced. The same reasoning is why the table at the top says an agent should attach documents to an item but should not be the one declaring the item done, even where the credential would permit it.

That is not a temporary boundary awaiting a smarter model. It is the same boundary that governs a first-year associate, drawn in software instead of in a supervision policy.

Where to start

Run the loop against a real room and see whether it holds up. Our data room is free for a limited time and self-serve, so you can hand a key to your own agent this afternoon without talking to anybody: it is at the Mage Data Room page. Mage is SOC 2 Type II certified, which covers the security controls and says nothing about whether your agent filed a document correctly, which is exactly the point of keeping the checklist as the report card.

The rest of our writing on how these rooms should work sits in the data rooms topic hub.