Data Access Is the Real Integration Project

Here's a small puzzle from Microsoft's own documentation. An app has been granted a permission called Files.Read.All. How many files can it read?

Either. The same name exists in two versions. In the delegated version, the app acts for a signed-in person and can read only the files that person could open. In the application version, the app acts as itself and can read every file in the company's tenant. Same name in the configuration screen. The difference is a few thousand files versus every contract, salary sheet and board pack the company owns.

That puzzle is the whole story of putting AI to work inside a company, in miniature. An AI assistant is only as useful as what it is allowed to see and do, and that permission is granted by people whose job is to say no carefully. Writing the integration code takes days. Earning the right to run it on real data can take months, and some projects never get there. The hard question is rarely whether the model can do the work.

One assistant, six vetoes

Take a mid-sized company whose accounts-payable team wants an assistant. Vendors email asking when they'll be paid, invoices don't match purchase orders, approvals sit in inboxes, and at month end someone has to explain why the numbers moved. The assistant should answer vendor questions, match invoices to orders, chase approvals and draft the month-end notes. Current models do this kind of reading well.

To do it, the assistant needs four systems. Email, at least the shared accounts-payable mailbox. The ERP, the enterprise resource planning system that holds the official record of vendors, orders and payments. The document drive where contracts and policies live. The CRM, because some vendors are also customers. And a fifth party appears the moment any of this reaches a model: the AI vendor, which will receive every email and invoice that lands in a prompt.

Each of those has an owner. Microsoft 365 belongs to IT. The ERP belongs to finance systems, with the controller watching anything that touches money, because of a basic control auditors check called segregation of duties: the same actor shouldn't be able to create a vendor and approve a payment to it. The CRM belongs to sales operations, and since customer contacts are personal data, privacy joins in; in Europe that means a written data processing agreement with every vendor that handles them. The AI vendor needs security, legal and procurement.

The integration code reads from four systems. The access request needs at least six owners, each with a veto.

Nobody in that list can say yes to the whole thing. That is where many promising assistants stall, and the model has nothing to do with it.

Whose permission is the agent using?

Every access decision reduces to one question: when the assistant reads something, whose permission is it using? There are two classic answers and a third arriving.

Acting for a person. With delegated access, the agent's effective permission is an overlap. The app's granted scopes set the most it could do for anyone; the person's own rights set what this person may do; the agent gets only what's in both. Microsoft's documentation puts it plainly: the app can never exceed the user's permissions, and the user can never exceed the app's.

That makes delegated access the natural default for an assistant that serves a person. When Ana from accounts payable asks a question, the assistant sees what Ana sees. When her account is disabled, the assistant loses her access. The logs show the app acting for Ana. It respects every access rule the company already has.

Acting as itself. A service account is an identity for the software, with its own permissions and no person behind it. It's the simple option, and the dangerous one. If the assistant runs on a service account that can read every file in finance, then every person who can type into the assistant can effectively read every file in finance, whatever the drive's permissions say. Security engineers call this a confused deputy: a component with broad authority acting on requests from people who don't have it.

Scroll sideways to see the whole figure

An identity for the agent. Identity platforms are now adding a third category. Microsoft's Entra Agent ID, generally available in 2026, gives agents their own identities with a human sponsor, and lets administrators set different rules for agents acting for a person and agents acting on their own. The underlying standard, OAuth token exchange, lets a service trade a person's token for one that names both the person and the agent working for them. The gain is a log line that reads "agent X, acting for Ana, read invoice 4471", which is far more useful than "Ana read it" (false) or "the integration account read it" (useless), and an agent that can be switched off without touching Ana's account.

My advice is simple: act for the person wherever you can. Use a service account only where a system offers nothing else or the job belongs to no one, and then make it small: one role, read-only, named resources, a credential that rotates.

An answer is a disclosure

