Microsoft Agent 365 is GA. Agent identity is now an Administer-tier problem.

The Six-Week Window That Reframed Agent Identity

In a six-week window straddling the spring of 2026, two events combined to reframe how platform-engineering and security teams have to think about AI agents in production.

On April 9, 2026, the Microsoft Security Response Center finished rolling out a tenant-side patch for a flaw in the Entra Agent ID Administrator role that the Silverfort research team had quietly disclosed on March 1 (after discovering it on February 24). The role was scoped, on paper, to Blueprints and Agent Identities — agent-only objects in Microsoft’s new agent-identity directory. In practice, anyone who held the role could become the owner of any Application Service Principal in the tenant, add their own credential, and then authenticate as that principal. Approximately 99% of business networks utilize privileged Service Principals; the path from “agent-only Administrator” to “global admin impersonation” was three API calls long.

On May 1, 2026, Microsoft Agent 365 became generally available — the new control plane for AI agents at $15 per user per month, organized around three pillars Microsoft is calling Observe, Govern, Secure. Microsoft Entra Conditional Access extends Zero Trust policies to agents acting independently and to agents acting on behalf of users. A registry-sync into AWS Bedrock and Google Cloud entered public preview, letting the Agent 365 inventory discover agents that live outside Microsoft’s own surfaces. Agents now ship into production with their own identities, their own conditional-access decisions, their own audit trails, and their own license-and-billing line items.

Together, the two events make a structural claim: agent identity is now an Administer-tier governance problem, with all the same blast-radius, separation-of-duties, and audit-trail requirements that IAM has carried for the last fifteen years. Platform-engineering teams that were planning to defer agent-identity governance to the agent vendor have lost that option.

Why the Agent ID Surface Is Materially Different

Three structural traits make agent identity a different problem from user or service-principal identity:

• Agents have permissions that humans never grant themselves. A human DevOps engineer goes through a manual approval process to escalate from a read-only IAM role to a write role. An agent — by design — has a broad, pre-authorized scope that lets it Operate without per-action approval. The agent’s standing scope is the floor on the blast radius, not the ceiling.
• Agents act on schedules, not on conscious intent. A compromised user account leaves a behavioral trail — login times, IP geolocation, application-launch sequences. A compromised agent acts on a polling loop. The behavioral baseline that catches user-credential abuse does not catch agent-credential abuse without explicit instrumentation.
• Agent identities are themselves an inventory problem. Agent 365 ships with a registry-sync into AWS Bedrock and Google Cloud because the obvious first question — “how many agents do we have, where do they run, and what do they have access to?” — is unanswerable for most organizations today. Without inventory, governance is theatre.

The Silverfort Entra Agent ID disclosure was a textbook example of all three: a single agent-scoped role admin could escalate to global-admin impersonation in three API calls, the activity looked like normal Graph API traffic, and most organizations did not know they had assigned the role at all.

The Microsoft Agent 365 Frame — And What It Doesn’t Cover

The Agent 365 framing is the strongest single piece of public language in 2026 around agent governance. Observe / Govern / Secure maps cleanly to the Observe / Operate / Administer capability-tier model that platform-engineering teams have been moving toward independently. The Conditional Access extension to agents is a meaningful primitive: it lets organizations express, in policy, the same risk-based gates they apply to human sign-ins, applied to the agent’s own session.

The Agent 365 frame has three limits that platform-engineering teams have to fill themselves:

1. The registry is Microsoft-centric. Registry-sync to AWS Bedrock and Google Cloud is in public preview; the Microsoft surfaces are GA. Agents running on Anthropic via API, on self-hosted inference (LMDeploy, vLLM, SGLang), or on niche vendor surfaces are not first-class inventory items. The Agent 365 registry will under-count.

2. The pricing model is per-user, not per-agent-action. $15 per user per month gets a customer the Agent 365 control plane. The pricing model assumes a per-user attribution that does not match the way agents actually create cost — agents act on behalf of teams, on behalf of schedules, on behalf of upstream events. Per-user pricing makes the cost-accounting line item easy and the actual workload attribution wrong.

3. The control plane is not the operating layer. Agent 365 is a dashboard-and-policy layer. It tells the security team where their agents are, what they are doing, and whether the policy is satisfied. It does not act on the agents. The cross-cloud agent-identity drift, the unowned service principal cleanup, the rotation of compromised agent credentials, the application of a new conditional-access policy across two thousand agents — those are operational actions that require an operational-agent layer above the dashboard.

