Securing Microsoft Identities At Agentic Speed

gettyImagine a presentation to an IT team showing an AI agent completing an administrative task in seconds. The demonstration works, the team sees the potential to scale, and someone asks how soon the agent can go into production. Before that happens, someone should ask what else the agent has permission to do, whether it can be constrained through a least-privilege delegation model and how the organization will recover if that authority is misused.

The biggest risk is not simply what an agent can do, but what the organization may authorize it to do without fully understanding the consequences. An agent’s assigned task and its broader access can be very different things. If the task is narrow but the permissions are broad, the organization has authorized far more than the business requested.

For enterprises built on Microsoft infrastructure, this is an immediate identity security concern. Agents may interact with Microsoft 365 data, cloud services and administrative workflows connected to Active Directory, impacting network resources and user identities.

The efficiency gains from AI are compelling, but organizations should be equally impatient about securing the infrastructure that makes those gains possible. If the Hugging Face incident demonstrated anything, it is that every decision to expand an agent’s reach should come with a clear decision about its limits.

Agents can present an identity threat in two ways. First, attackers can use them to automate steps in an intrusion. Second, legitimate agents can become a route to sensitive systems if their credentials are stolen or their actions are manipulated. Organizations need to prepare for both.

Neither scenario requires AI to break through every defense. An attacker who obtains a credential with excessive privileges already has an opportunity. Automation can exploit that opportunity with less manual effort. A compromised internal agent presents a related problem because it may already have permission to perform useful and consequential work.

Microsoft’s guidance on securing autonomous agents makes the identity connection explicit. It calls for unique, traceable agent identities and access that is limited in scope and duration, with the ability to revoke it.

Organizations can act on the permissions they grant today, examine the systems those permissions reach and decide which actions carry too much business risk to run without additional checks. They should also determine how they will identify and reverse consequential changes that occur before access is revoked.

Before giving an agent access, organizations need to examine the work it will perform and the authority each step requires. These six practices can establish clear boundaries and maintain them as the deployment evolves.

Consider an agent intended to help with employee onboarding. Reading an approved request, creating an account and assigning access are separate decisions. Successfully reading the request should not automatically authorize every subsequent action. Each step needs an appropriate permission boundary.

The owner should be able to explain the agent’s purpose and approve access changes. Organizations should also review what the agent can reach across connected systems. An agent should not inherit a broad administrative account simply because that account makes integration easier.

This is particularly important in hybrid Microsoft environments, where a cloud workflow may rely on an identity or service that also has responsibilities on-premises. Reviewing one application in isolation can miss the consequences of that relationship. Access needs to be evaluated end to end, including the combined authority created by the workflow.

Routine work within a narrow scope can proceed automatically. Granting elevated privileges or making widespread administrative changes deserves a check before execution.

Ask the team to demonstrate that the agent cannot make an unauthorized change, even when instructed to do so. Demonstrating what the agent is prevented from doing can be as valuable as demonstrating what it accomplishes.

Security teams need to connect consequential changes to the identity responsible and understand whether its access has expanded. A new integration should trigger another review. Otherwise, an agent approved for a modest task can gradually acquire responsibilities that nobody has evaluated together.

Agentic speed also changes what organizations should expect from incident response. A process that depends on finding the right administrator, explaining the situation and determining how to revoke access introduces unnecessary delay. The procedure should be established in advance and tested to confirm that it stops activity across connected systems.

Containing the activity is only part of the response. The changes already made still need to be addressed. If an identity was granted inappropriate access, can the team identify and reverse it? If an incident broadly damages Active Directory, can the organization restore it to a trustworthy state?

Recovery belongs in the AI deployment conversation from the beginning because identity supports the business long after the demonstration ends. Applications and employees depend on it to work. When that infrastructure fails, the consequences can extend well beyond the agent that initiated the incident. A recovery exercise should establish what the team can restore, how the result will be validated and how long restoration takes, including what happens when normal administrative access is unavailable.

Organizations have every reason to pursue the productivity that agents can deliver. AI can reduce manual effort and help people act on what matters, but consequential decisions still require human judgment. That ambition needs to come with an investment in identity security and resilience. The people responsible for Microsoft infrastructure need to be involved while access decisions are being made, with enough time to test the controls and recovery procedures.

Before approving the next agent for production, ask for evidence of its limits and a demonstration of how the business will regain control and restore trust if something goes wrong. That is how organizations earn the confidence to let agents act.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?