Most first assistants are built on retrieval. Documents are copied into a search index; when someone asks a question, the most relevant passages are pulled out and the model answers from them.

Here's the trap. When you copy a document into an index, you copy it out of the system that enforced its permissions. SharePoint knew who could open the salary file. Your index, unless you built it to, doesn't.

Now an accounts-payable clerk asks, "What's the bonus pool this year?" The retriever finds the most relevant passage, which sits in an HR spreadsheet the clerk could never open, and the model summarizes it helpfully, with a citation. Nobody hacked anything. The answer is a data leak with good formatting.

The fix is called permission-aware retrieval. Each passage in the index carries the access list of its source document, each question carries the identity of the person asking, and the retriever filters before it ranks, so the model never sees a passage the asker couldn't have opened. Simple to state, fiddly to keep right, because access lists change after indexing and groups nest inside groups.

And defaults don't help. Microsoft's documentation says its synced Copilot connectors, which copy outside content into its index, are tenant-wide unless someone restricts them, and one of its sample connectors makes ingested content visible to everyone in the organization. Point that at a contracts repository and every employee can read every contract.

There's a deeper twist. Permission-aware retrieval enforces the permissions you have, not the ones you should have. In many companies the drives are full of old mistakes: a board pack shared with "everyone" for one meeting three years ago, a salary file in a folder that inherited a broad group. People never stumble on them. A search-backed assistant finds them in a second.

An assistant that respects permissions perfectly will still expose every permission that was wrong.

That's why the first real output of many AI rollouts is a permissions cleanup. I'd treat that as a gift to IT rather than a delay: the oversharing was already there, and fixing it makes the company safer whatever happens to the assistant.

Why the people saying no are right to

It's tempting to treat security review as friction. A security team is rarely praised for the projects it enabled and is blamed for the incidents it didn't prevent. If it approves an assistant that leaks the salary file, the incident is its own. If it delays the assistant a quarter, the cost is spread thin across people who will complain and move on. Careful refusal is the rational answer to a vague request, and AI requests are vague exactly where it matters: broad access, behavior nobody can fully specify, and inputs that outsiders can write.

So stop trying to win the argument and change the request until yes becomes the safe answer. An easy request has the same four properties whatever the system:

• Scoped. Named resources (this mailbox, these two sites, this company code), the minimum permissions for the first use case, nothing company-wide.
• Reversible. Read-only first. When writes arrive, drafts a person sends, or changes that can be undone.
• Logged. Every retrieval and action recorded against the agent and the person it acted for, in the company's own systems.
• Revocable. A named owner, an expiry date, and a tested way to turn it off.

Read-only does more work than people expect. A read-only assistant can still be wrong and can still leak what it reads, but it can't pay a vendor or send an email that commits the company. The approver's worst case drops from "money moved" to "someone saw something." And most of the finance assistant's early value, answering vendor questions, flagging mismatches, drafting notes, needs no writes at all.

The last property hides a surprise. "We'll just revoke it" is slower than anyone assumes. Depending on the mechanism, Microsoft documents delays of up to 15 minutes, 60 to 90 minutes, or two hours, and more than a week for hiding a very large SharePoint site from Copilot. If the approver's real question is how fast this can be stopped, the honest answer has to live in a layer the project controls: a small gateway in front of the agent's tools that checks, on every call, whether this agent, this person and this action are still allowed, with a switch that stops everything on the next request. That is modest engineering, and it answers the question that actually decides the review.

These boundaries are walls, in the sense of Same Model, Different Results: they don't loosen when a better model arrives, because they encode who is allowed to know what.

What permissions can't stop

Good permissions have a limit, and it's worth being precise about it.

In June 2025 researchers disclosed EchoLeak, a flaw in Microsoft's Copilot that Microsoft rated critical and fixed. An attacker sent an ordinary-looking email with instructions addressed to the assistant hidden inside. The user never had to open it. Later, when the user asked Copilot a normal work question on a topic the email had been written to match, Copilot retrieved that email as context, followed the hidden instructions, and sent internal data out through an image link. Copilot didn't break a single permission. The data at risk was data the user could already see. It left anyway.

