What is Zero Trust, and why is it becoming essential in the age of AI?

Zero Trust is sometimes presented as a complex security architecture reserved for cybersecurity specialists. Yet its starting point is simple: access should never be considered legitimate once and for all.

An identity, device or application must be verified based on the context. Permissions must reflect a genuine need. The organisation must also be able to detect unusual behaviour and limit the impact of an incident.

This approach already applied to users, devices, applications and data. With the arrival of Microsoft 365 Copilot and AI agents that can use tools or perform actions, it has taken on a new level of importance.

Artificial intelligence does not replace Zero Trust. It makes its application even more critical.

Why is the traditional security model no longer enough?

For many years, companies focused mainly on protecting a perimeter: their offices, servers and internal network. That model no longer reflects the way most organisations operate.

Employees use several devices and access resources from different locations. Data moves between Microsoft 365, business applications, collaboration platforms and cloud services. Partners and service providers may also need access to specific information.

In this environment, being connected to the corporate network is no longer enough to establish trust.

An employee may change roles while retaining access from a previous position. A device may no longer meet the organisation’s security requirements. A password may be compromised. A permission granted for a temporary project may remain active long after the project has ended.

Zero Trust is based on a practical observation: an identity or device may be legitimate at a given moment without being trusted permanently.

Every access request should be assessed in context:

• who is requesting access;
• which device they are using;
• which resource they want to access;
• under what conditions;
• the level of risk involved;
• the action they intend to perform.

The three principles of Zero Trust

Microsoft structures its Zero Trust approach around three principles: verify explicitly, use least-privilege access and assume that a breach can occur so that its impact can be contained.

Verify explicitly

An access decision should never rely on a single signal. A correct password alone may not be enough to prove that a request is legitimate.

The organisation can also consider the user’s identity, authentication method, device status, application, requested resource and detected risk level.

The purpose is not to create unnecessary obstacles for users. Verification should reflect the sensitivity of the situation.

Accessing general information and opening a confidential document do not carry the same level of risk. The access conditions can therefore be different.

Grant only the permissions that are needed

The principle of least privilege means giving a person, application or service only the permissions required to carry out its role.

Consider a simple example. An employee joins a project and receives access to a workspace containing commercial proposals, contracts and information about several customers. Once the project ends, she moves to another role, but her permissions are never reviewed.

Her account has not been compromised, and she has done nothing wrong. The access is simply no longer justified.

Companies should therefore review permissions regularly:

• Is this access still required?
• Does it still match the person’s role?
• Does it need to be permanent?
• Does it provide access to more resources than necessary?
• Should it be reviewed periodically?

The same principle must apply to AI agents, which may have their own identities and permissions.

Limit the impact of an incident

Adopting Zero Trust does not mean treating every employee as a threat. It means preparing for the possibility that an account could be compromised, a mistake could be made or a security control could be bypassed.

If an identity is compromised, how far could an attacker go? Could they access sensitive information or use administrative privileges? Would the organisation be able to detect unusual behaviour quickly?

Restricting permissions, separating sensitive access and monitoring security events all help reduce the potential impact of an incident.

Zero Trust does not rely on a single security measure to solve every problem. It combines several controls to verify access, protect data, detect anomalies and contain incidents.

Does using Microsoft 365 mean that Zero Trust is already in place?

Microsoft 365 provides capabilities that can support a security strategy. However, using the platform does not automatically mean that every Zero Trust principle has been implemented.

Several levels need to be distinguished:

1. a security capability exists;
2. it is available to the organisation;
3. it is configured according to identified needs;
4. it is actively used and monitored;
5. its effectiveness is reviewed over time.

A company may have enabled multifactor authentication without having a clear view of its sensitive accounts. It may secure user sign-ins effectively while still allowing overly broad access to certain documents.

It may also receive security alerts without having defined who should review them, how they should be prioritised or what action should follow.

The question should not be limited to:

Which solutions have we purchased?

It should also become:

