In our previous article on post:zero-trust-ai-foundations, we introduced three core Zero Trust principles: verify explicitly, use least-privilege access and limit the potential impact of an incident.
These principles take on a new dimension when artificial intelligence moves beyond searching for or summarising information. An agent can access business resources, use connectors and perform actions within the organisation’s environment.
The question is therefore no longer limited to what the AI can read.
Which identity is the agent using, which data can it access, and how far can it go without human intervention?
From an assistant that responds to an agent that acts
Microsoft 365 Copilot primarily works alongside the user. It can retrieve information, summarise a meeting, analyse a document or prepare a message.
The user usually remains in control of the next step. Copilot proposes an output, but the user decides whether to change it, send it or reject it.
An agent can go further. Depending on its design and permissions, it can:
- receive an objective;
- search across several information sources;
- use a connector or API;
- create or update information;
- trigger a process;
- send a response;
- update a business application.
Microsoft describes an agent as an application that can understand its environment, make decisions and act through the tools available to it. Some agents are directly invoked by a user. Others can perform part of their work autonomously.
Microsoft’s documentation on agent identities (opens in a new tab) explains this shift and the resulting requirements for identity, authorisation and governance.
The more an agent is allowed to do, the greater the potential impact of excessive permissions, an error or malicious content.
A practical example: automating customer requests
Consider a company that wants to create an agent to support its customer service team.
The agent needs to:
- read messages from a shared mailbox;
- understand the incoming request;
- find an answer in SharePoint;
- prepare a reply;
- suggest the appropriate document;
- send the response;
- update the customer record in a business application.
The process appears straightforward, but every step raises a security question.
The shared mailbox may contain confidential information. The document found in SharePoint may not be suitable for the customer. An incoming message may include an instruction designed to influence the agent. Updating the business application may also change important data.
Applying Zero Trust means controlling four elements:
- the agent’s identity;
- the data it can access;
- the tools and connectors it can call;
- the actions it can perform.
Give every agent its own identity
An agent should not remain an anonymous technical component. It should not share an account with an employee, administrator or several other automated processes.
Microsoft Entra Agent ID represents agents in Microsoft Entra ID through specialised identities. Each agent can therefore be distinguished from human users and traditional applications.
An agent identity has a unique identifier. It can be linked to a reusable model called an agent identity blueprint, which defines a type of agent and helps apply consistent policies across several agent instances.
It can also be associated with a human sponsor who is accountable for the agent’s purpose.
The Microsoft Entra Agent ID documentation (opens in a new tab) describes these identity components and how they work.
This makes it possible to answer essential questions:
- Which agent accessed the resource?
- Which permissions were granted to it?
- Who is accountable for its use?
- Which user or process triggered the action?
- How can the agent be suspended without affecting other agents?
- Does the agent still need its current access?
In our example, the customer service agent should have its own identity. It should not reuse an employee’s account.
Two responsibilities should also be distinguished:
- the business sponsor, accountable for the business need served by the agent;
- the technical owner, responsible for its configuration, security and operation.
If the sponsor leaves the company or the business process is discontinued, the organisation should be able to reassign responsibility or deactivate the agent.
A separate identity does not eliminate every risk. It does, however, provide the foundation for least privilege, traceability and proper removal of access.
Limit the data the agent can access
An agent should not be given access to all available information simply because broad permissions make development easier.
The agent in our example needs:
- access to the customer service mailbox;
- a defined collection of approved documents;
- selected fields in the business application.
It probably does not need access to human resources records, supplier contracts or every SharePoint site in the organisation.
This requires the organisation to understand where sensitive information is stored, how it is classified and who can currently access it.
Classify information with Microsoft Purview
Microsoft Purview Information Protection uses sensitivity labels to distinguish between information levels such as:
- public;
- internal;
- confidential;
- highly confidential.
A sensitivity label can also apply protection measures such as encryption or usage restrictions.
The organisation could therefore decide that a document labelled “highly confidential” must never be attached automatically to an external response.
Microsoft 365 Copilot respects existing permissions. When information is protected through sensitivity labels and encryption, additional usage rights may be required before that content can be used in a response.
Microsoft’s documentation on protecting generative AI applications with Purview (opens in a new tab) describes these mechanisms and the prerequisites that organisations should review.
Prevent data loss
Microsoft Purview Data Loss Prevention policies, usually referred to as DLP policies, can identify sensitive information and control the related actions.
Depending on the licences and locations covered, a DLP policy may:
- detect sensitive information;
- warn the user;
- request a justification;
- block an operation;
- record the event for investigation.
In our scenario, the control should not only examine the document found in SharePoint. It should also consider the drafted message, attachment, recipient and communication channel.
Identify oversharing and risky AI use
Microsoft Purview Data Security Posture Management provides visibility into risks associated with organisational data and AI use.
It can help identify:
- sensitive data that is accessible too broadly;
- interactions with AI applications;
- sensitive content used in prompts or responses;
- recommendations for reducing exposure.
Microsoft Purview can also provide audit events for supported interactions with Copilot and AI applications. Prompts, responses and references to accessed files can contribute to audit activities and, depending on the available licences, investigation and compliance processes.
No tool can replace missing governance. If permissions are excessive and nobody understands the sensitivity of the documents, the organisation must first regain control of its data.
Control connectors and actions
Agents built in Microsoft Copilot Studio can use knowledge sources, connectors, HTTP requests, triggers and other tools.
These capabilities should not all be available under the same conditions.
Data policies in the Power Platform admin centre can control areas including:
- maker and user authentication;
- knowledge sources;
- actions and connectors;
- HTTP requests;
- publication channels;
- triggers;
- selected autonomous capabilities.
Microsoft’s documentation on security and governance in Copilot Studio (opens in a new tab) also covers capabilities such as pre-publication security analysis, visibility into connector dependencies, audit logging and the routing of makers into controlled environments.
A practical approach is to separate three environments:
- an experimentation environment using non-sensitive data;
- a validation environment with stronger controls;
- a production environment limited to approved sources and connectors.
This reduces the risk of a quickly built prototype becoming a production process without a proper security review.
Decide what the agent may do by itself
Not all actions carry the same level of risk.
Actions that may be automated
The agent could, for example:
- classify a request;
- identify its subject;
- search approved documentation;
- prepare a draft;
- suggest an appropriate attachment.
These actions generate an intermediate result without immediately producing an external effect.
Actions that require approval
Human confirmation may be required before the agent:
- attaches a confidential document;
- sends an external message;
- changes an important record;
- updates the status of a request;
- makes a commitment on behalf of the organisation.
Approval should provide meaningful control. It should not become another prompt that users accept automatically without checking.
Actions that should remain prohibited
Some operations may be excluded from the initial scope:
- changing permissions;
- permanently deleting data;
- using an unapproved connector;
- contacting an unverified recipient;
- executing a transaction;
- accessing an unapproved source.
The objective is not to remove all autonomy. It is to align the level of autonomy with the potential impact of the action.
Protect the agent from the content it processes
An agent does not only receive instructions entered by its user. It may also read emails, documents, web pages or data from external applications.
This content can include an instruction designed to influence the AI’s behaviour. This risk is known as indirect prompt injection.
In our scenario, a message sent to customer service could attempt to persuade the agent to ignore its original objective, search for unrelated information or use an unnecessary tool.
No single protection is sufficient. The organisation should combine:
- analysis of incoming content;
- limited permissions;
- approved knowledge sources;
- controlled connectors;
- human approval for sensitive actions;
- usable audit logs;
- the ability to suspend the agent quickly.
The underlying Zero Trust principle remains unchanged: content should be treated as potentially untrusted, even when it enters an apparently routine process.
Choose a level of protection that fits the organisation
The most advanced solution is not automatically the most appropriate. The organisation should start with its risks, regulatory obligations and ability to operate the available security tools.
Microsoft 365 Business Premium for the foundations
For a small or medium-sized business with up to 300 users, Microsoft 365 Business Premium includes:
- Microsoft Entra ID Plan 1 for identity and Conditional Access;
- Microsoft Intune Plan 1 for device management and compliance;
- Microsoft Defender for Business for endpoint protection;
- Microsoft Defender for Office 365 Plan 1 for email and file protection;
- Microsoft Purview information protection and DLP capabilities.
Microsoft’s documentation on the security capabilities available with Business Premium (opens in a new tab) describes this foundation and the available extensions.
These capabilities can strengthen authentication, apply access conditions, manage devices, protect endpoints and establish an initial information classification approach.
A licence does not configure itself. Conditional Access policies, device compliance, Defender protections and DLP policies still need to be designed, tested and maintained.
Microsoft Defender Suite for stronger detection and investigation
Microsoft Defender Suite for Business Premium extends that foundation with:
- Microsoft Entra ID Plan 2;
- Microsoft Defender for Endpoint Plan 2;
- Microsoft Defender for Identity;
- Microsoft Defender for Office 365 Plan 2;
- Microsoft Defender for Cloud Apps;
- Microsoft Defender XDR.
This becomes relevant when an organisation needs to identify unapproved AI services, correlate signals across identities, endpoints and email, and conduct more detailed investigations.
Microsoft Defender for Cloud Apps can help discover unauthorised cloud applications. Microsoft Defender XDR can bring several related signals together as a single incident.
The organisation must still decide who will review alerts and how response actions will be handled. Accumulating alerts without a response process does not provide effective security.
Microsoft Purview Suite for data security and compliance
Microsoft Purview Suite becomes relevant when requirements extend beyond basic classification and DLP.
It can strengthen:
- data classification;
- data loss prevention across several channels;
- insider risk management;
- auditing;
- eDiscovery;
- communication compliance;
- retention of AI interactions;
- visibility into data and agent-related risks.
This level is particularly useful when Copilot or agents use many internal sources, when regulatory obligations apply or when the organisation regularly handles personal, financial or contractual information.
The progression is not necessarily Business Premium, followed by Defender, followed by Purview. A company may have advanced data security requirements without operating a large security operations centre.
The choice should follow the organisation’s actual risks.
Govern agents at scale with Microsoft Agent 365
When several teams create agents across different platforms, a central inventory becomes necessary.
Microsoft Agent 365 provides a central control plane for discovering, managing, governing and securing Microsoft and third-party agents.
The official Microsoft Agent 365 service description (opens in a new tab) distinguishes between two levels of capabilities.
Several Microsoft 365 plans provide foundational capabilities such as:
- agent inventory;
- publication and approval;
- blocking or deleting agents;
- assigning agents to users and groups;
- reassigning agent ownership;
- automating selected lifecycle actions.
Advanced capabilities require Microsoft Agent 365 or Microsoft 365 E7. They include:
- enhanced observability and detailed activity tracking;
- centralised policy templates;
- control over the tools available to agents;
- access packages that restrict permissions;
- sponsor-led lifecycle policies;
- Conditional Access for agent identities;
- audit and eDiscovery for agent interactions;
- DLP applied to content accessed or shared by agents;
- detection of suspicious activity;
- integration with Microsoft Defender, Purview, Entra and Intune.
Microsoft 365 E7 combines Microsoft 365 E5, Microsoft 365 Copilot, Microsoft Entra Suite and Microsoft Agent 365. This may suit organisations that intend to deploy Copilot and a significant number of agents at scale.
It is not a required destination. For many small and medium-sized businesses, Business Premium with carefully selected additions remains more proportionate.
Plan for the end of the agent’s lifecycle
An agent that is secure when launched can become a risk over time.
Its owner may change. A new data source may be added. Its permissions may expand. The business need may disappear without the agent being deactivated.
Governance should therefore cover the entire lifecycle:
- define the need and responsibilities;
- create a separate identity;
- restrict permissions;
- approve the data and tools;
- test the agent’s behaviour;
- monitor its activities;
- review access regularly;
- deactivate the agent and remove its permissions when the need ends.
An agent without a sponsor, owner or verified use should be treated like any other access that is no longer justified.
Fourteen questions to answer before deploying an agent
- Which business problem will the agent solve?
- Who is its business sponsor?
- Who is responsible for its technical administration?
- Does it have a separate identity?
- Which data can it access?
- Has sensitive information been identified?
- Which connectors and tools can it use?
- Which actions can it perform independently?
- Which actions require human approval?
- How will its activities be logged?
- Who will review the alerts?
- How can the agent be suspended quickly?
- How frequently will its permissions be reviewed?
- How will access be removed when the project ends?
If several answers remain unclear, the project does not necessarily need to be abandoned. Its scope can be reduced by using fewer data sources, fewer connectors, fewer actions or additional human approval.
A service:microsoft-365-security-assessment delivered by MC3 Cloud can help review the identities, permissions, devices, sharing settings and protections already in place before the organisation expands its use of Copilot or AI agents.
Explore these topics at our December events
MC3 Cloud is organising ZeroTrust Days Copilot 2026 in two locations:
- 9 December 2026 in Réunion, at the SFR Amphitheatre in Le Port;
- 10 December 2026 in Mauritius, at Hennessy Park Hotel in Cybercity Trianon.
Seyfallah Tagrerout, Microsoft MVP Security and Microsoft Regional Director, will cover the risks associated with generative AI, sensitive data protection, agent identities, permissions and the role of Microsoft Entra ID. Demonstrations will connect these principles with practical situations.
- Register for the Réunion event (opens in a new tab)
- Register for the Mauritius event (opens in a new tab)
On 22 December 2026, MC3 Cloud will also host an executive security roundtable at the Labourdonnais Waterfront Hotel in Mauritius, with remote participation available through Microsoft Teams.
Patrick Beeharry, Vice President of Strategy & Operations for the Microsoft Security Division, will share Microsoft’s perspective on security, artificial intelligence, data governance and the priorities organisations should anticipate.
This non-technical session is designed for business leaders, CIOs, CISOs and senior IT decision-makers. It will extend the discussion beyond technical controls to include governance, accountability, investment priorities and organisational readiness for wider AI adoption.
Places will be limited to preserve the quality of the discussion. To request a place, contact your MC3 Cloud account manager.
Next article: turning technical controls into business decisions
Giving agents their own identities, restricting their permissions and protecting organisational data provides a technical foundation.
These controls do not, however, answer every strategic question:
- Which uses should the organisation authorise?
- What level of risk is acceptable?
- Which decisions must remain human?
- Who is ultimately accountable for an agent?
- Which investments are genuinely necessary?
- Under which conditions can a pilot be expanded?
The third article in this series will explore how Zero Trust can become a business strategy that enables AI adoption without treating innovation and security as opposing objectives.