This is prompt injection, and as of October 2026 there's no general fix: models can't reliably tell instructions they should follow from text they should only read. The finance assistant is exposed by design, since anyone in the world can email a vendor mailbox. So on top of good permissions, strip the outbound channels the assistant doesn't need (external images, arbitrary links), keep writes behind human approval, and separate the part that reads untrusted email from the part that can act (Giving an Agent Room to Work). Permissions decide how much can leak. These measures decide how easily it can.

Climb a ladder, one rung at a time

A competent engineer will propose skipping all this: build against a sandbox with fake data, prove it works, then ask for real access.

A sandbox is the right place to build the plumbing, and nothing in it can leak. But synthetic data is clean in exactly the ways that hide both the value and the risk. Real accounts-payable work is full of duplicate vendor records, half-empty purchase orders, invoices scanned at an angle, vendors replying to the wrong thread, and exceptions only one person understands. That mess is where the assistant earns its keep or fails. A sandbox proves the system runs. It can't prove the system is worth the access it will eventually need.

The answer is to stage access so each step produces the evidence the next approval will ask for.

Scroll sideways to see the whole figure

1. Sandbox, synthetic data. Proves the plumbing, logging and failure handling. No grant needed.
2. Read-only on real data, tightly scoped. One mailbox, one ERP company code, two document sites, acting for the person where possible. Proves accuracy on the real mess and gives a first estimate of value.
3. Supervised write. The assistant drafts replies and proposes matches; a person approves each one. Proves the acceptance rate, the kinds of errors, and that reversal works.
4. Autonomous within limits. Routine payment-status replies go out and small matches get posted; everything else goes to a person, and the limits are enforced outside the model.

Each rung asks for a little more and arrives carrying proof from the rung below, so the next request is a modest extension of something already working (Moving Without Breaking).

What I'd do

Start the access work in week one. File the access requests, the vendor security questionnaire and the processing agreement on day one, in parallel with building in the sandbox. The review will usually be the longest task in the plan. Building first and asking later turns a three-month review into a three-month idle team.

Ask what's already approved. If the company has already put Microsoft Copilot or Gemini in Workspace through security, legal and procurement, a first version built on that platform inherits its identity model, logging and contract, and the review covers only the new connectors. Two cautions: the approved platform may not fit the use case, and approvals drift. Microsoft keeps EU users' Copilot traffic inside its EU data boundary, yet as of October 2026 models from Anthropic running inside Copilot are excluded from it. A vendor adding a model can change what you approved, so give approvals a review date.

Write the access map before the code. For each system: what the assistant needs, under whose identity, with what scope, and who signs. If a row has no owner, that's your critical path.

Ask for the smallest useful yes. Scoped, reversible, logged, revocable. Read-only first. Never a company-wide grant because it was easier to configure.

If you sell AI to companies, put the permission model in the product. Delegated access, minimal scopes, confinement to named resources, logs that go to the customer's systems, and an off switch in the customer's identity provider give the reviewer less to refuse than a better model without them (Where the Moat Moves).

The models in this story will change several times before the finance assistant reaches its fourth rung. The access map, the scoped identities, the audit trail and a revocation drill that worked won't need rewriting when they do. They're what the integration project actually builds, and they make the next project faster.

Check yourself

Why can an assistant on a broad service account leak data without any hack?

Anyone who can type into the assistant can effectively read what the account can read, whatever the drive's permissions say. This is a confused deputy.

Why is an answer a disclosure?

Copying documents into a search index copies them out of the system that enforced permissions, so the retriever must filter by the asker's access before it ranks.

Why start the access work in week one?

The review is usually the longest task in the plan. Building first and asking later turns a three-month review into a three-month idle team.