Data Security and AI Executive Briefing: Oversharing, AI Assistants and Data Exposure Risk

AI assistants do not usually create new access to data; they make the access people and systems already have far easier to use, so years of oversharing, stale permissions and unlabelled files become a live exposure the day an assistant is switched on. This briefing is for board members, chief executives, finance directors, general counsel and risk committees who approve AI rollouts or oversee data risk. It explains the three main ways AI drives data exposure (oversharing inside the organisation, data sent to external AI services, and AI agents acting with broad credentials), the controls worth funding first, the questions directors should ask and a 90-day plan. It is vendor neutral and stays at board level; the deployment detail for copilots is in the Enterprise AI Copilot Security Guide and for data loss prevention in the Generative AI Data Loss Prevention Guide.

The risk in one paragraph

Enterprise AI assistants answer questions by searching the data a user can reach. Microsoft's documentation for Microsoft 365 Copilot, for example, states that it only surfaces organisational data the individual user has at least view permission to access, and stresses that organisations need to use the permission models available, such as those in SharePoint, so the right people have access to the right content. In most organisations those permissions are far broader than anyone intended: sites shared with everyone, links that never expire, files nobody has classified. Before AI, finding that data took effort. With AI, one question can surface salary files, board papers or customer records to anyone who technically has access. At the same time, staff paste confidential material into public AI tools, and AI agents are being given credentials that reach across systems. The board's job is to make sure AI adoption is matched by funded work on access, classification and monitoring, and that someone is accountable for AI data risk.

Why this is a board-level issue now

• AI is being deployed faster than data is being cleaned up: AI assistants are switched on across whole workforces, while permission reviews and data classification programmes run on multi-year timelines. The gap between the two is the exposure.
• Staff use public AI tools whether or not they are allowed: in March 2023, engineers at a large electronics manufacturer pasted proprietary source code and a meeting transcript into a public chatbot while doing their jobs, within weeks of the tool being permitted. No attacker was involved. See the Samsung ChatGPT source code leak and the Shadow AI Statistics Guide.
• Sensitive information disclosure is a recognised AI risk: the OWASP Top 10 for LLM Applications 2025 lists Sensitive Information Disclosure as LLM02, covering personal data, financial details, health records, confidential business data, credentials and legal documents exposed through AI output. It notes that instructions in the system prompt not to reveal such data may not always be honoured and can be bypassed.
• Personal data law still applies: processing personal data through AI tools is subject to data protection law, including security obligations such as UK and EU GDPR Article 32 and impact assessments for high-risk processing under Article 35. See the AI and GDPR Guide.
• Directors are expected to know their critical data: the UK Cyber Governance Code of Practice (8 April 2025) asks boards to gain assurance that the technology, information and services critical to the organisation are identified, prioritised and agreed (principle A). AI makes that assurance urgent.

Three ways AI exposes data

Oversharing: the problem AI makes visible

Oversharing is rarely a single mistake. It accumulates: project sites opened to the whole company, files shared with anyone who has the link, departed staff still in groups, guest users never removed. AI assistants turn that accumulated access into instant answers. The response is not to delay AI forever, but to fix the highest-risk access first and to keep it fixed.

• Find the most sensitive repositories first: HR, finance, legal, mergers and acquisitions, board and customer data. Classification tools and data security posture management can help locate them. See the DSPM Guide.
• Remove organisation-wide and anonymous sharing on those repositories, and set link expiry by default.
• Label sensitive content: sensitivity labels with encryption carry access rules with the file. Microsoft states that Microsoft 365 Copilot honours usage rights on content encrypted by Microsoft Purview Information Protection. See the Microsoft Purview Information Protection Guide.
• Restrict what AI can search where needed: enterprise AI platforms commonly provide settings to exclude sites or content from AI search while clean-up continues. Confirm the options in your supplier's current documentation.
• Review access continuously: owners of sensitive repositories should confirm who has access on a regular cycle. See the AI Data Access Review Guide.

External AI services and shadow AI

Staff use public AI tools because they are useful. Banning them without an alternative tends to push use out of sight. The board should expect a combination of an approved option, clear rules and technical enforcement.

• Provide an approved tool with enterprise terms: for example, Microsoft states that prompts, responses and data accessed through Microsoft Graph are not used to train the foundation models used by Microsoft 365 Copilot. Every AI supplier's training, retention and data location terms should be checked before approval.
• Set and publish an AI acceptable use policy that says which data may be used with which tools. See the AI Acceptable Use Policy Template.
• Discover AI use through network, browser and SaaS signals, including AI features embedded in existing applications. See the Shadow AI Agent Discovery Guide.
• Enforce with data loss prevention on AI traffic for the most sensitive data types, and plan for what happens when sensitive data is pasted. See the Sensitive Data Pasted into AI Playbook.

AI agents: data access by non-human identities

AI agents and AI integrations do not log in like people. They use service accounts, API keys, OAuth tokens and connectors, often with broad standing access granted for convenience. That makes them non-human identities that need the same governance as any privileged account, and more, because their behaviour can be steered by the content they read. OWASP describes prompt injection (LLM01) and excessive agency (LLM06), where an AI system has more functionality, permission or autonomy than it needs. The NCSC-led Guidelines for Secure AI System Development (27 November 2023) aim to help providers build AI systems that work without revealing sensitive data to unauthorised parties, across secure design, development, deployment and operation.

