Microsoft’s agentic AI platform is expanding fast. The security principles that should govern it are older than the technology itself.
May 2026 | 7 min read
At a Glance
1. Why Agent Identity Is Now a Security Priority
Most organizations now have AI agent identity security running somewhere in their Microsoft 365 environment. Copilot Studio agents answering HR queries. Power Automate flows trigger actions in SharePoint. Azure AI Foundry workloads are processing documents. In many cases, IT did not build them and does not know they exist.
The principle of least privilege, meaning every system, user, or process should have only the access it strictly needs to perform its function, is a foundational security principle. It is how you limit the blast radius when something goes wrong. It has been applied to service accounts for decades. Now it applies to AI agents, and most organizations are not ready for that.
Microsoft Security Blog data from February 2026 put 80% of Fortune 500 companies as running active AI agents. The governance frameworks to control them have not kept pace. Agent identity security — who an agent is, what it can access, and who is accountable for it — is the gap.
2. The Principle of Least Privilege Applied to AI Agent Identity Security
Least privilege access is not a new idea. In traditional IT, you apply it to user accounts, service accounts, and application permissions. The rule is simple: give the minimum access required to do the job, revoke it when the job is done, and review it regularly.
AI Agent identity security breaks the practical application of this rule in several ways. First, they are often provisioned with broad permissions to ensure they can operate across multiple scenarios. An AI agent identity security analyzing financial reports might be granted access to all financial data in SharePoint rather than the specific folder it needs. Second, agents accumulate permissions over time as their use cases expand and nobody reviews the original grant. Third, agents can act autonomously, which means over-permissioned access is not just a compliance issue — it is an operational risk.
The challenge is compounded by the speed of adoption. When a developer builds a Copilot Studio agent in an afternoon and connects it to company data to test a use case, the permissions it inherits from the signed-in user can be substantial. If that AI agent’s identity security is then shared with a team, those permissions travel with it. The organization has created an identity with significant access that nobody has formally reviewed.
“An agent built in an afternoon can inherit the permissions of a senior analyst. Without governance, that access does not expire when the meeting ends.”
3. Agent 365: What Microsoft’s Control Plane Provides and Where It Stops
Microsoft Agent 365 became generally available on 1 May 2026. It is Microsoft’s first dedicated control plane for AI agent identity security, lifecycle, and access management. Each agent registered through Agent 365 receives a Microsoft Entra Agent ID, giving it a governed identity rather than operating under a user’s inherited credentials.
Agent 365 enforces security controls through several mechanisms: least privilege access policies that control which data, tools, and MCP servers an AI agent identity security can reach; lifecycle rules that expire inactive agents automatically and flag ownerless ones; and integration with Microsoft Purview for data protection policy enforcement and audit trails.
The coverage has a clear boundary. Agent 365 governs agents built and registered within the Microsoft ecosystem: Copilot Studio, Power Automate, and Azure AI Foundry agents registered under Entra ID. Agents built through third-party platforms, or agents operating under non-Entra identities, fall outside its reach. It is also a governance layer, not a visibility layer — it can enforce policies for agents it knows about, but it does not discover agents it does not know about.
Security risk: Over-privileged agent identities in Microsoft 365
AI agents provisioned with broad permissions represent a persistent access risk. An agent that can read all financial SharePoint sites, send emails on behalf of a user, or call external APIs without restriction is a potential exfiltration vector. OWASP’s Agentic Top 10 (2026) places Identity and Privilege Abuse (ASI03) as the third most critical risk in agentic AI systems. Prevention starts with a register of what agents exist and what they can access.
4. The Service Account Parallel: A Problem IT Teams Already Know How to Solve
IT teams have lived through this before. Service accounts proliferated in on-premise environments as applications needed identities to run. They accumulated permissions as requirements grew. They were rarely reviewed and almost never expired. When someone left the team that created them, they became orphaned: active, credentialed, and unmanaged. Microsoft 365 governance practice spent years catching up with that problem.
AI agents are the service account problem, accelerated. They spawn faster because citizen developers can build them. They acquire permissions more broadly because agentic use cases are not as well-defined as traditional service account functions. And they are harder to discover because they may operate under user identities rather than dedicated service principals.
The governance playbook for service accounts covers inventory, owner assignment, permission scoping, regular review, and automated expiry for inactivity. It applies directly to agents. The patterns already applied to licence and lifecycle management — identifying inactive identities, surfacing orphaned accounts, flagging permissions that have not been reviewed — are the same patterns that need to apply to agent identities. The governance principles do not change because the identity is non-human.
5. OWASP’s Agentic Top 10: What AI Agent Security Risks Look Like in Practice
OWASP published its Top 10 for Agentic Applications in 2026. Microsoft published guidance on addressing those risks in Copilot Studio on 30 March 2026. The list is worth understanding because it frames what least privileged access failure looks like in an agentic context.
ASI01 (Agent Goal Hijack) involves redirecting an agent through injected content: an email, a document, or a data feed that manipulates the agent into acting outside its intended scope. Least privilege limits the damage: an agent that can only write to a specific folder and read from a specific dataset cannot exfiltrate the whole tenant, even if it is manipulated.
ASI03 (Identity and Privilege Abuse) is the most direct: agents inherit delegated trust, credentials, or role chains and exploit them to gain unauthorized access. This is exactly the over-provisioning problem. An agent granted broad SharePoint access to cover a range of possible tasks is an ASI03 risk by design.
Zero-trust principles applied to agentic workloads treat every agent request as unverified until proven otherwise, scope tokens to the minimum required, and log every action for review. Organizations that have already deployed agents at scale without that framework in place need to get there quickly.
6. What Least Privilege Governance for Agents Looks Like in Practice
Building agent identity governance that actually works requires four things to be true simultaneously.
A register of what exists. You cannot govern what you cannot see. Agent identity management starts with discovery: what agents are running, what identities they hold, who owns them, and what they can access. For Microsoft ecosystem agents, Agent 365 provides this for registered agents. For agents operating outside Entra ID, manual discovery is required.
Scoped permissions by design. Every agent should be provisioned with the minimum permissions required for its stated purpose. Permissions added for convenience become permanent vulnerabilities. The person provisioning the agent should be required to justify each grant.
Owner assignment and review cadence. Every AI agent identity security needs a named owner responsible for confirming it is still needed, that its permissions are still appropriate, and that its behaviour is as expected. A quarterly review cadence for active agents and an automatic suspension trigger for agents with no confirmed owner within 90 days is a reasonable starting point.
Activity monitoring. Agents should be logged. What data did they access? What actions did they take? Were there anomalies? Microsoft Defender surfaces some agent-related alerts, and Purview provides audit trails for agents within Agent 365’s scope. Monitoring should be active, not forensic — catch unusual behaviour before it becomes a breach, not after.
None of this is technically complex. The challenge is organizational: building the process, assigning the ownership, and maintaining the discipline as the number of agents grows. The organizations getting this right now will not need to retrofit it later.
Frequently Asked Questions
What is the principle of least privilege for AI agents?
The principle of least privilege applied to agents means giving each AI agent identity security only the permissions it needs to perform its specific function, scoped as narrowly as possible, with regular review and automatic revocation for inactive agents. It prevents over-provisioned agents from becoming security risks.
What are the main AI agent identity security risks in Microsoft 365?
The main AI agent security risks in Microsoft 365 include identity and privilege abuse (agents operating with excessive permissions), goal hijacking through prompt injection, ownerless or orphaned agent identities, and agents operating outside IT visibility. OWASP’s Agentic Top 10 (2026) documents these in detail.
What does Microsoft Agent 365 do?
Microsoft Agent 365 (GA May 2026) is a control plane for AI agent identity and lifecycle management. It assigns each agent a Microsoft Entra Agent ID, enforces least privilege access policies, integrates with Purview for data protection, and provides lifecycle rules such as automatic expiry of inactive agents. It covers agents built in Copilot Studio, Power Automate, and Azure AI Foundry.
How does agent identity security governance relate to existing IT governance?
Agent identity governance follows the same principles as service account governance: inventory, owner assignment, permission scoping, regular review, and automated expiry. Organizations with strong identity governance frameworks are better positioned to extend those frameworks to AI agents.
About TeamsFox
TeamsFox is the Microsoft 365 management and optimization platform that gives IT teams tenant-wide visibility, evidence-based governance, and automated license and storage right-sizing. As AI agents become standard infrastructure, the governance principles TeamsFox applies to licences, identities, and permissions provide the foundation organizations need. Headquartered in Düsseldorf and trusted in 20+ countries, TeamsFox helps organizations reduce license spend by up to 30%, cut storage costs by 40%, and free up 60% of administrative time.