The Identity Problem Hiding in AI Agent Deployments

1. Executive summary

CrowdStrike has published analysis identifying a structural identity-management weakness in enterprise AI agent deployments: OAuth access tokens conforming to RFC 9068 (JWT format) cannot accurately represent the relationship between an autonomous AI agent and the user on whose behalf it acts. The flaw is architectural rather than a specific CVE — no CVSS score or CISA-KEV entry applies. EMEA financial services deploying AI agents (e.g., for HR automation, code execution, or customer interaction) face the risk that agents operating with broad OAuth scopes cannot be constrained by fine-grained access controls or produce meaningful audit trails, creating conditions for privilege escalation and undetectable data access.

2. Regulatory framing

Article	Trigger (the fact in this item)	Practical impact
DORA Art. 17: ICT-related incident management process	AI agents acting outside intended scope without meaningful audit trails cannot be detected or managed under existing incident processes.	Financial institutions cannot rely on existing ICT incident processes to detect agent misuse; process gaps must be identified and addressed before deployment.
DORA Art. 28: ICT third-party risk — general principles	AI agents invoke other agents transitively, creating dynamic third-party dependency chains with no standard identity context.	Third-party risk assessment for AI agent ecosystems is not feasible with current OAuth token standards; contractual and technical controls with agent platform providers need review.
NIS2 Art. 21(2)(d): supply chain security measures	Transitive agent-to-agent invocation patterns create undocumented supply-chain dependencies.	Supply chain security measures must account for agent-to-agent invocation chains that bypass traditional vendor assessment.

3. Technical analysis & attack chain

Vulnerability mechanism

The issue resides in the mismatch between OAuth access token standards and multi-principal AI agent architectures. The MCP (Model Context Protocol) core spec recommends OAuth 2.1 for issuing access tokens to AI agents. Tokens may be issued in two modes:

User-subject tokens (OAuth code flow): The user is the subject; the agent identity is encoded only in the client_id field. No claim exists for agent instance identity or the agent-user relationship.
Agent-subject tokens (client credentials grant): The agent itself is the subject. There is no field in the JWT format (RFC 9068) to encode the user on whose behalf the agent is acting.

RFC 9068 defines standard claims for subject, client, and scope, but was designed for single-principal scenarios. It defines no claims for agent instance identity or the relationship between an agent and the user it represents.

Agentic AI usage patterns (identity risk progression)

CrowdStrike identifies four patterns with increasing identity risk:

Interactive — User drives an interactive AI client; user available for consent. Low identity risk (similar to browser session).
Offline — User kicks off a task and is unavailable until completion. Identity context must persist without user consent checkpoints.
Automated — Agents run autonomously, instantiated/terminated dynamically or continuously running, assigning tasks from a queue. No human in the loop.
Transitive — One agent invokes another agent to complete a subtask. Identity context is lost across the invocation boundary.

As agent autonomy increases, the inability to express identity context in the token becomes an active access-control failure.

Attack chain (confirmed steps from source material)

Initial positioning — An AI agent is deployed with OAuth access tokens granting access to sensitive systems (databases, APIs, files). Tokens are issued per MCP spec using OAuth 2.1.
Identity context loss — When the token is issued to the agent (client credentials grant), no claim encodes the user principal on whose behalf the agent acts. The receiving system cannot determine the actor or the nature of the agent-user relationship.
Scope overprivilege — Because the system receiving the request cannot determine the user principal, it cannot enforce fine-grained access controls. Access decisions fall back to the broad scopes encoded in the token.
Transitive expansion — An agent invokes another agent (transitive pattern). The second agent receives a request with no identity context about the original user or the first agent's instance identity. Each hop widens the access boundary.
Audit trail degradation — Without user principal or agent instance identity in the token, audit logs cannot attribute actions to a specific user or agent instance. Actions taken by the agent are not attributable.
Undetectable scope expansion — An agent acting outside its intended scope cannot be distinguished from legitimate operation because the audit trail lacks the identity context needed for anomaly detection.

Corroborating context (Red Canary)

