← Back to Cybersecurity News Center
Severity
HIGH
CVSS
7.5
Priority
0.574
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
Microsoft patched a privilege escalation flaw in a built-in Entra ID role called Agent ID Administrator, introduced to manage AI agent identities, that allowed an attacker with access to the role to seize control of service principals beyond its intended boundary. According to security researchers, the role's permissions were not properly scoped, creating a lateral movement path inside Entra ID tenants. The finding signals a broader governance risk: AI agent frameworks are generating new identity objects and roles that most organizations' access control review processes were not designed to evaluate.
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
HIGH
High severity — prioritize for investigation
TTP Sophistication
MEDIUM
3 MITRE ATT&CK techniques identified
Detection Difficulty
MEDIUM
Standard detection methods apply
Target Scope
INFO
Microsoft Entra ID (Agent ID Administrator built-in role)
Are You Exposed?
⚠
You use products/services from Microsoft Entra ID (Agent ID Administrator built-in role) → Assess exposure
⚠
3 attack techniques identified — review your detection coverage for these TTPs
✓
Your EDR/XDR detects the listed IOCs and TTPs → Reduced risk
✓
You have incident response procedures for this threat type → Prepared
Assessment estimated from severity rating and threat indicators
Business Context
Organizations running Microsoft Entra ID with AI agent features enabled faced a window during which an insider or external attacker who obtained a single role assignment could pivot to control service principals across the tenant, potentially accessing cloud resources, applications, and data those principals are authorized to reach. For enterprises in regulated industries or those with large Entra ID footprints, a successful service principal takeover can bypass application-layer access controls without triggering conventional account compromise alerts. The incident underscores a governance cost that comes with AI adoption: every new AI framework integrated into identity infrastructure requires dedicated access control review, and skipping that step compounds identity risk at scale.
You Are Affected If
Your organization uses Microsoft Entra ID and has enabled AI agent or Copilot features that create service principals
The Agent ID Administrator built-in role is assigned to any account or group in your tenant
Your Entra ID tenant includes service principals created by AI agent frameworks such as Microsoft Copilot Studio or Azure AI Foundry
Your identity governance process reviews role assignments by display name rather than by underlying API permission set
You have not applied the Microsoft patch addressing this Entra ID role flaw
Board Talking Points
A flaw in a Microsoft identity role designed for AI features allowed attackers to seize control of cloud service accounts across our environment, with a risk score of 7.5 out of 10.
IT and security teams should verify the patch is applied and audit all role assignments tied to AI features within the next five business days.
Without this review, a single compromised account holding this role could provide an attacker persistent access to cloud applications and data without triggering standard alerts.
Technical Analysis
The Agent ID Administrator role was added to Microsoft Entra ID to support AI agent identity lifecycle management, a function that creates and manages service principals representing AI agents within a tenant.
According to security researchers, the role's permission set was not constrained to agent-scoped service principals as intended.
An attacker who obtained the role, whether through direct assignment, a compromised account holding it, or a privilege escalation step from a lower-privilege position, could exercise control over service principal objects beyond the agent boundary.
This maps directly to MITRE ATT&CK T1078.004 (Valid Accounts: Cloud Accounts), T1098.001 (Account Manipulation: Additional Cloud Credentials), and T1548 (Abuse Elevation Control Mechanism), and aligns with CWE-269 (Improper Privilege Management) and CWE-732 (Incorrect Permission Assignment for Critical Resource). The attack path follows a recognizable pattern in cloud identity abuse: a role granted to support a narrow function carries implicit permissions that, when examined at the API level, are broader than the design label implies. Security teams reviewing role assignments by display name rather than the underlying permission set would not catch this gap. Microsoft has issued a patch. The research surfaces a systemic problem that extends beyond this specific role: as AI agent frameworks proliferate inside enterprise tenants, they add service principal objects and associated roles at a pace that outstrips current identity governance review cadences. Traditional access certification processes were built around human accounts and well-understood service account patterns; AI agent identities occupy a different category that most review tooling does not yet segment or flag. Sources: The Hacker News (T3), CSO Online (T3), Microsoft Entra documentation (T1).
Action Checklist IR ENRICHED
Triage Priority:
URGENT
Escalate to CISO and legal/compliance immediately if Entra ID audit logs show the Agent ID Administrator role was activated and followed by any `Update service principal`, `Add app role assignment to service principal`, or `Add delegated permission grant` operations during the exposure window, as this indicates active exploitation of the privilege escalation path with potential unauthorized access to downstream application identities that may hold access to regulated data (PII, PHI, financial records) triggering breach notification obligations.
1
Step 1: Assess exposure, determine whether your Entra ID tenant has the Agent ID Administrator role assigned to any user, group, service principal, or managed identity; pull current role assignments via the Entra admin center or Microsoft Graph API and review the Agent ID Administrator entry specifically.
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis: identifying scope of potential compromise by enumerating all principals holding the Agent ID Administrator role across the tenant
NIST IR-4 (Incident Handling)
NIST IR-5 (Incident Monitoring)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
CIS 5.1 (Establish and Maintain an Inventory of Accounts)
CIS 1.1 (Establish and Maintain Detailed Enterprise Asset Inventory)
Compensating Control
Run the Microsoft Graph API query without enterprise tooling using PowerShell with the Microsoft.Graph module (free): `Connect-MgGraph -Scopes 'RoleManagement.Read.Directory'; Get-MgDirectoryRole | Where-Object {$_.DisplayName -eq 'Agent ID Administrator'} | ForEach-Object { Get-MgDirectoryRoleMember -DirectoryRoleId $_.Id }`. Pipe output to CSV for offline review. For tenants without PowerShell access, use the Entra admin portal under Identity > Roles and administrators > search 'Agent ID Administrator' and export assignments manually.
Preserve Evidence
Before enumerating current assignments, export and preserve the Entra ID audit log (Microsoft Entra admin center > Monitoring > Audit logs) filtered on Category: 'RoleManagement' and Activity: 'Add member to role' targeting the Agent ID Administrator role — this captures historical assignment events that may indicate when and by whom the role was assigned, critical for establishing attacker dwell time. Also capture the Microsoft Graph unified audit log via `Search-UnifiedAuditLog -RecordType AzureActiveDirectory -Operations 'Add member to role'` for the past 90 days.
2
Step 2: Review controls, verify that Privileged Identity Management (PIM) is enforcing just-in-time activation and approval workflows for any built-in roles introduced in the past 12 months, including roles tied to AI or Copilot features; confirm that Conditional Access policies apply to accounts holding these roles.
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy: reducing the blast radius of the Agent ID Administrator privilege escalation path by enforcing JIT activation and Conditional Access before eradication steps are complete
NIST IR-4 (Incident Handling)
NIST AC-2 (Account Management) — specifically reviewing accounts with Agent ID Administrator assignment
NIST AC-6 (Least Privilege)
NIST IA-2 (Identification and Authentication — Organizational Users)
CIS 5.4 (Restrict Administrator Privileges to Dedicated Administrator Accounts)
CIS 6.3 (Require MFA for Externally-Exposed Applications)
CIS 6.5 (Require MFA for Administrative Access)
Compensating Control
For tenants without Microsoft Entra ID P2 (required for PIM), implement manual compensating controls: (1) Remove standing Agent ID Administrator assignments immediately and replace with break-glass procedures documented in a runbook; (2) Use Azure AD Conditional Access (available in P1) to require MFA and compliant device for any account retaining the role; (3) Set a calendar-based review reminder (weekly) to re-audit role assignments using the PowerShell command from Step 1 until PIM is licensed. Document the compensating control exception formally per NIST IR-4.
Preserve Evidence
Before modifying PIM settings, capture the current PIM role settings for Agent ID Administrator via Microsoft Graph: `GET https://graph.microsoft.com/v1.0/policies/roleManagementPolicies?$filter=scopeId eq '/' and scopeType eq 'DirectoryRole'` — this preserves the pre-remediation policy configuration as forensic baseline. Also export the Entra ID Sign-in logs (Entra admin > Monitoring > Sign-in logs) filtered on accounts holding the Agent ID Administrator role, specifically flagging any sign-ins from unexpected IPs, locations, or outside business hours, which would indicate the role was actively leveraged for service principal manipulation (MITRE T1078.004).
3
Step 3: Update threat model, add AI agent role misconfiguration as an explicit privilege escalation path in your Entra ID threat register; map to T1078.004, T1098.001, and T1548 and document detection logic for each.
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity: incorporating the Agent ID Administrator privilege escalation path into the organizational threat register and updating detection logic to prevent recurrence across AI-introduced Entra ID roles
NIST IR-8 (Incident Response Plan)
NIST RA-3 (Risk Assessment)
NIST SI-4 (System Monitoring)
NIST AU-2 (Event Logging)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 7.2 (Establish and Maintain a Remediation Process)
Compensating Control
Document detection logic as Sigma rules (free, open-source) targeting the three mapped techniques: (1) T1078.004 — Sigma rule on Entra audit log field `operationName: 'Add member to role'` where `targetResources.displayName: 'Agent ID Administrator'`; (2) T1098.001 — Sigma rule on `operationName: 'Add app role assignment to service principal'` initiated by a principal holding Agent ID Administrator; (3) T1548 — Sigma rule on service principal `oauth2PermissionGrants` modifications following Agent ID Administrator activation. Submit rules to the SigmaHQ community repo for peer review. Store rules in version control (Git) alongside your threat register entry.
Preserve Evidence
Before closing the threat model update, pull the Microsoft Entra ID audit log for all `Update service principal` and `Add app role assignment` operations performed by any principal holding the Agent ID Administrator role during the exposure window — this establishes whether the misconfigured role was exploited to modify service principal permissions (T1098.001), which is the specific lateral movement mechanism Silverfort identified, not just that the role existed.
4
Step 4: Communicate findings, brief identity and cloud security leads on the gap between role display names and underlying permission sets; frame the broader governance risk that AI-introduced roles are not being reviewed with the same rigor as legacy roles.
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity: lessons-learned communication specific to the governance gap that allowed Agent ID Administrator's overly broad service principal permissions to go unreviewed, and recommendations to extend role review processes to AI-platform roles
NIST IR-6 (Incident Reporting)
NIST IR-8 (Incident Response Plan)
NIST CA-7 (Continuous Monitoring)
NIST SI-5 (Security Alerts, Advisories, and Directives)
CIS 4.6 (Securely Manage Enterprise Assets and Software)
Compensating Control
Produce a one-page technical brief (no enterprise GRC tool required) that includes: (1) a side-by-side table of Agent ID Administrator's documented display-name permissions vs. the actual Graph API permissions Silverfort disclosed; (2) a list of all Entra ID built-in roles introduced since the tenant's Copilot or AI feature enablement date, extracted via `Get-MgDirectoryRole | Where-Object {$_.Description -match 'agent|copilot|AI'}` as a starting scope; (3) a recommendation to add these roles to the quarterly access review cycle. Distribute via secure email with read receipts to create an audit trail of notification per NIST IR-6.
Preserve Evidence
Before the briefing, extract and attach the raw Entra audit log evidence showing the Agent ID Administrator role's permission scope — specifically, retrieve the role's `rolePermissions` object via Microsoft Graph `GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleDefinitions?$filter=displayName eq 'Agent ID Administrator'` and capture the full `allowedResourceActions` list. This concrete permission list, compared against the role's stated purpose of managing AI agent identities, is the factual foundation for the governance gap discussion and should be included in the brief as an exhibit.
5
Step 5: Monitor developments, track the Microsoft Security Response Center for any follow-up advisories tied to Entra ID AI agent roles; subscribe to security research feeds for additional findings in this area.
IR Detail
Preparation
NIST 800-61r3 §2 — Preparation: establishing ongoing intelligence feeds and monitoring processes to detect follow-on advisories for the Agent ID Administrator vulnerability class and related AI-platform Entra ID roles before they are exploited
NIST SI-5 (Security Alerts, Advisories, and Directives)
NIST IR-2 (Incident Response Training)
NIST IR-3 (Incident Response Testing)
NIST AU-13 (Monitoring for Information Disclosure)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
Implement threat intelligence monitoring without a commercial TI platform: (1) Subscribe to the Microsoft Security Response Center RSS feed (https://msrc.microsoft.com/blog/feed) and filter for keywords 'Entra', 'agent', 'Copilot', 'service principal' using a free RSS reader with keyword alerting (e.g., Feedly free tier); (2) Set a Google Alert for `site:silverfort.com OR site:msrc.microsoft.com 'Entra ID' 'agent'`; (3) Create a recurring monthly calendar task for a 2-person team to re-run the Step 1 PowerShell role enumeration and diff against the prior month's CSV output to detect net-new Agent ID Administrator assignments or new AI-platform roles added by Microsoft without explicit tenant admin action.
Preserve Evidence
Establish a monitoring baseline now by documenting the current state of all Entra ID built-in roles with 'agent', 'copilot', or 'AI' in their display name or description, including their full `allowedResourceActions` permission sets pulled via Microsoft Graph. Store this as a dated snapshot in version control — future advisories from MSRC or Silverfort about related roles can be immediately cross-referenced against this baseline to assess whether your tenant is affected, rather than starting exposure assessment from scratch.
Recovery Guidance
After removing unauthorized Agent ID Administrator assignments and enforcing PIM with JIT activation, conduct a full audit of all service principals modified by any principal holding the Agent ID Administrator role during the exposure window — specifically check `oauth2PermissionGrants` and `appRoleAssignments` for unexpected delegated permissions added to high-value service principals (e.g., those with access to Exchange, SharePoint, or line-of-business APIs). Rotate credentials (client secrets and certificates) for any service principal that was within reach of the misconfigured role, even if no modification is confirmed, because the permission boundary failure means you cannot rule out undocumented access. Monitor Entra audit logs for `Sign-in` and `Service principal activity` events on affected service principals for a minimum of 30 days post-remediation to detect any persistence mechanisms established during the exposure period.
Key Forensic Artifacts
Entra ID Audit Logs — RoleManagement category: Events with operationName 'Add member to role' and 'Remove member from role' targeting Agent ID Administrator, establishing the full timeline of who held the role and when; extract via Microsoft Graph `GET /auditLogs/directoryAudits?$filter=category eq 'RoleManagement'`
Entra ID Audit Logs — ServicePrincipal category: Events with operationName 'Update service principal', 'Add app role assignment to service principal', and 'Add delegated permission grant' initiated by principals who held the Agent ID Administrator role during the exposure window — these are the specific write operations the misconfigured role enabled beyond its intended scope
Microsoft Graph roleDefinitions API response for Agent ID Administrator: The full `allowedResourceActions` array from `GET /roleManagement/directory/roleDefinitions?$filter=displayName eq 'Agent ID Administrator'` captures the actual permission set at time of investigation; preserve as a versioned snapshot since Microsoft may silently update the role definition post-patch
Entra ID Sign-in Logs for Agent ID Administrator holders: Filter on `appId`, `ipAddress`, `location`, and `conditionalAccessStatus` for all accounts that held the role; anomalous sign-in patterns (off-hours, unfamiliar geography, MFA bypass) indicate the role was actively used rather than merely assigned
Service Principal credential and permission state snapshots: For all service principals accessible to the Agent ID Administrator role, capture current `keyCredentials`, `passwordCredentials`, `appRoleAssignments`, and `oauth2PermissionGrants` via Microsoft Graph before any remediation — this preserves the post-exploitation state and enables comparison against pre-exposure configuration baselines to identify attacker-added persistence
Detection Guidance
Review Entra ID audit logs for assignments to the Agent ID Administrator role, particularly any assignments made by non-privileged accounts or automated processes.
Query Microsoft Graph audit logs (AuditLogs/directoryAudits) filtering on activity type 'Add member to role' where the role display name contains 'Agent' or 'AI'.
Hunt for service principal credential additions (T1098.001 ) that follow a role assignment event within the same session or short time window, as this pattern suggests an attacker establishing persistence after gaining the role.
Monitor for service principal modifications outside expected change windows, particularly changes to application credentials, owner assignments, or API permissions on service principals the organization did not explicitly create for AI agent workflows. In Entra ID Identity Protection, review risky sign-ins and risky service principals for accounts that hold or recently held the Agent ID Administrator role. Audit all service principals in the tenant to identify those created by AI agent frameworks versus those created through standard provisioning; any service principal with owner or credential-write permissions on other service principals warrants immediate review. Reference Microsoft's Zero Trust engineering systems guidance (learn.microsoft.com/en-us/entra/fundamentals/zero-trust-protect-engineering-systems) for baseline role and service principal hygiene controls.
Indicators of Compromise (1)
Export as
Splunk SPL
KQL
Elastic
Copy All (1)
1 tool
Type Value Enrichment Context Conf.
⚙ TOOL
Pending — refer to Silverfort research for published indicators
Silverfort's research into the Agent ID Administrator privilege escalation path may include specific permission sets, Graph API calls, or audit log signatures; the actual indicator values are not present in the available source material
LOW
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
Hard indicator (direct match)
Contextual (behavioral query)
Shared platform (review required)
IOC Detection Queries (1)
Known attack tool — NOT a legitimate system binary. Any execution is suspicious.
KQL Query Preview
Read-only — detection query only
// Threat: Microsoft Entra ID Agent ID Administrator Role Enabled Privilege Escalation to S
// Attack tool: Pending — refer to Silverfort research for published indicators
// Context: Silverfort's research into the Agent ID Administrator privilege escalation path may include specific permission sets, Graph API calls, or audit log signatures; the actual indicator values are not pres
DeviceProcessEvents
| where Timestamp > ago(30d)
| where FileName =~ "Pending — refer to Silverfort research for published indicators"
or ProcessCommandLine has "Pending — refer to Silverfort research for published indicators"
or InitiatingProcessCommandLine has "Pending — refer to Silverfort research for published indicators"
| project Timestamp, DeviceName, FileName, FolderPath,
ProcessCommandLine, AccountName, AccountDomain,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
MITRE ATT&CK Hunting Queries (2)
Sentinel rule: Sign-ins from unusual locations
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Locations = make_set(Location), LoginCount = count(), DistinctIPs = dcount(IPAddress) by UserPrincipalName
| where array_length(Locations) > 3 or DistinctIPs > 5
| sort by DistinctIPs desc
Sentinel rule: Privilege escalation / account modification
KQL Query Preview
Read-only — detection query only
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("Add member to role", "Add app role assignment", "Add owner to application", "Reset user password")
| extend Target = tostring(TargetResources[0].userPrincipalName), Actor = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, OperationName, Actor, Target, Result
| sort by TimeGenerated desc
No actionable IOCs for CrowdStrike import (benign/contextual indicators excluded).
No hard IOCs available for AWS detection queries (contextual/benign indicators excluded).
Compliance Framework Mappings
T1078.004
T1098.001
T1548
MITRE ATT&CK Mapping
T1098.001
Additional Cloud Credentials
persistence
T1548
Abuse Elevation Control Mechanism
privilege-escalation
Guidance Disclaimer
The analysis, framework mappings, and incident response recommendations in this intelligence
item are derived from established industry standards including NIST SP 800-61, NIST SP 800-53,
CIS Controls v8, MITRE ATT&CK, and other recognized frameworks. This content is provided
as supplemental intelligence guidance only and does not constitute professional incident response
services. Organizations should adapt all recommendations to their specific environment, risk
tolerance, and regulatory requirements. This material is not a substitute for your organization's
official incident response plan, legal counsel, or qualified security practitioners.
View All Intelligence →