Do we know how our identities, access rights, devices and data are actually protected?

This distinction does not call Microsoft 365 into question. It separates the availability of security capabilities from their effective use within the organisation.

Zero Trust is not another product to install. It is a way to organise security decisions and make sure that access remains aligned with the company’s actual needs.

Zero Trust is not only an IT issue

Technical tools are essential, but they cannot decide:

• which information matters most;
• which employees should have access to it;
• which uses carry an acceptable level of risk;
• who is responsible for a document workspace;
• how long access should be retained;
• which actions require human approval;
• which uses of artificial intelligence should be allowed.

These decisions require close cooperation between management, business teams, IT and security teams.

Security is not only about preventing attacks. It also creates the conditions needed to collaborate, launch new services and adopt artificial intelligence with greater control.

For business leaders, the challenge is to connect security investments to practical needs: protecting important information, maintaining business continuity and enabling new uses while keeping risk at an acceptable level.

Protecting access is not enough: you also need to understand the data

Once connected, users can view the resources their permissions allow them to access.

Those permissions do not always reflect the current situation. They may come from an old project, a previous role, a team created several years ago, an external sharing link that was never reviewed or a group that provides access to too broad a range of resources. In some cases, the owner of a collaborative workspace may no longer be clearly identified.

The risk does not necessarily come from a sophisticated attack. Confidential information may simply be stored in a location accessible to too many people.

Microsoft’s guidance on applying Zero Trust to Copilot describes several complementary layers: data protection, identities and access, applications, devices, threat protection, secure collaboration and least-privilege access to data.

This highlights an important rule: the security of an environment never depends on a single control.

Why does AI make this more urgent?

Artificial intelligence does not necessarily create the permissions it uses. It relies on the identities, applications, data and access rights already present in the environment.

However, AI can make information much easier to search, combine and summarise. A permission that was previously too broad but rarely noticed can become far more significant when AI makes the related content easier to discover.

In his publications on generative AI, Seyfallah Tagrerout highlights several important areas, including oversharing in Microsoft 365 Copilot, agent identities and the knowledge sources used by AI systems.

Read Seyfallah Tagrerout’s publication on Zero Trust and generative AI (opens in a new tab).

Existing security measures do not become obsolete with AI. They must, however, cover a broader scope:

• the data an assistant can access;
• the sources it can use;
• the external content it processes;
• the tools available to an agent;
• the actions the agent can perform;
• the decisions that must remain subject to human approval.

An assistant that can only prepare a summary does not create the same level of risk as an agent that can send a message, share a document or modify information.

The question should not only be:

Can the AI system perform this action?

It should also be:

Does it genuinely need this permission, and what level of control do we want to retain?

Microsoft recommends building a strong security foundation before introducing Copilot. This includes protecting data, reviewing identity and access policies, securing applications and devices, managing threats and controlling data permissions.

For further guidance, read the Microsoft documentation on applying Zero Trust principles to Microsoft Copilot (opens in a new tab).

This does not mean that a company must achieve perfect security before it can start experimenting. It does need to understand its existing access rights, identify its most significant gaps and adapt its controls to the intended use cases.

Where should you start?

Zero Trust covers identities, devices, applications, data, cloud environments and security operations. Companies do not need to transform everything at once.

A practical starting point is to focus on four areas.

1. Identify sensitive accounts and access rights

The company needs to know which accounts have significant privileges and how those accounts are protected.

This includes administrators, but also technical accounts, application identities and employees with access to sensitive data.

The next step is to identify access rights that no longer reflect a current need. These may include permissions inherited from old projects, inactive accounts, access retained after a change of role or groups with an unnecessarily broad scope.

2. Understand the data that matters

Not all information requires the same level of protection.

The first step is to locate commercial, financial, contractual, personal and strategic data. The organisation must then understand who can access it, how it is shared and who is responsible for it.

This becomes particularly important before connecting an assistant or agent to internal sources.

3. Review detection and response capabilities