Red Canary's analysis of Microsoft Entra Agent ID provides complementary detection perspective: autonomous agents can escalate privileges and persist within an Entra ID tenant. This corroborates the CrowdStrike assessment that agent identity gaps enable privilege escalation. This is single-sourced; verify before enforcement — the Red Canary source is a blog series primer, and specific IOCs, techniques, or detection rules were not available in the provided material.

Confidence caveat

No CVE, CVSS score, CISA-KEV entry, or named threat actor is associated with this item. The VERIFIED REFERENCE DATA resolved no entries. Attribution is not applicable (architectemic weakness, not actor-driven campaign). The CrowdStrike analysis is a single vendor's blog post; the Red Canary source provides partial corroboration of the privilege-escalation risk but does not independently confirm all claims.

4. Mitigation & containment

P1 — Within 24 hours

Inventory AI agent deployments. Identify all AI agents in production that use OAuth access tokens (OAuth 2.1 per MCP spec). Document: token issuance mode (user-subject vs. agent-subject), scopes granted, and resources accessed (databases, APIs, files).
Restrict agent-subject tokens. Where agents use client credentials grant (agent as subject), audit the scopes granted. Reduce to least-privilege. If the agent cannot function without broad scopes, flag as high-risk and require manual review of access logs.
Block transitive agent-to-agent invocation where possible. Disable or require explicit approval for any agent configuration that allows one agent to invoke another, until identity context can be propagated across the call.

P2 — Within 72 hours

Implement compensating access controls. Since OAuth tokens cannot encode agent-user relationships, implement application-layer controls that enforce user-principal context outside the token. For example, require agents to pass user identity in a custom header or application-level context that the receiving system validates independently.
Enable enhanced audit logging. Configure agent platforms to log: agent instance ID, invoking user (if known), action taken, resource accessed, and scopes used. Where the platform does not support this, log at the resource layer (API gateway, database audit) and correlate by token client_id.
Review Entra ID Agent ID configurations. Per the Red Canary analysis, autonomous agents can escalate privileges and persist in Entra ID tenants. Audit Entra ID for agent-created service principals, app registrations, or delegated permissions that were not administrator-approved.

P3 — Within 7 days

Establish agent identity governance. Define an internal standard for AI agent identity that supplements RFC 9068 JWT claims. At minimum: agent instance ID, user principal on whose behalf the agent acts, delegation chain (for transitive patterns), and scope justification.
Implement anomaly detection on agent access patterns. Since audit trails are degraded, deploy behavioural analytics on agent access: unusual resource access, scope expansion, off-hours activity, and transitive invocation patterns. Correlate with client_id in OAuth tokens.
Engage agent platform vendors. Require vendors to articulate their roadmap for agent identity context in OAuth tokens. This is an industry gap — no current standard solves it. Contractual provisions should require vendors to support custom claims or alternative identity propagation mechanisms.
Test incident response runbooks for agent-origin incidents. Validate that existing DORA Art. 17 ICT incident management processes can handle an incident where an AI agent acted outside scope but the audit trail cannot attribute the action to a user. If the runbook fails, document the gap.

5. Indicators of compromise

No indicators of compromise available in the source material.

6. Detection

The sources provide usable artefacts for detection rule construction. The CrowdStrike source identifies OAuth token fields (client_id, subject, scope) and the MCP spec's use of OAuth 2.1 as the token issuance mechanism. The Red Canary source identifies Microsoft Entra Agent ID as a platform where autonomous agents can escalate privileges and persist. Detection rules below target the behavioural patterns described.

rule AI_Agent_OAuth_Token_Anomaly
{
    meta:
        author = "Adverse Trace"
        date = "2026-06-25"
        reference = "https://www.crowdstrike.com/en-us/blog/the-identity-problem-hiding-in-ai-agent-deployments/"
        description = "Detects OAuth token artefacts associated with AI agent deployments using MCP spec OAuth 2.1 — flags tokens with client_id patterns consistent with agent workloads for further review"
    strings:
        $client_id_claim = "client_id" ascii
        $scope_claim = "scope" ascii
        $subject_claim = "subject" ascii
        $oauth2_1 = "OAuth 2.1" ascii
        $mcp_ref = "MCP" ascii
        $jwt_header = "eyJ" ascii
    condition:
        $jwt_header at 0 and 3 of ($client_id_claim, $scope_claim, $subject_claim) and any of ($oauth2_1, $mcp_ref)
}

