When generative AI moved from experiment to everyday enterprise tool, it also expanded the attack surface in ways many organisations are only beginning to understand.
In this interview, Nikolay Milyaev, a seasoned enterprise security practitioner with 50+ major global projects to his name walks us through the shift: why identity, data governance, and agent oversight have become the new frontlines of corporate security, what most companies get wrong when they rush a Copilot deployment, and why the question was never whether the AI model is safe, but whether the permissions, data flows, and controls surrounding it are.
1. You work at the intersection of enterprise security, endpoint management, and AI enablement. How has the conversation around cybersecurity changed since generative AI entered the enterprise mainstream?
The information I share today represents my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation.
Since generative AI entered the enterprise mainstream, the cybersecurity conversation has become much more data-centric and much more operational. In my view, the biggest shift is that security teams are no longer asking only, “How do we protect users, devices, and applications?” They are also asking, “How do we control what AI can access, what it can expose, and how it behaves inside the enterprise?” Microsoft’s recent guidance reflects exactly that shift, with stronger emphasis on AI security, data security, compliance, privacy, and governance as part of the core enterprise security model.
What has not changed is the foundation. The core principles are still Zero Trust, least privilege, strong identity, and continuous verification. What has changed is the attack surface. Microsoft now explicitly addresses new trust boundaries in AI systems, including the relationships among users and agents, models and data, and humans and automated decision-making. In practical terms, that means enterprises now have to think seriously about oversharing, prompt injection, shadow AI, overprivileged agents, and whether sensitive data is being surfaced too easily through AI experiences.
The other major change is speed. Microsoft’s latest Digital Defence Report says AI is pushing threats to new levels of speed, scale, and sophistication, and that threat actors are already using AI to scale phishing and automate intrusions. So the discussion has moved beyond traditional prevention into resilience and response at machine speed. That is why AI is now part of both sides of the equation: attackers use it to move faster, and defenders use it to detect, investigate, and respond faster as well.
Generative AI has not replaced classic cybersecurity priorities, but it has raised the stakes. It has made identity, data governance, and real-time visibility even more important and turned AI security from a niche topic into a mainstream board-level issue. The organisations handling this best are those that treat AI as an extension of their existing security architecture, rather than as a separate experiment running outside it.
2. You have worked on more than 50 enterprise security projects for major global organisations. What patterns do you consistently see in companies that are good at turning security into an operational advantage rather than just a compliance function?
Across the many enterprise security projects I have worked on, companies that turn security into an operational advantage usually share common patterns. First, they do not run security as a side process for audit season. They anchor it to the business assets and processes that matter most, and they build controls around those priorities. Microsoft’s Zero Trust guidance is very clear that security should be an integrated strategy that protects what matters most while preserving business agility. That mindset changes security from a checkbox exercise into something that actively supports the way the company operates.
Second, the stronger organisations are disciplined about fundamentals. They treat identity as a core control plane, enforce strong authentication and least privilege, and apply policy consistently across users, devices, and applications. Microsoft positions Conditional Access as the Zero Trust policy engine, and its guidance notes that multifactor authentication reduces the risk of compromise by more than 99%. In practice, the companies that do this well make these controls consistent, measurable, and difficult to bypass, instead of relying on scattered exceptions and fragmented tools.
Third, they reduce silos. Microsoft’s unified security operations model brings endpoint, cloud, identity, email, threat intelligence, exposure management, and SIEM into a single central platform, which matters operationally because it lets teams work with shared signals rather than fragmented dashboards. The better organisations also continuously measure exposure rather than treating posture as a once-a-year exercise. Microsoft’s guidance now emphasises ongoing exposure management, unified recommendations, automated assessment of hundreds of security settings, and clear daily, weekly, and monthly SecOps routines. That is usually the real difference: security becomes an operating rhythm that improves resilience, speeds decisions, and helps the business move with more confidence.
3. From your experience with large enterprise projects, what mistakes do organisations make when they try to apply old security models to AI-powered workflows?
From my experience, the biggest mistake is assuming AI is just another application that can be secured with the old model of SSO, static roles, and a perimeter mindset. Microsoft is now very explicit that AI systems do not fit neatly into traditional security models because they create new trust boundaries between users and agents, models and data, and humans and automated decision-making. If organisations miss that shift, they end up with AI systems that are overprivileged, manipulated, or simply misaligned with the business outcome they were meant to support.
The second mistake is underestimating the data problem. In older security models, teams often focused mainly on whether a user could get in. In AI-powered workflows, Microsoft puts oversharing, data leakage, and governance much closer to the centre. If Copilot or an agent is connected to overshared SharePoint sites, OneDrive content, or business systems, it can surface sensitive information very efficiently, because it is working with the access it has been given. That is why Microsoft’s Copilot Control System starts with data security, including identifying overshared content, limiting access to those who genuinely need it, and applying monitoring, DLP, and sensitivity protections around Copilot and agent interactions.
A third mistake is treating agents as lightweight helpers rather than as identities and workloads that require governance. Microsoft’s latest guidance says organisations should treat every AI agent as a first-class identity, with clear ownership, governed permissions, and proper audit trails. In practice, the risky patterns are very concrete: agents shared too broadly, agents without authentication, agents running with the maker’s credentials, hard-coded secrets, or dynamic actions where the model can decide recipients, endpoints, or execution logic. Those shortcuts often look harmless in a pilot, but they become serious security gaps in production.
So overall, I would say the core mistake is trying to bolt AI onto an old security model instead of extending Zero Trust across the full AI lifecycle, from data and identity to agent behaviour, monitoring, and governance. Microsoft’s direction is very clear on that point, and I think enterprises that understand it early will be in a much stronger position.
4. Many companies want to adopt Microsoft Copilot quickly, but security teams are worried about data exposure. What are the most common risks organisations underestimate at the start?
In my experience, the risk most organisations underestimate at the start is not Copilot itself, but the condition of their existing data estate. Microsoft is very clear that Microsoft 365 Copilot only surfaces content that a user already has permission to access through Microsoft Graph. That sounds reassuring, but in practice, it means that old permission problems, overshared SharePoint sites, risky links, inactive or ownerless sites, and loosely governed collaboration spaces become much more visible and consequential once Copilot is introduced. What was previously hidden in the background can suddenly become easy to discover and summarise.
The second thing companies often underestimate is how much upfront governance they need around sensitive data. Microsoft’s guidance puts this right at the centre: identify overshared data, classify and label sensitive files, decide what Copilot should not use for grounding, and apply DLP policies for both files and prompts. Many organisations want to move straight to enablement and adoption, but if they skip those guardrails, they create avoidable exposure risks. I would say this is one of the biggest mindset gaps: treating Copilot deployment as a feature rollout, when Microsoft’s own guidance treats it as a security and governance program.
A third underestimated risk is agent sprawl. As soon as companies move beyond core Copilot and start enabling agents, the question is no longer only who can see data, but also who can create, share, publish, and govern those agents. Microsoft now provides specific controls to restrict org-wide sharing, approve and block agents, and manage access centrally, which tells you this is not a theoretical issue. In real projects, I often see organisations focus on the user experience first and only later realise they need proper control over who can build and distribute AI assistants internally.
And finally, many teams underestimate the need for ongoing monitoring after launch. Microsoft recommends using Purview to review prompts and responses, web search keywords, risky AI usage, audit activity, and attempts such as prompt injection. That matters because data exposure is rarely a one-time configuration issue. It is something that has to be continuously validated as content, permissions, agents, and user behavior evolve. So for me, the most common mistake is thinking the main question is whether Copilot is secure enough. The real question is whether the organisation is disciplined enough in data governance, permissions, and monitoring to use it safely at scale.
