Your Organisation Enabled AI. Here Are the Nine Things It Forgot.
Here are the nine things most organisations skipped when they enabled AI and what the consequences look like when each one is missing.
Most organisations think the AI risk is a dramatic data breach. Something loud. Something visible.
The actual risk is quieter than that. It is executive compensation files appearing in an intern's Copilot response. It is 3,000 agents running in a production environment nobody inventoried. It is a sensitivity label that Copilot bypassed for four weeks before anyone noticed.
None of those are hypothetical. All of them happened.
This post is not a lecture and it is not a compliance document. It is the navigation aid that should have come with the deployment decision. Nine things your organisation probably skipped, and the specific consequences that follow each one when it is missing. If you have been handed AI security responsibility and sent off to figure it out — this is where you start.
1. Data Discovery
Before anything else, you need to know what you have. Where it lives. Who can technically reach it. Not what your data map from three years ago says. What actually exists in the environment today.
Most organisations skip this step because it feels slow. The business wants Copilot live, the productivity numbers are compelling, and a data discovery exercise sounds like something that happens before the next project, not this one. So they enable the tool and move on.
Here is what happens next.
Executive compensation spreadsheets, M&A documents, and HR investigation files have appeared in Copilot responses within the first week of ungoverned deployments. Not because of a breach. Not because of an attacker. Because most enterprise tenants have 15 plus years of accumulated oversharing — stale permissions, broken inheritance, and "Everyone except external users" links on sensitive document libraries. The data was always there. Before Copilot, finding it required knowing the URL. Copilot removes that friction entirely. CybernewsCybernews
I have walked into environments where the security team genuinely believed their data estate was in reasonable shape. Policies were in place. SharePoint had been organised. Or so they thought. What the discovery exercise consistently surfaces is the archaeology of previous administrations — folders created in 2009 that nobody owns anymore, project sites from initiatives that ended years ago, distribution groups that never got cleaned up after a restructure, permission groups with names nobody can explain that still have access to everything. Copilot does not care that those artefacts were forgotten. It indexes them. It searches them. It surfaces them in response to a prompt typed by someone who had no idea any of it existed.
You cannot protect what you have not found. And you will be surprised what Copilot finds that you forgot existed.
2. Sensitivity Labels
Once you know what you have, you need to classify it. And the classification system you apply needs to hold up under the specific pressure that AI creates.
Sensitivity labels are the tags your organisation applies to content to signal how it should be handled — what can be shared, what can be printed, what can be accessed by which systems. In principle, a label marked Confidential should tell Copilot to treat that content accordingly.
In practice, Microsoft Copilot bypassed sensitivity labels twice in eight months. EchoLeak was patched in June 2025. Eight months later, Copilot was bypassing sensitivity labels again, this time through its own code defect rather than an external attack. In both cases, Copilot exposed confidential content that sensitivity labels were supposed to protect. The January 2026 incident caused Copilot to read and summarise email messages that organisations had labelled confidential, drawing from users' Sent Items and Drafts despite Purview sensitivity labels and configured Data Loss Prevention protections. Let's Data Science + 2
What this tells you is not that sensitivity labels are useless. It is that they are one layer and they need the layers around them to function. A label without proper enforcement, without DLP policies aligned to it, without monitoring to detect when it is being bypassed — is a sign in a building with no walls.
A label that Copilot can bypass is not a label. It is a suggestion.
3. Advanced Data Classification
Labels cover what they cover. The problem is everything else.
Most organisations classify a fraction of their sensitive content. The rest — years of unclassified files, legacy documents, shared drives that predate the labelling policy, content created before the governance programme existed — sits outside the framework entirely. Copilot does not check whether something has been labelled before it surfaces it. It checks whether the user has permission to access it. If the file is accessible and unlabelled, it is fair game.
Advanced data classification extends the net beyond what a manual or basic labelling approach can reach. It uses automated scanning to identify sensitive content that has never been labelled — content that looks like a salary discussion, a legal document, a patient record — and applies classification at scale without requiring a human to review every file individually.
In every environment I have assessed, the unlabelled data is always more extensive than the organisation expects and more sensitive than they are comfortable admitting. The gap is not a reflection of negligence. It is a reflection of how fast data accumulates versus how slowly governance programmes are built. The problem is that Copilot operates at AI speed. Your classification programme does not.
Your labelling policy is only as good as the oldest unlabelled file on your SharePoint. That file is older than you think.
4. Access and Sharing
Here is where the oversharing problem becomes very concrete very quickly.
The typical enterprise has 16% of its business-critical data overshared, with an average of 802,000 files at risk per organisation. Before AI, oversharing was a latent risk. An employee could navigate to a SharePoint library with board meeting minutes, but they needed to know the URL, find the right folder, and open the document. That friction, accidental and unintentional as it was, provided a degree of practical control. VentureBeat
Copilot removes that friction completely.
The access and sharing review is the exercise of going through the permission model systematically — identifying who has access to what, revoking access that is no longer needed, breaking inheritance where it has spread permissions further than intended, removing stale guest accounts, and applying least-privilege principles to the data environment before the AI is let loose inside it.
The oversharing was always there. Copilot just gave it a search bar.
What I consistently find during these reviews is not malicious sharing. It is accidental accumulation. A project folder shared broadly so a contractor could access it two years ago and never restricted afterward. A SharePoint site that inherited permissions from a parent and nobody noticed. A distribution group with a membership list that nobody has audited since the person who created it left the company. Each one individually is minor. Collectively, and viewed through the lens of what an AI can retrieve in seconds, they are significant.
5. Encryption
This one tends to get assumed rather than verified.
The assumption is that because the data lives inside Microsoft 365, it is encrypted. And to a degree that is true — Microsoft encrypts data at rest and in transit within its infrastructure. What organisations miss is the specific encryption considerations that AI processing introduces.
Interaction data lives inside Microsoft 365. Prompts and responses are stored in the user's mailbox, files uploaded to Copilot Chat land in a dedicated OneDrive folder, and Copilot Pages content sits in user-owned SharePoint Embedded containers. Each of those storage points has its own permissions and its own access model. If your encryption keys are managed by Microsoft rather than by your organisation, if your DLP policies do not extend to those containers, if your conditional access policies do not account for AI-generated outputs as a data category — there are gaps that encryption alone will not close. Substack
The question is not whether your data is encrypted in transit. The question is whether the outputs Copilot generates from that data are treated with the same classification rigour as the inputs. Most organisations have not asked that question yet.
You would not leave a filing cabinet unlocked in the lobby. Every AI interaction has a filing cabinet. Check who has the key.
6. Data Minimization
This is the principle that AI systems should only access the data they actually need for the specific task they are performing. Not everything a user can access. Not everything in the tenant. The minimum necessary for the job.
74% of organisations give AI agents more privileges than necessary. 79% report agents creating hard-to-monitor access pathways, and only 22% apply access control frameworks consistently. Ajithp
The reason this happens is not carelessness. It is speed. When you are building an agent to handle a specific workflow, restricting its access scope requires knowing what it actually needs — which requires understanding the task in detail, mapping the data sources, and making deliberate decisions about what to include and exclude. That takes time. Giving it broad access takes minutes.
An agent built to summarise meeting notes does not need access to your financial systems. An agent handling customer queries does not need visibility into HR records. An agent that assists with contract review does not need access to the engineering source code repository. But without deliberate minimization, the agent gets what the user has — and what the user has is often far more than the task requires.
The access scope I find on most agents that were built without data minimization in mind is extraordinary. The agent was scoped to do one thing. But because nobody explicitly restricted its access, it can reach everything its creator could reach — and sometimes more, depending on how it was connected. That access does not disappear when the agent is no longer the focus of attention. It persists. And it becomes a surface that an attacker, a misconfiguration, or an unexpected prompt can exploit long after the original use case has been forgotten.
Least privilege is not a new concept. Applying it to an AI agent that can summarise your entire SharePoint in forty seconds is a different discipline from applying it to a junior employee.
7. Governance — Not Just for Data, for Agents Too
Your organisation probably has an AI policy. It probably mentions data protection, acceptable use, and something vague about compliance. What it almost certainly does not have is a governance framework for agents — what exists, who owns it, what it is connected to, what it can do, and who is responsible when it does something unexpected.
Gartner predicts that by 2028, the average Fortune 500 enterprise will have over 150,000 AI agents in use, up from fewer than 15 in 2025. Yet only 13% of organisations believe they have the right governance in place today. That 87% gap represents real exposure: security blindspots, compliance risk, redundant costs, and ungoverned systems making decisions on behalf of the business. NHI Management Group
88% of organisations experienced a confirmed or suspected AI agent security incident in the prior year. Reco
I walked into one environment where the security team believed they had a reasonable handle on their AI deployment. They had enabled Copilot, they had some policies in place, and they had restricted certain external connections. What nobody had done was count the agents. When we ran the inventory, close to 3,000 agents were already live in the default production environment. Agent Builder, Copilot Studio, Foundry — three surfaces, three sets of agents, none of them registered, none of them governed, none of them owned by anyone who could explain what they were connected to or what they were authorised to do. The organisation had firewall rules blocking some third-party URLs. The agents were exchanging data through embedded API connections that the firewall rules did not cover. They felt secure. The inventory said otherwise.
Governance for agents means a register — not a spreadsheet someone updates occasionally, an active register with ownership assigned, access scope documented, connection points mapped, and a review cadence that keeps pace with the rate at which new agents are being created. Less than half of the organisations surveyed have visibility into an inventory of AI agents. The ones that do not are making decisions about their AI risk posture based on an incomplete picture of what is actually running in their environment. arxiv
You cannot govern what you cannot count. And most organisations cannot count their agents. That is not a figure of speech.
8. Compliance
Compliance tends to be the item that gets deferred most confidently. The attitude is that the regulations are still maturing, the frameworks are still being written, and there is time to get ahead of it later.
The timeline on that assumption has already closed.
In March 2024 the U.S. House of Representatives banned Microsoft Copilot from its devices, citing data security concerns. 42% of companies abandoned most of their AI initiatives in 2025, a dramatic spike from 17% in 2024, with the average organisation scrapping 46% of AI proofs of concept before they reached production. Compliance and regulatory alignment were consistently among the reasons cited. The EU AI Act enforcement for high-risk systems begins August 2026, with penalties reaching €35 million or 7% of global annual turnover for failures in safety and governance obligations. EPC GroupSAP
The organisations that are most exposed are not the ones that ignored compliance entirely. They are the ones that noted it as something to address later and found that later arrived faster than they anticipated, with higher stakes than they had budgeted for.
Mapping your AI deployment against the regulatory requirements that apply to your sector, your geography, and your specific use cases is not a one-time exercise. It is an ongoing function that needs to move at the pace the regulatory landscape moves. That pace is faster than most governance programmes are currently designed to match.
The regulator was not invited to your AI launch event. They will make their appearance at a time of their choosing.
9. Data Monitoring
The last item on the checklist is the one that would have caught most of the incidents described in the previous eight.
CW1226324 and EchoLeak are not isolated incidents. They are part of a pattern of security failures in Microsoft's Copilot ecosystem that stretches back to 2024. What they share is not just a technical failure. They share the characteristic of running undetected for weeks or months. Not because the organisations affected were incompetent. Because nobody had monitoring in place that was calibrated to catch AI-specific anomalous behaviour. Let's Data Science
Traditional monitoring watches for known attack patterns against known systems. AI introduces new behaviours, new data flows, and new failure modes that existing monitoring tools were not designed to see. Copilot accessing content it should not be able to reach looks different from a user manually accessing the same content. An agent behaving abnormally looks different from a user behaving abnormally. Without monitoring that is specifically calibrated to AI behaviour patterns, those anomalies become invisible.
What I typically find when I arrive at an organisation that has not built AI-specific monitoring is a security team that is watching their existing dashboards and seeing nothing unusual — because the dashboards were not built to surface what is unusual about AI. The alerts are not firing because the alert conditions were written for human behaviour. The logs exist but nobody has defined what to look for in them. The SIEM has Copilot data flowing through it but the correlation rules have not been updated to account for AI-specific patterns. The organisation feels like it has visibility. The gap between that feeling and the reality is where incidents live.
Data monitoring for AI means defining what normal looks like for your AI systems, instrumenting for deviations from that baseline, building alert logic that accounts for AI-specific failure modes — prompt injection attempts, anomalous data retrieval patterns, unusual output characteristics — and maintaining logs of prompt and response activity that are independent of vendor-provided logs.
The incidents that cost organisations the most are never the ones that happened. They are the ones that happened weeks before anyone noticed.
Where This Leaves You
You were handed this responsibility. Possibly without a framework, possibly without a team, possibly while the AI tools were already live and users were already in them.
That is the reality for most security professionals in this position right now. And the honest answer is that you do not need all nine of these in place by Monday. What you need is to know which ones are missing, what the specific risk of each gap represents, and what to prioritise first.
Start with Data Discovery. You cannot build anything on top of a foundation you have not mapped. Everything else follows from knowing what you actually have and where it lives.
The next post in this series goes through the practical implementation of each item — not the policy version, the version that actually works in the environments where these gaps exist. If you want the full governance framework rather than the checklist, that is what CyberSage is building for exactly this moment in the industry.
Either way — save this. Share it with the person in your organisation who approved the AI deployment. Particularly if security was not in the room when that decision was made.
For further reading and the frameworks referenced throughout this piece:
EU AI Act overview: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
OWASP Top 10 for Large Language Model Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
MITRE ATLAS — adversarial threat landscape for AI systems: https://atlas.mitre.org/
Stay Updated
Get the latest security insights delivered to your inbox.