title: Suspicious AI Agent Service Principal Creation in Entra ID
id: 0a1b2c3d-4e5f-6a7b-8c9d-0e1f-2a3b
status: experimental
description: >
    Detects creation of service principals or app registrations that may indicate
    an autonomous AI agent persisting in an Entra ID tenant. Based on Red Canary
    analysis of privilege escalation via Entra Agent ID.
references:

    - https://redcanary.com/blog/threat-detection/entra-id-ai-workflows/
    - https://www.crowdstrike.com/en-us/blog/the-identity-problem-hiding-in-ai-agent-deployments/
author: Adverse Trace
date: 2026/06/25
logsource:
    product: microsoft
    service: entra_id_audit
detection:
    selection:
        operationName:

            - "Add service principal"
            - "Add application"
            - "Update application - Certificates and secrets management"
            - "Add delegated permission grant"
        initiatedBy:

            - "app"
            - "servicePrincipal"
    filter_legitimate_admin:
        initiatedBy: "user"
        result: "success"
    condition: selection and not filter_legitimate_admin
falsepositives:

    - Legitimate automation creating service principals via managed identity
    - Infrastructure-as-code deployments
level: medium

title: AI Agent OAuth Token with Broad Scope and No User Context
id: 1b2c3d4e-5f6a-7b8c-9d0e-1f2a-3b4c
status: experimental
description: >
    Detects OAuth access tokens issued to AI agents (client credentials grant)
    with broad scopes and no user principal context, as described in CrowdStrike
    analysis of the identity problem in AI agent deployments.
references:

    - https://www.crowdstrike.com/en-us/blog/the-identity-problem-hiding-in-ai-agent-deployments/
author: Adverse Trace
date: 2026/06/25
logsource:
    product: microsoft
    service: entra_id_signin
detection:
    selection_agent_token:
        grantType: "client_credentials"
        scope:

            - "*"
            - "https://graph.microsoft.com/.default"
            - "https://graph.microsoft.com/Directory.Read.All"
            - "https://graph.microsoft.com/User.Read.All"
    filter_known_service_accounts:
        appId:

            - "00000000-0000-0000-0000-000000000000"
    condition: selection_agent_token and not filter_known_service_accounts
falsepositives:

    - Legitimate daemon services using client credentials with broad scopes
    - Backup or sync services
level: medium

7. Sources

CrowdStrike — "The Identity Problem Hiding in AI Agent Deployments" — https://www.crowdstrike.com/en-us/blog/the-identity-problem-hiding-in-ai-agent-deployments/ — 2026-06-24
Red Canary — "Investigating suspicious AI workflows in Microsoft Entra Agent ID: Autonomous agents" — https://redcanary.com/blog/threat-detection/entra-id-ai-workflows/ — date not specified in source

8. Adverse Trace position

This is an architectural weakness, not a CVE-bound vulnerability — no CVSS score, CISA-KEV entry, or named threat actor applies. The risk to EMEA financial services is real and growing: every new AI agent deployment that uses OAuth 2.1 tokens per the MCP spec inherits this identity-context gap. The CrowdStrike analysis is single-vourced; the Red Canary source provides partial corroboration of the privilege-escalation risk in Entra ID but does not independently confirm all claims — single-sourced; verify before enforcement. We assess this as a high-impact strategic risk for any client deploying or planning to deploy AI agents with access to sensitive systems. We will monitor for: (1) IETF or OAuth working group proposals for agent-identity claims extending RFC 9068; (2) MCP spec updates addressing multi-principal token context; (3) Microsoft Entra ID feature changes that add agent instance identity to audit logs; and (4) any CVE or KEV entry that binds this pattern to a specific exploitable product. Clients with active AI agent deployments should treat this as a P2 action item — the compensating controls in §4 are achievable without vendor changes.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.