Receiving an alert is not enough if nobody knows what to do with it.

The organisation should define:

• who reviews security alerts;
• which situations take priority;
• what information is available for investigations;
• who can suspend access;
• how responsibilities are divided during an incident.

The protection, detection and investigation capabilities available through Microsoft Defender and Microsoft Sentinel can support this process when they are configured and operated according to the organisation’s needs.

4. Build a realistic roadmap

The initial assessment should help prioritise action, rather than produce an endless list of issues to fix.

A company that does not yet have a clear view of its sensitive accounts will have different priorities from an organisation looking to improve its detection capabilities.

Likewise, a company preparing to adopt Microsoft 365 Copilot will need to pay particular attention to the data and permissions that Copilot will be able to access.

A Microsoft 365 security assessment delivered by MC3 Cloud can help review the existing environment, identify the most significant gaps and organise the required actions by priority.

Eight questions to assess your starting point

Before launching a broader programme, your organisation can begin by answering eight questions:

1. Do we know which accounts have the most sensitive privileges?
2. Are access rights reviewed when someone changes roles or leaves a project?
3. Do users have only the permissions they need for their work?
4. Do we know where our confidential information is stored?
5. Do we understand how that information is shared internally and externally?
6. Do we know who should review an alert and make a decision?
7. Do business teams, IT and security teams understand their respective responsibilities?
8. Do we know which information would be accessible to Copilot or a future AI agent?

A lack of precise answers does not mean that an incident is about to happen. It does show that the organisation needs greater visibility and a clear set of priorities.

ZeroTrust Days Copilot 2026 in the Indian Ocean

To explore these issues in more detail, MC3 Cloud is organising the ZeroTrust Days Copilot 2026 across two locations:

• Wednesday, 9 December 2026, from 1:30 p.m. to 5:00 p.m., at the SFR Amphitheatre in Le Port, Réunion Island;
• Thursday, 10 December 2026, from 2:30 p.m. to 6:00 p.m., at the Hennessy Park Hotel in Cybercity, Trianon, Mauritius.

Seyfallah Tagrerout, Microsoft MVP Security and Microsoft Regional Director, will cover topics including:

• how Zero Trust is evolving in response to artificial intelligence;
• the risks associated with generative AI;
• the protection of sensitive data;
• agent identities and permissions;
• the role of Microsoft Entra ID;
• practical approaches for moving from principles to implementation.

Attendance is free, subject to registration and availability.

• Register for ZeroTrust Days Copilot 2026 in Réunion Island (opens in a new tab)
• Register for ZeroTrust Days Copilot 2026 in Mauritius (opens in a new tab)

On 22 December 2026, MC3 Cloud will host a strategic security roundtable at the Labourdonnais Waterfront Hotel in Mauritius, also accessible via Microsoft Teams.

Patrick Beeharry (opens in a new tab), Vice President of Strategy & Operations for the Microsoft Security Division, will share Microsoft’s direction on security, AI and data governance. This non-technical session is designed for business leaders, CIOs, CISOs and senior IT decision-makers. Places will be limited to encourage meaningful discussion.

Interested in attending? Contact your MC3 Cloud sales representative to reserve your place.

In the next article: when AI can take action

Understanding Zero Trust provides the foundation. The arrival of AI agents introduces an additional question.

An assistant can search for, summarise or produce information. An agent can go further. Depending on its design and permissions, it can access resources, use tools and perform specific actions.

The next article in this series will explore:

• the difference between an assistant and an agent;
• what AI can see within the organisation’s environment;
• which actions an agent may be allowed to perform;
• the risks associated with permissions and knowledge sources;
• agent identity and lifecycle management;
• the controls to put in place before expanding the use of AI.

The question is no longer limited to whether a person should have access to a particular piece of data. Organisations must also understand which identity the agent uses, which resources it can access, which tools it can use and which actions it is allowed to perform.

With AI agents, Zero Trust must now address a new question: how can organisations remain in control of systems that can access company resources and act alongside users?