• Give every agent its own identity with an owner, a purpose and least-privilege access; never reuse a person's credentials.
• Require approval for sensitive actions such as bulk export, external sharing or deletion.
• Log and monitor agent activity and alert on unusual data access volumes.
• Review OAuth grants and connectors that give AI tools access to mail, files and business systems.

Agents also widen the exposure route described above: an agent that reads a poisoned document or email can be steered into retrieving and sending data its owner never intended to share, so the limits on what it can reach matter more than the instructions it is given. See the NHI Guide and the Top 10 AI Agent Security Risks for CISOs.

Where it sits in the frameworks

Five questions for the board to ask

1. What could our AI assistant show the wrong person today? Ask for a test: what sensitive content can an ordinary user surface by asking, and what has been done about it?
2. Where is our most sensitive data, and who can reach it? Show the top repositories, their owners, how widely they are shared and when access was last reviewed.
3. Which AI tools are staff actually using? Show discovery results, the approved alternatives and the data rules for each tool.
4. What can our AI agents access and do? List each agent or integration, its owner, credentials, permissions and the actions that need human approval.
5. Who is accountable for AI data risk? Name the executive owner and the measures reported to the board.

Red flags in management answers

• The AI assistant was enabled for everyone before any permission review of sensitive repositories.
• "The AI only sees what users can see" is offered as reassurance, rather than as the reason to fix access.
• Public AI tools are banned on paper, but nobody measures actual use.
• AI agents run under a shared or personal account, or with administrator rights.
• Supplier terms on training, retention and data location have not been reviewed by legal.
• No data protection impact assessment exists for AI use involving personal data.

What good looks like

• Clean before scale: AI rollout is phased, with high-risk repositories remediated before wide release.
• Labelled sensitive data: the most sensitive content is classified and protected wherever it travels.
• Approved and observed AI use: staff have a sanctioned tool, clear rules, and AI use is visible.
• Governed agents: every AI agent has an owner, its own identity, least-privilege access and monitoring.
• One accountable owner: AI data risk is on the risk register with an executive owner and board reporting.

Where to invest first

1. Permission clean-up on the top sensitive repositories: the fastest reduction in AI exposure for the money.
2. Data discovery and classification: tools and owner time to find and label the most sensitive data. See the Data Classification Guide.
3. An approved AI tool with enterprise terms: so staff do not need consumer tools for everyday work.
4. Visibility of AI use and data flows: discovery and data loss prevention for AI traffic.
5. Agent identity governance: inventory, ownership and least privilege for AI agents and integrations.

Metrics to track

A 90-day plan

1. Days 1 to 30: name an executive owner for AI data risk; identify the top sensitive repositories and test what an ordinary user can surface through the AI assistant; run discovery of AI tool use; inventory AI agents and integrations.
2. Days 31 to 60: remove organisation-wide and anonymous sharing on sensitive repositories; restrict AI search on high-risk content while clean-up continues; publish an AI acceptable use policy; review supplier terms on training, retention and data location; complete impact assessments where personal data is involved.
3. Days 61 to 90: extend labelling and data loss prevention to AI traffic; give each AI agent an owner, its own identity and least-privilege access; agree the phased rollout criteria; report the metrics above to the board.

Common failure patterns

• Switching on first, cleaning up later: the assistant is released to everyone and the first permission review follows a complaint.
• Policy without enforcement: written rules on public AI tools are not backed by discovery or technical controls, as the 2023 source code case showed.
• Labels without coverage: a classification scheme exists, but most sensitive files are unlabelled.
• Agents with borrowed access: AI agents run under personal or shared accounts with broad rights, so their activity cannot be scoped or attributed.
• Ignoring embedded AI: AI features inside existing SaaS applications receive data without any review.
• No owner: AI data risk falls between the CISO, the data protection officer and the business, and nobody reports it.

Lessons from incidents

The 2023 source code case is useful because it was ordinary: employees trying to work faster with a newly allowed tool, no attacker involved. The company's response, limiting prompt size and then temporarily restricting generative AI tools on company devices, came after the data had left. The lesson for boards is to put the approved tool, the rules and the visibility in place before or alongside adoption, not afterwards. See the Samsung ChatGPT source code leak.

Practitioner checklist

• Assign an executive owner for AI data risk and add it to the risk register.
• Identify and remediate sharing on the most sensitive repositories before broad AI rollout.
• Label sensitive content and confirm AI tools honour those labels, using supplier documentation.
• Restrict AI search on high-risk content until clean-up is complete.
• Provide an approved AI tool and publish an AI acceptable use policy.
• Discover AI tool use and apply data loss prevention to AI traffic for sensitive data types.
• Give every AI agent its own identity, an owner and least-privilege access, with approval for sensitive actions.
• Review AI supplier terms on training, retention and data location, and complete impact assessments for personal data.

Standards and references

• OWASP: Top 10 for LLM Applications 2025
• NCSC: Guidelines for Secure AI System Development
• NIST: AI Risk Management Framework
• NIST: Cybersecurity Framework 2.0
• Microsoft Learn: Data, Privacy, and Security for Microsoft 365 Copilot
• UK Government: Cyber Governance Code of Practice

How NHI Mgmt Group can help

We provide independent identity and non-human identity assessments and board briefings, including reviews of the service accounts, API keys and OAuth grants that AI agents and assistants use to reach company data. Our NHI Foundation Level Training Course includes a section on agentic AI. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: Enterprise AI Copilot Security Guide · Generative AI Data Loss Prevention Guide · Microsoft 365 Copilot Security Deep Dive · AI Governance Guide