{"id":7941,"date":"2026-04-27T12:35:10","date_gmt":"2026-04-27T12:35:10","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=7941"},"modified":"2026-04-27T12:35:10","modified_gmt":"2026-04-27T12:35:10","slug":"microsoft-patched-an-agent-only-role-that-was-not","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=7941","title":{"rendered":"Microsoft patched an \u2018agent-only\u2019 role that was not"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

An administrative role meant for AI agents within Microsoft\u2019s Entra ID<\/a> ecosystem could allow privilege escalation and tenant takeover attacks, as it had privileges over more than agent-related objects.<\/p>\n

Researchers at Silverfort found that users assigned to Microsoft\u2019s \u201cAgent ID Administrator\u201d role, scoped to agent-related objects like blueprints and agent identities, could take ownership of unrelated service principals<\/a> across the tenant. These users could then attach credentials and authenticate as those applications (unrelated services) to potentially manipulate app-to-app communication inside enterprise environments.<\/p>\n

\u201cPrior to the fix, the Agent ID Administrator role allowed assigning ownership over service principals beyond agent-related identities, effectively enabling similar capabilities to roles such as Application Administrator, but without being scoped specifically to agent use cases,\u201d Silverfort researchers said in a blog post.<\/a><\/p>\n

Microsoft has reportedly patched the issue across all cloud environments, blocking the role from modifying non-agent service principals. The cloud giant did not immediately respond to CSO\u2019s request for comments.<\/p>\n

Agent-only briefly meant everything<\/h2>\n

The problem was a failure in scope enforcement within a new agent identity security offering.<\/p>\n

Introduced as part of Microsoft\u2019s push to operationalize AI agents through its Agent Identity Platform<\/a>, the Agent ID Administrator role is an effort to give autonomous agents their own governed identities inside Entra ID.<\/p>\n

The role was designed to operate within a newly introduced set of objects tied to AI agents. However, because agent identities are ultimately built on the same primitives as applications, namely service principals, the boundary between \u201cagent\u201d and \u201cnon-agent\u201d objects was not properly defined.<\/p>\n

This architectural confusion could allow role holders to add themselves as owners of a wide range of service principals across the tenant<\/a>. But the same action was blocked for application objects, suggesting the flaw was specific to the service principal layer rather than the broader identity model.<\/p>\n

Application object and service principal are two related objects created every time an application is registered in Microsoft Entra ID.<\/p>\n

\u201cThe application object serves as the global definition of the app and describes its configuration,\u201d the researchers explained. \u201cThe service principal represents the app as an identity within a tenant and is the object that authenticates, is assigned roles and permissions, and accesses resources.\u201d<\/p>\n

The lack of definition allowed privilege expansion, allowing the role to mimic capabilities of a higher-privileged role like an Application Administrator. This was happening by default and did not trigger any alarm, the researchers noted.<\/p>\n

<\/a>From principal ownership to full takeover<\/h2>\n

Once ownership of a service principal was obtained, the attacker could generate new credentials like client secrets or certificates, and use them to authenticate as the compromised application. If the application held elevated directory roles or sensitive API permissions, the attackers could inherit those privileges.<\/p>\n

\u201cThe impact depends on the privileges assigned to the targeted service principal,\u201d the researchers said. \u201cIn environments where service principals are widely used or hold elevated permissions, this can lead to significant escalation. Tenant posture can further influence the impact, for example in cases of broadly consented applications or permissive configurations.\u201d<\/p>\n

The researchers noted that Agent ID Administrator is fairly new and isn\u2019t in wide use yet, but the service principal-based escalation path is. \u201cAbout 99% of tenants have at least one privileged service principal (not necessarily agent-related),\u201d they said. Of them, more than half use agent identities averaging around 100 per tenant, creating a \u201creal risk.\u201d<\/p>\n

Microsoft Security Response Center (MSRC) told Silverfort that an internal fix was fully rolled out by April 9, 2026, requiring no further user action. Researchers still published a few recommendations along with detection steps to help users identify and respond to similar patterns.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

An administrative role meant for AI agents within Microsoft\u2019s Entra ID ecosystem could allow privilege escalation and tenant takeover attacks, as it had privileges over more than agent-related objects. Researchers at Silverfort found that users assigned to Microsoft\u2019s \u201cAgent ID Administrator\u201d role, scoped to agent-related objects like blueprints and agent identities, could take ownership of […]<\/p>\n","protected":false},"author":0,"featured_media":7942,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-7941","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/7941"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=7941"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/7941\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/7942"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7941"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7941"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7941"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}