The Cross-Cloud Agent-Identity Governance Pattern

Five questions every platform-engineering team should put on its agent-identity governance roadmap for the next two quarters:

1. What is the agent registry? Single source of truth for every agent identity in production, across Microsoft Entra Agent ID, AWS IAM Roles Anywhere / Bedrock agents, Google Cloud workload identity, Anthropic API keys, and self-hosted inference endpoints. The registry has to live above any single cloud’s control plane.

2. What is the scope-of-action policy per agent? Each agent identity has an explicit capability-tier classification — Observe / Operate / Administer — and an explicit list of resources it can touch within that tier. Anything outside the list is a denial, audited as a denial.

3. Who owns the model keys, and how do they rotate? BYOK on model keys is the lower-risk shape. The keys live in the customer’s secret store, not the agent vendor’s. Rotation is a scheduled operational action, not a manual one.

4. What does the immutable audit trail capture? Every agent action, every Administer-tier approval, every conditional-access decision, every credential rotation, every scope change. The audit trail is the reconciliation artifact for internal audit, external auditors, and cyber insurance.

5. What enforces separation of duties on identity-changing actions? Any agent action that changes IAM, billing, or the approval policy is Administer-tier. The human approving the change cannot be the human who proposed it. This is the structural answer to the Silverfort-discovered Entra Agent ID overreach.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

How IAN Helps: The Compliance Agent on the Active Operational Layer

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents on the active operational layer. The compliance agent inside the IAN team is built to sit above the cross-cloud agent-identity registry that Agent 365 only partially covers:

• Cross-cloud agent registry. The compliance agent inventories agent identities across Entra Agent ID, AWS IAM Roles Anywhere, AWS Bedrock agents, Google Cloud workload identity, and self-hosted inference endpoints. The registry is the customer’s own database — it is not Microsoft’s, AWS’s, or Google’s.
• Capability-tier classification per agent. Each registered agent identity is classified Observe / Operate / Administer with an explicit list of resources it can touch. Drift between classification and actual scope is detected and surfaced as an Operate-tier remediation candidate.
• BYOK on model keys. Customers bring their own Anthropic / OpenAI / model-provider keys, stored in the customer’s secret manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault). Rotation is a scheduled Operate-tier action with an explicit audit trail.
• Immutable audit trail in the customer’s database. Every compliance-agent action, every Administer-tier approval gate, every drift detection, every credential rotation lands in the customer’s per-tenant audit-trail store. The audit trail is the reconciliation artifact, and it is not the vendor’s database.
• Separation-of-duties on Administer-tier. IAM, billing, org-policy, and approval-policy changes always require explicit human approval, with separation-of-duties enforced — the human approving the change cannot be the human who proposed it.

The combined effect is an agent-identity governance layer that addresses the structural shape the Silverfort disclosure exposed and the cross-cloud limit the Agent 365 registry-sync ships with.

The Three-Phase Rollout

Phase 1 — Inventory every agent in production. Stand up the cross-cloud agent registry. Pull from Entra Agent ID, AWS IAM, Bedrock agents, Google Cloud workload identity, and self-hosted inference endpoints. Most organizations are surprised by the count. Two-to-four weeks.

Phase 2 — Classify every agent into a capability tier. Apply the Observe / Operate / Administer classification, pre-authorize the Operate-tier scopes, and codify the Administer-tier approval-gate policy. Wire the conditional-access policies in Entra Agent ID (and equivalents on AWS and GCP) to match. Two-to-three months.

Phase 3 — Cross the compliance / security / cost agent loop. Once the inventory is live, its outputs feed the security-agent’s exposure scoring, the cost-agent’s per-agent attribution model, and the SRE-agent’s incident-investigation context. Agent-identity drift becomes an Operate-tier remediation candidate, not a quarterly audit finding.

Microsoft Agent 365 going GA is the strongest piece of public framing on agent governance to date. The Silverfort Entra Agent ID disclosure is the strongest piece of public evidence on why the framing matters. The active operational layer is built for the sequence — agent identity is now an Administer-tier problem, not a backlog item.

Get a free infrastructure audit → | See pricing →