Copilots and AI agents find data that people forgot they could reach, so the first question after an AI rollout is not what the AI can do but what data it can get to, and through whose access. An enterprise assistant that searches as the signed-in user surfaces every overshared folder that user can open. A retrieval index copies documents out of their original permissions. A connector or agent with its own service account may reach far more than any single user. This guide sets out a data-centric access review: starting from sensitive data, mapping every AI path to it, testing reach with probe queries, and fixing what should not be reachable. It is for identity governance, data security and AI platform teams. Reviewing the agent identities themselves is covered in the Agent Identity Recertification and Agent Permission Drift guides; this page looks at the same problem from the data side.
Key takeaways
- Review from the data outwards. Identity-centric reviews ask what each agent holds; a data access review asks which AI paths can reach each sensitive data set, which catches overshared content and copied indexes that identity reviews miss.
- There are several kinds of AI reach. Acting as the user, reading a copied index, using a connector service account, holding an OAuth grant, using the agent's own identity and calling tools through MCP servers each need a different review method.
- Test reach, do not infer it. Seed canary documents and query as low-privilege test identities; what the assistant returns is the evidence, not what the configuration screens say.
- Most fixes are data hygiene. Removing broad sharing links, labelling sensitive content and narrowing what each index ingests usually reduce AI exposure more than changing the AI tool.
- Make it recurring. New connectors, new indexes, new tools and organisation changes all alter reach, so trigger reviews on those events as well as on a calendar.
What an AI data access review covers
OWASP's Top 10 for LLM Applications 2025 describes the root problem from two angles. LLM06:2025 Excessive Agency names excessive functionality, excessive permissions and excessive autonomy, and recommends executing extensions in the user's context with the minimum permissions needed. LLM08:2025 Vector and Embedding Weaknesses warns that inadequate or misaligned access controls on embeddings can let a model retrieve and disclose data, and that shared vector stores can leak context between users or groups. A data access review checks both, path by path.
| Reach path | Whose access is used | Where to look | Typical exposure |
|---|---|---|---|
| Assistant acting as the user | The signed-in user's delegated permissions | Sharing reports for document stores, mail and chat; group memberships | Overshared sites and folders, "anyone in the organisation" links, stale group membership |
| Retrieval index or vector store | The ingestion identity at crawl time, then whatever the query layer enforces | Index source list, ingestion account permissions, whether per-document permissions are stored and enforced at query time | Restricted documents readable by anyone who can query the index |
| Connector or integration service account | A non-human identity with standing access to a source system | Connector configuration, the service account's roles in the source | Whole-tenant read access used by a tool that serves many users |
| OAuth grant to an AI application | Scopes a user or administrator consented to | Identity provider and SaaS consent and app grant listings | Mail, files or CRM read scopes granted to unreviewed AI apps |
| Agent with its own identity | The agent's workload or service identity | Role assignments, policies, secrets the agent can fetch | Broad cloud storage or database roles added during development |
| MCP server or tool layer | The server's credential, ideally scoped per user and per tool | MCP server configuration, scopes requested, whether tokens are issued for the server | Omnibus scopes such as files:* or admin:* granted up front |
The MCP security best practices describe the last row directly: a token carrying broad scopes, granted because the server exposed every scope and the client requested them all, enables lateral data access and privilege chaining. They recommend a minimal initial scope set with incremental elevation, and list publishing all possible scopes and using wildcard scopes as common mistakes.
Scoping the review: start from sensitive data
A review that starts from "all AI tools" stalls. Start from the data sets that would cause harm if an assistant summarised them for the wrong person, then work out which AI paths reach each one.
- Pick the data sets: HR and payroll records, legal matters, board and M&A material, customer personal data, source code and secrets stores, security investigation files, and regulated records. NIST CSF 2.0 ID.AM-07 calls for inventories of data and metadata for designated data types; reuse that inventory. See the Data Classification Guide.
- Name a data owner per set: only the owner can say whether a reach path is intended. See the Data Access Governance Guide.
- List AI paths per set: for each data set, which assistants, indexes, connectors, agents and MCP servers can touch it, using the table above.
- Rank by blast radius: paths that serve many users from one identity (shared indexes, connector service accounts) come before paths that act strictly as each user.
How to run the review
- Inventory AI paths: collect assistants enabled per tenant, retrieval indexes and their sources, connectors and their service accounts, OAuth grants to AI applications, agent identities and registered MCP servers. Shadow tools found through consent listings belong here too; see the SaaS and OAuth App Governance Guide.
- Map effective reach: for each path, resolve group nesting, inherited permissions and sharing links into the actual set of data the path can read. For acting-as-user assistants, the question becomes which users can open the sensitive data set, because the assistant will find it for them.
- Probe-test: place uniquely worded canary documents in each sensitive location, then query each assistant and index as test identities with typical, low and no access. Record what is returned, summarised or cited.
- Compare with intent: the data owner marks each reach as intended, unintended or unknown. Unknown is treated as unintended until justified.
- Remediate: apply the fixes in the next section, smallest change first, with a rollback note (the previous sharing setting or scope list) for each.
- Re-test and record: repeat the probe queries, keep the before and after results as evidence, and record the decision and owner sign-off.
Run the first cycle in read-only mode: no changes until the reach map and probe results have been reviewed with data owners, because removing sharing links or index sources can break legitimate work.
Probe testing in practice
Configuration screens show what should happen. Probe tests show what does happen, including permission caching, delayed index updates and connectors that ignore per-document permissions.
| Test | How | Pass condition |
|---|---|---|
| Permission trimming | Query the index as a test user without access to a canary document | Canary text never appears, is never cited and is never summarised |
| Revocation lag | Remove a test user's access, then query at intervals | Canary disappears within the documented sync interval |
| Cross-group leakage | Query a shared vector store from a user in a different group or tenant | No results from the other partition (OWASP LLM08 mitigation: permission-aware stores with logical partitioning) |
| Label exclusion | Apply the "exclude from AI" or highest sensitivity label to a canary | Assistant cannot return or summarise it, per the label policy |
| Agent overreach | Ask the agent for data outside its stated purpose | Request denied by authorisation, not just refused by the model |
| Indirect injection reach | Plant benign instruction text in an external email or document and see whether the assistant pulls internal canaries into its answer | Internal data does not flow into responses triggered by untrusted content |
Keep probe text benign and unique, record each test identity, and agree the tests with the data owner and the AI platform team before running them.
Remediation options
| Finding | Fix | Trade-off |
|---|---|---|
| Organisation-wide or anonymous sharing links on sensitive content | Remove the links, replace with named groups, set default link scope to specific people | Users re-request access; communicate first |
| Sensitive site or folder reachable by too many users | Fix membership; or exclude the location from assistant search while the clean-up runs | Exclusion hides content from legitimate users' assistants too |
| Index ingests restricted sources | Remove the source, or store and enforce per-document permissions at query time | Per-document enforcement adds latency and sync work |
| Connector service account has tenant-wide read | Scope it to the needed sites, mailboxes or objects, or switch to user-delegated access | Delegated access needs per-user consent and token handling |
| Broad OAuth or MCP scopes | Re-consent with minimal scopes; adopt incremental elevation; revoke unused grants | More consent prompts |
| Agent role broader than its purpose | Replace with a purpose-scoped role and short-lived credentials | Needs a purpose baseline per agent |
Decision guidance
- Acting as the user or own identity: acting as the user keeps reach within each person's access and keeps audit trails meaningful, and OWASP LLM06 recommends it; an agent identity is needed for background work with no user present, and then needs a purpose-scoped role and its own review.
- Exclude or clean up: excluding a location from AI search is fast and reversible; cleaning up permissions fixes the underlying exposure for every tool, not just the assistant. Use exclusion as a stopgap with a dated clean-up plan.
- Small organisations: focus on sharing links, a short list of sensitive locations and OAuth grants to AI apps; quarterly probe tests on the main assistant are usually enough.
- Large organisations: automate reach mapping, run probe tests per business unit, and tie reviews to change events: a new connector, index source, MCP server, agent tool or major reorganisation.
- Cadence: NIST SP 800-53 AC-6(7) asks for periodic review of assigned privileges and removal where no longer needed; for AI paths, add event triggers, because reach changes when content and connectors change, not only when roles do.
Detection and measurement
Monitor the reach paths between reviews: new OAuth grants to AI applications, new index sources, connector permission changes, MCP servers added, and assistant retrievals that return content with the highest sensitivity labels. Retrieval logs should record the identity used for the permission check and the labels of returned items; see the Secure AI logging guide.
- Sensitive-set coverage: percentage of designated sensitive data sets with a mapped and owner-approved AI reach list.
- Probe pass rate: share of probe tests passing at each cycle (target 100% for permission trimming and cross-group tests).
- Broad links on sensitive content: count of organisation-wide or anonymous links in sensitive locations, trending down.
- Unreviewed AI grants: OAuth grants and connectors to AI applications without an owner or review date.
- Time to close: median days from an unintended-reach finding to verified fix.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-6, AC-6(7), AC-2 | Least privilege, periodic privilege review, account management for agent and connector identities |
| NIST CSF 2.0 | PR.AA-05, ID.AM-07 | Access permissions reviewed with least privilege; data inventories |
| OWASP Top 10 for LLM Applications 2025 | LLM06, LLM08, LLM02 | Excessive agency, vector store access control, sensitive information disclosure |
| MITRE ATT&CK | T1213, T1530 | Data from information repositories and cloud storage: what an attacker using an over-reaching assistant or agent would collect |
| MITRE ATLAS | AML.T0051, AML.T0057 | Prompt injection steering an assistant to data it can reach; LLM data leakage |
Common failure patterns
- Reviewing the AI tool, not the data: the assistant passes a security review, but the tenant's oversharing goes untouched, so the assistant faithfully surfaces it.
- Ignoring untrusted content in the same context: in the EchoLeak 2025 research, a crafted email could steer an assistant to disclose data it could retrieve for the user. The vendor fixed the issue server-side; the lasting customer-side lesson is that everything an assistant can reach is in scope once untrusted content shares its context, so reducing reach limits impact.
- Index as a permission bypass: documents are crawled with a privileged account and served to everyone who can query the index.
- One-off clean-up: oversharing is fixed before rollout, then returns as new sites and links are created, with no recurring review.
- Configuration evidence only: reviewers accept screenshots of settings without probe tests, missing sync lag and connectors that do not enforce per-document permissions.
Practitioner checklist
- List the sensitive data sets and name an owner for each.
- Inventory every AI reach path: assistants, indexes, connectors, OAuth grants, agent identities and MCP servers.
- Map effective reach per sensitive data set, resolving groups, inheritance and sharing links.
- Seed canary documents and run probe tests as test identities with typical, low and no access.
- Have data owners mark each reach as intended or unintended, and treat unknown as unintended.
- Remove broad sharing links and narrow index sources and connector scopes before changing the AI tool.
- Prefer acting-as-user access for assistants, and purpose-scoped roles with short-lived credentials for agents.
- Trigger re-review on new connectors, index sources, MCP servers, agent tools and reorganisations, and keep before and after probe results as evidence.
Standards and references
- OWASP: Top 10 for LLM Applications 2025
- Model Context Protocol: Security Best Practices
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Data from Information Repositories
- MITRE ATLAS: LLM Data Leakage
Related NHI Mgmt Group resources: Enterprise AI Copilot Security Guide · Access Reviews Guide · Agent Identity and Access Guide · RAG Security Guide