Enterprise AI assistants sold as copilots do not create new access rights. They surface what an account can already reach, faster than a person ever could. Auditing those permissions before deployment is the main security task, and most of it is ordinary admin work.
Gather the access and information you need
Before starting, you need administrative access to the systems the assistant will connect to: the identity provider that issues accounts, the document store or file shares it will index, and the audit or logging console for that platform. You also need a current list of licensed users, or at least the pilot group, and an owner for each major data repository who can answer questions about who is supposed to have access.
Have to hand any existing data classification scheme, however informal, and your organisation’s records of what counts as personal data under data protection law. If none exists, expect the audit itself to produce a rough one, because you cannot decide what an assistant should not summarise until you know what is sensitive.
Finally, set aside time. On a large estate this is not an afternoon’s work, and the useful output is not a switch flipped but a list of repositories that turn out to be readable by far more people than anyone intended.
Map what the assistant will be able to reach
Start by picking one pilot account and enumerating everything it can open: mailboxes, shared drives, team sites, chat histories, wikis, ticketing systems and any connectors to third-party tools. An assistant grounded in organisational data will generally treat all of it as fair material for an answer.
The point of the exercise is to move from theoretical permissions to practical reach. A folder that a person would never think to open is, to a retrieval system, simply another indexed document. Write the inventory down. Where a system’s permissions cannot be enumerated cleanly, record that as an unknown rather than assuming it is fine.
Close the oversharing gaps before you buy licences
Most organisations that run this audit find the same pattern: sharing links created years ago that grant access to anyone in the organisation, sites with default membership set too wide, and archived project folders nobody owns. These are pre-existing problems. An assistant does not cause them, but it removes the practical obscurity that has been hiding them.
Revoke or time-limit broad sharing links, reset default sharing to the most restrictive setting that still works, and assign an owner to every repository that will be in scope. Where a site cannot be fixed quickly, exclude it from indexing rather than leaving it in and hoping.
Label and classify the material that must stay restricted
Classification labels are the mechanism most enterprise platforms use to keep specific content out of assistant responses, or to ensure that anything generated from labelled material carries the same restrictions. Apply labels to the categories that would cause real harm if summarised into a chat window: HR case files, board papers, legal advice, security documentation, salary data, health information.
Automated labelling based on content patterns is available on some platforms and is worth using, but treat its output as a first pass. Check a sample by hand. A label applied to the wrong things is as much of a problem as no label at all, because people will start working around it.
Narrow the search scope for the pilot
Rather than exposing the whole estate on day one, restrict the assistant’s retrieval scope to a defined set of repositories that you have already audited. Several enterprise platforms support this directly through a permitted-sources list; where yours does not, achieve it by excluding content from the index.
This makes the pilot answerable. If something inappropriate surfaces, you know which repository it came from. Expanding the scope afterwards, one repository at a time, is slower than switching everything on, and considerably easier to explain when someone asks how a document ended up in an answer.
Switch on auditing and read the logs
Confirm that prompts and responses, or at least the identity of the documents retrieved, are recorded in your audit log, and check the retention period on those records. Verify that the logs are actually being written by running a test query and finding it.
Then read them. The first weeks of a pilot show what people genuinely ask an assistant for, which is rarely what the deployment plan assumed. The logs are also the only way to answer, after the fact, whether a particular file was ever surfaced to a particular person — a question that arrives eventually, usually from a lawyer or a regulator.
Test the assistant against hostile content
An assistant that reads documents and emails will also read instructions hidden inside them. Indirect prompt injection — text placed in a file, web page or message that the model treats as a command rather than as content — is a recognised weakness of retrieval-based systems, and there is no complete fix for it.
Test it deliberately. Place a document in the pilot scope containing instructions aimed at the model, then ask a question that causes the assistant to retrieve it. Repeat with any connector that pulls in external content, which is where untrusted text most often enters. What you learn determines how much the assistant should be allowed to do automatically, as opposed to drafting something a person then approves.
Write the rules people will actually follow
Publish short, concrete guidance: which categories of information may be typed into the assistant, which may not, whether output may be pasted into external systems, and who to tell if the assistant returns something that looks confidential. Vague policies produce shadow use of consumer tools, which is worse than supervised use of a sanctioned one.
Include a line on verification. Assistants produce fluent text that can be wrong, including wrong summaries of real internal documents, so anything consequential needs checking against the source.
Avoid the mistakes people actually make
The most common error is treating the rollout as a procurement decision rather than a permissions project, and discovering the oversharing after users do. The second is assuming that because nobody had found a file before, nobody will now; retrieval systems are indifferent to obscurity.
Others recur. Labelling everything as confidential, so the classification carries no information. Running the pilot with administrators, whose permissions are unrepresentative, then rolling out to staff whose experience differs. Forgetting that leavers, contractors and service accounts may hold licences. Assuming an assistant’s answers are covered by the same records management rules as the underlying documents without checking. And omitting to re-run the audit: permissions drift, new repositories appear, and an audit completed once is accurate only on the day it finished.
Recognise when this approach is the wrong choice
This process assumes an assistant grounded in your own data under your own identity system. It does not transfer cleanly to coding assistants, where the risks are different — suggested code containing vulnerabilities, dependency naming attacks, secrets committed into repositories — and where the controls belong in code review and build pipelines instead.
It is also the wrong approach where the underlying permissions cannot be made correct in reasonable time. If a file estate has no reliable ownership and no workable access model, indexing it for an assistant will not clarify matters; the remediation has to come first, or the scope has to stay narrow indefinitely.
Finally, if the material is subject to strict confidentiality obligations — legally privileged, special category personal data, or held under contractual restrictions on processing location — the question is not how to configure the assistant but whether that content should be in scope at all. In some cases the honest answer is no.
Frequently asked questions
Does an AI copilot give employees access to files they could not already open?
Generally no. Enterprise assistants of this kind operate under the signed-in user’s existing permissions and return only what that account could already reach. The practical change is speed and discoverability: material that was technically accessible but buried becomes easy to surface through a plain-language question. This is why permission audits matter before deployment — the assistant exposes existing configuration errors rather than creating new ones.
What is prompt injection and why does it affect document assistants?
Prompt injection is text crafted to be read by a language model as an instruction rather than as content. When an assistant retrieves documents, emails or web pages to answer a question, any instructions hidden in that material may influence its behaviour. It is a well-documented weakness of retrieval-based systems with no complete technical fix, which is why assistants handling untrusted content are usually kept to drafting rather than acting independently.
Should conversations with a workplace AI assistant be logged?
Most organisations conclude yes, for security investigation and records purposes, but logging prompts creates its own data protection questions because prompts can contain personal or sensitive information. Decide the retention period deliberately, document the lawful basis for keeping the records, and tell staff that the logs exist. Silent monitoring of what people ask an assistant is both a compliance risk and a reliable way to destroy trust in the tool.
How often should permissions be re-audited after rollout?
There is no universal interval, and the right answer depends on how fast your file estate changes. The practical trigger points are consistent, though: new repositories or connectors, departmental reorganisations, large joiner or leaver movements, and any change to default sharing settings. Many organisations pair a scheduled review with automated reporting on broad-access links, so drift is visible between formal audits rather than discovered during one.
Sources and further reading
- Vendor administrative documentation for enterprise AI assistants, covering permission inheritance, indexing scope and classification labels.
- The UK National Cyber Security Centre, for published guidance on the security of large language model applications.
- The OWASP Foundation, for its community-maintained list of top security risks in large language model applications, including prompt injection.
- The Information Commissioner’s Office, for guidance on data protection obligations when personal data is processed by AI systems.
Surfaced from the google:GB signal “interest in AI copilots”. AI-assisted draft, editorially reviewed.
