Google’s launch of Gemini agent brings another AI colleague into the workplace. Microsoft’s Satya Nadella has argued AI models should be treated as insider risks, trusted to work but never trusted blindly. In Microsoft 365, that means watching the settings an agent can change as closely as the agent itself.
Large organisations depend on Microsoft 365 and Entra for access to email, documents and business applications. An agent with sufficient administrative permissions can alter the controls protecting that access, including permissions governing its own reach. Allowed to act without approval at each step, it can repeat an unsafe change across the business before anyone intervenes.
An agent’s activity record might show that it completed every requested task. The tenant can still be less secure when it finishes.
How agents acquire more power than intended
Take a service-desk agent introduced to handle access requests and sign-in problems. Its purpose sounds limited. The permissions granted to get it working could be considerably broader.
Built-in administrative roles can cover settings and users beyond the intended task. Connecting the agent through an administrator’s account brings another question: how much access does that person already hold? For delegated access, the application’s permissions and the user’s access together determine what the agent can do.
Giving the agent a separate identity makes its permissions easier to inspect, provided somebody reviews them. A pilot can finish while the application and its access remain available for the next piece of work. The original approval then becomes the basis for tasks nobody assessed.
Staff can also connect some third-party tools themselves where tenant consent settings allow it. A service-desk team could begin using an assistant before central IT has examined its access. Finding out which identity it uses and what it can change becomes work done after the connection is live.
That pressure is visible in our research. 53% of IT leaders said AI initiatives were advancing faster than governance structures could support. Access decisions made to get an agent working quickly can remain unchecked as its responsibilities grow.
The agent can change the rules governing its work
The service-desk agent receives a ticket from users who cannot sign in. It identifies a Conditional Access policy as the obstacle. Its application has been granted permission to amend those policies, so it excludes the affected group.
The users can sign in again, potentially without an authentication or device requirement the organisation intended to enforce. The agent has resolved the immediate complaint by weakening the protection.
Its authority could extend further. If the same conventional application also holds the RoleManagement.ReadWrite.Directory application permission, Microsoft warns that it can grant additional privileges to itself, other applications or users. The permissions intended to define the agent’s reach can themselves become something it changes. Allowed to continue autonomously, the agent could apply the same approach to similar tickets elsewhere, extending the exposure before anyone reviews its work.
But it isn’t enough to set rules for an agent if the agent can change them. In Microsoft 365, those rules sit in permissions and configuration, and an agent with the right access can rewrite them while it works.
Many organisations have already found this out. More than half of large organisations (51%) have reversed AI-driven changes within Microsoft 365 due to security or governance concerns. But you can only reverse a change if you know what the agent altered and have a trusted version of your settings to go back to.
A completed task can leave an unsafe tenant
Judged on whether it finished the job, the service-desk agent did well. Users are signing in again. Compare the tenant with how it’s meant to be set up, and a different picture appears- a group taken out of a sign-in policy, and perhaps a role the agent gave itself.
To understand why, investigators need to link the tenant’s audit records to the agent’s request history. That shows which ticket started the work and whether anyone approved the exception. The audit record on its own shows what changed, but not why.
The baseline and monitoring arrangements also require protection from the agent’s authority. If it can alter the records or mechanisms used to check its work, oversight rests on settings it can change.
An alert has to reach somebody authorised to investigate and reverse the unsafe edit that day. Until then, the excluded group remains without the protection that policy provided.
Saved settings and change history allow the repair to preserve legitimate edits made by other administrators. Any additional privileges it granted itself require attention too. Leaving them in place gives the agent authority to repeat the change on its next request.
The service desk has resolved a sign-in problem only when users can work with the intended protection restored. A closed ticket cannot establish that. Observability is as important for a Microsoft 365 tenant as it is for the model.
_____
About Andrea Sivieri
Andrea Sivieri is Chief Product and Technology Officer at CoreView, where he leads product and technology strategy for the company’s Microsoft 365 tenant resilience and governance platform.
About CoreView
CoreView is the leading SaaS platform for Microsoft 365 tenant resilience. Trusted by enterprises worldwide, CoreView secures the configuration, identity, and access layers of Microsoft 365, hardening tenants against attack, reducing privilege and blast radius, detecting configuration tampering, and restoring security posture after incidents. By protecting Microsoft 365 and Entra at the tenant level, CoreView ensures organisations can prevent compromise, withstand intrusion, and recover with confidence from cyber threats and operational disruption.
Join our LinkedIn group Information Security Community!
