Back to Intelligence

Shadow AI Agents: Finding and Governing the Third-Party AI Your SSO Can't See (2026 State of Agent Security)

SA
Security Arsenal Team
October 10, 2026
12 min read

The 2026 State of Agent Security Report landed on a number every CISO and SOC lead needs to sit with: in the environments studied, roughly 1,280 third-party products now embed AI capabilities. Only about 282 of them sit behind single sign-on. The other ~1,000 agents are invisible to identity infrastructure by default — not because anyone deliberately hid them, but because an identity stack can only govern what authenticates through it, and most agents never do.

This is not a theoretical governance gap. I've run IR engagements where the initial access vector turned out to be an AI assistant plugin granted broad OAuth scopes by a well-meaning business user, and a supply-chain compromise where a vendor's embedded LLM feature silently began piping customer data to a model endpoint nobody had reviewed. The pattern is consistent: the agent is sanctioned by no one, scoped by no one, and logged by no one — until it becomes the incident.

This post breaks down the defensive reality of third-party agent sprawl, how these agents actually operate in your environment, and gives you concrete detection content — Sigma, KQL, Velociraptor, and a Graph PowerShell inventory script — to start closing the gap this quarter.

Technical Analysis: Why Agents Evade Identity Governance

The structural blind spot

Traditional SSO and IdP governance (Entra ID, Okta, Ping) works because applications opt in to federation — they register, redirect, and authenticate through the identity plane. Third-party AI agents break this model in three distinct ways:

  1. User-granted OAuth consent. An employee connects a SaaS AI feature or assistant to their Microsoft 365 or Google Workspace account. The app receives delegated scopes (often Mail.Read, Files.Read.All, offline_access) and operates with a refresh token. It never authenticates through SSO interactively — it silently exchanges tokens against the token endpoint. If your tenant allows user consent, this happens with zero admin involvement.
  2. Embedded vendor AI (the 'feature' problem). A product you already approved — your CRM, ticketing system, code editor — ships an AI feature that calls an external model API. The data egress happens from the vendor's infrastructure or from the endpoint under an existing approved app context. No new identity object appears; the risk materialized inside a trusted boundary.
  3. Local agentic runtimes. Developers and power users run agent frameworks and MCP (Model Context Protocol) servers locally — npx @modelcontextprotocol/server-*, Python-based agent harnesses, desktop AI clients with tool-use capabilities. These processes hold API keys in plaintext config files, read local files and credentials, and make outbound HTTPS calls to model and tool endpoints. Your IdP sees nothing. Your EDR sees node.exe.

Why this is an exploitation surface, not just a compliance headache

From a threat actor's perspective, ungoverned agents are ideal infrastructure:

  • Over-scoped OAuth grants are a persistence and data-access mechanism that survives password resets and MFA enforcement — refresh tokens and service principal credentials are not covered by interactive authentication policies. Token theft and illicit consent grant techniques (MITRE ATT&CK T1550.001, T1528) map directly here.
  • Local agent runtimes with tool-use capabilities are, functionally, remote-controlled shells with a friendly UI. An attacker who phishes an API key or poisons an MCP server config inherits whatever the agent can reach: file systems, shells, internal APIs, mailboxes.
  • Supply-chain embedded AI inherits the trust of the parent application. If the vendor's model endpoint, plugin registry, or update channel is compromised, the blast radius is every customer tenant where that agent operates.

The exploitation status here is not a single CVE — it's an actively exploited class of exposure. Illicit consent grants have been used in real intrusions, MCP server ecosystems have already seen malicious packages published to public registries, and security teams are finding agent-related data egress in DLP reviews with increasing frequency. Treat this as an active hygiene-and-detection problem now, not a 2027 roadmap item.

Detection & Response

The detections below target the three observable behaviors that matter: new OAuth consents and service principals appearing in the tenant, local agent runtimes executing on endpoints, and outbound connections to AI/model infrastructure. None of these are fire-and-forget — tune the allowlists to your sanctioned tooling.

Sigma Rules

YAML
---
title: OAuth Application Consent Granted to Third-Party Application
id: 3f7a2c91-4d58-4e6b-b1a2-9c8e7d6f5a4b
status: experimental
description: Detects user or admin consent grants to applications in Entra ID. Ungoverned AI assistants and embedded third-party AI features frequently establish access via user consent, bypassing SSO governance entirely.
references:
  - https://thehackernews.com/2026/10/the-third-party-agent-problem-why.html
  - https://attack.mitre.org/techniques/T1528/
  - https://attack.mitre.org/techniques/T1550/001/
author: Security Arsenal
date: 2026/10/20
tags:
  - attack.persistence
  - attack.credential_access
  - attack.t1528
  - attack.t1550.001
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName:
      - 'Consent to application'
      - 'Add OAuth2PermissionGrant'
      - 'Add service principal'
      - 'Add app role assignment to service principal'
  filter_known_critical:
    # Suppress consents to sanctioned, reviewed first-party integrations
    operationName: 'Add service principal'
    resultType: '0'
  condition: selection
falsepositives:
  - Legitimate application onboarding through IT-approved procurement
  - Admin consent for sanctioned enterprise applications
level: medium
---
title: Local AI Agent Runtime or MCP Server Execution
id: 8b1e4d26-7f3a-4c59-9e2d-1a5b6c7d8e9f
status: experimental
description: Detects execution of local AI agent frameworks and Model Context Protocol (MCP) servers via node/npx or Python. These runtimes operate outside identity governance, often hold API keys in plaintext configs, and provide tool-use access to local resources.
references:
  - https://thehackernews.com/2026/10/the-third-party-agent-problem-why.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/20
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith:
      - '\node.exe'
      - '\npx.cmd'
      - '\python.exe'
      - '\pythonw.exe'
      - '\uv.exe'
      - '\uvx.exe'
      - '\bun.exe'
  selection_cli:
    CommandLine|contains:
      - 'modelcontextprotocol'
      - 'mcp-server'
      - 'mcp_server'
      - '@anthropic'
      - 'langchain'
      - 'autogen'
      - 'crewai'
      - 'openai-agents'
      - 'claude_desktop_config'
  filter_dev_paths:
    # Reduce noise from reviewed developer workstations; remove after baseline
    Image|startswith:
      - 'C:\Program Files\ApprovedTooling\'
  condition: selection_img and selection_cli and not 1 of filter_*
falsepositives:
  - Developer workstations with sanctioned AI tooling
  - QA/automation pipelines using agent frameworks
level: medium
---
title: Suspicious OAuth Grant with High-Risk Mail or File Scopes
id: 5c9d3e17-2a84-4b6f-a1d3-7e5f9c2b4a68
status: experimental
description: Detects consent grants requesting broad data access scopes commonly abused for silent data exfiltration by third-party AI assistants. Combination of offline_access with Mail/Files/Sites read scopes enables persistent mailbox and document access without further user interaction.
references:
  - https://thehackernews.com/2026/10/the-third-party-agent-problem-why.html
  - https://attack.mitre.org/techniques/T1528/
author: Security Arsenal
date: 2026/10/20
tags:
  - attack.collection
  - attack.persistence
  - attack.t1528
  - attack.t1114
logsource:
  product: azure
  service: auditlogs
detection:
  selection:
    operationName: 'Consent to application'
    modifiedProperties|contains:
      - 'Mail.Read'
      - 'Mail.ReadWrite'
      - 'Files.Read.All'
      - 'Files.ReadWrite.All'
      - 'Sites.Read.All'
      - 'full_access_as_app'
  selection_persist:
    modifiedProperties|contains:
      - 'offline_access'
  condition: selection and selection_persist
falsepositives:
  - Approved backup, eDiscovery, or CRM synchronization tooling
level: high

KQL — Microsoft Sentinel / Defender

The first query hunts new service principals and OAuth grants surfacing in your tenant — the "agents behind the agent." The second hunts local agent runtime execution on endpoints, including outbound connections to known model API infrastructure. Both assume standard Sentinel ingestion (Entra ID AuditLogs, Defender XDR advanced hunting tables).

KQL — Microsoft Sentinel / Defender
// Hunt 1: New OAuth consent grants and service principals (potential ungoverned AI agents)
let Lookback = 14d;
let HighRiskScopes = dynamic(["Mail.Read","Files.Read.All","Sites.Read.All","offline_access","full_access_as_app","Chat.Read"]);
AuditLogs
| where TimeGenerated > ago(Lookback)
| where OperationName in~ ("Consent to application","Add OAuth2PermissionGrant","Add service principal")
| where Result == "success"
| mv-expand TargetResources
| mv-expand TargetResources.modifiedProperties
| extend PropName = tostring(TargetResources_modifiedProperties.displayName),
         NewValue = tostring(TargetResources_modifiedProperties.newValue)
| where PropName =~ "ServicePrincipalNames" or NewValue has_any (HighRiskScopes)
| extend AppDisplayName = tostring(TargetResources.displayName),
         ConsentingUser = tostring(InitiatedBy.user.userPrincipalName)
| summarize FirstSeen=min(TimeGenerated), Scopes=make_set(NewValue)
  by AppDisplayName, ConsentingUser, OperationName, CorrelationId
| order by FirstSeen desc;

// Hunt 2: Local agent runtime execution and connections to AI model endpoints
let AIEndpoints = dynamic(["api.openai.com","api.anthropic.com","generativelanguage.googleapis.com","api.cohere.com","openrouter.ai","registry.modelcontextprotocol.io"]);
DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where FileName in~ ("node.exe","npx.cmd","python.exe","uv.exe","uvx.exe","bun.exe")
| where ProcessCommandLine has_any ("modelcontextprotocol","mcp-server","mcp_server","langchain","autogen","crewai","claude_desktop_config")
| project TimeGenerated, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine
| join kind=leftouter (
    DeviceNetworkEvents
    | where TimeGenerated > ago(Lookback)
    | where RemoteUrl has_any (AIEndpoints)
    | project DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP, TimeGenerated2=TimeGenerated
) on DeviceName, $left.FileName == $right.InitiatingProcessFileName
| summarize arg_max(TimeGenerated, *) by DeviceName, ProcessCommandLine
| order by TimeGenerated desc

Velociraptor VQL

For DFIR scoping and proactive hunting, this artifact inventories local agent runtime processes and their command lines across the fleet, plus common agent configuration file locations where API keys and MCP server definitions live. Run it as a hunt to establish your baseline of unsanctioned agent tooling.

VQL — Velociraptor
-- Hunt: Third-Party AI Agent Runtime and MCP Configuration Discovery
-- Identifies running agent processes and reads MCP/agent config files
-- that typically contain API keys and server definitions outside IdP governance.

SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)modelcontextprotocol|mcp[-_]server|langchain|autogen|crewai|openai-agents|claude_desktop'
   OR Exe =~ '(?i)(node|npx|python|uvx?|bun)\.exe$'
      AND CommandLine =~ '(?i)mcp|agent'
VQL — Velociraptor
-- Hunt: Agent and MCP configuration files containing API keys / server definitions
SELECT FullPath, Size, Mtime, Btime,
       read_file(filename=FullPath, length=8192) AS ConfigSnippet
FROM glob(globs=[
  'C:/Users/*/AppData/Roaming/Claude/claude_desktop_config.json',
  'C:/Users/*/.cursor/mcp.json',
  'C:/Users/*/.codeium/windsurf/mcp_config.json',
  'C:/Users/*/.config/*/mcp.json',
  'C:/Users/*/.aws/credentials',
  'C:/Users/*/.openai/*',
  '/home/*/.config/Claude/claude_desktop_config.json',
  '/home/*/.cursor/mcp.json',
  '/Users/*/Library/Application Support/Claude/claude_desktop_config.json'
])
WHERE ConfigSnippet =~ '(?i)api[_-]?key|token|mcpServers|command'

Inventory & Hardening Script

You cannot govern what you have not inventoried. This PowerShell script uses Microsoft Graph to enumerate every OAuth permission grant and non-Microsoft service principal in the tenant — your true population of third-party "agents behind the agent" — then flags risky scope combinations for review. Run it as a read-only audit first; the disable action at the bottom is commented out pending your change-control review.

PowerShell
# Requires: Microsoft.Graph PowerShell SDK, Application.Read.All + Directory.Read.All (audit) or Directory.ReadWrite.All (remediate)
# Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"

$ReportPath = ".\ThirdPartyAgentInventory_$(Get-Date -Format 'yyyyMMdd').csv"
$HighRiskScopes = @('Mail.Read','Mail.ReadWrite','Mail.Send','Files.Read.All','Files.ReadWrite.All',
                    'Sites.Read.All','Chat.Read','ChannelMessage.Read.All','full_access_as_app','offline_access')

# 1. Enumerate all delegated OAuth permission grants (user/admin consent)
Write-Host "[*] Enumerating OAuth2 permission grants..." -ForegroundColor Cyan
$grants = Get-MgOauth2PermissionGrant -All
$results = foreach ($g in $grants) {
    $clientSp  = Get-MgServicePrincipal -ServicePrincipalId $g.ClientId -ErrorAction SilentlyContinue
    $resourceSp = Get-MgServicePrincipal -ServicePrincipalId $g.ResourceId -ErrorAction SilentlyContinue
    $scopes = $g.Scope -split ' '
    $risky = $scopes | Where-Object { $_ -in $HighRiskScopes }
    [PSCustomObject]@{
        AppName        = $clientSp.DisplayName
        AppId          = $clientSp.AppId
        PublisherVerified = $clientSp.VerifiedPublisher.IsVerified
        ConsentType    = $g.ConsentType   # 'AllPrincipals' = admin-wide; 'Principal' = single user
        ResourceApi    = $resourceSp.DisplayName
        Scopes         = ($scopes -join ';')
        HighRiskScopes = ($risky -join ';')
        RiskFlag       = if ($risky.Count -gt 0 -and -not $clientSp.VerifiedPublisher.IsVerified) { 'REVIEW' } else { 'OK' }
    }
}

# 2. Enumerate non-Microsoft service principals (third-party apps registered in tenant)
Write-Host "[*] Enumerating third-party service principals..." -ForegroundColor Cyan
$thirdParty = Get-MgServicePrincipal -All -Filter "servicePrincipalType eq 'Application'" |
    Where-Object { $_.AppOwnerOrganizationId -ne 'f8cdef31-a31e-4b4a-93e4-5f571e91255a' } |  # Microsoft tenant ID
    Select-Object DisplayName, AppId, CreatedDateTime, AccountEnabled,
                  @{N='PublisherVerified';E={$_.VerifiedPublisher.IsVerified}}

$results | Export-Csv "$ReportPath" -NoTypeInformation
$thirdParty | Export-Csv "ThirdPartyServicePrincipals_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
$results | Where-Object RiskFlag -eq 'REVIEW' | Format-Table -AutoSize
Write-Host "[*] Inventory complete. Review flagged grants in: $ReportPath" -ForegroundColor Green

# 3. REMEDIATE (change-control required): revoke a confirmed malicious/unauthorized grant
# Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<GrantId>"
# Update-MgServicePrincipal -ServicePrincipalId "<SpId>" -AccountEnabled:$false

Remediation: Closing the Agent Governance Gap

There is no patch for an architectural blind spot. Closing this gap requires a deliberate program across identity, endpoint, and data controls:

1. Lock down consent at the identity plane (this week).

  • In Entra ID, disable end-user consent or restrict it to verified publishers with low-risk scopes (Entra admin center → Enterprise applications → Consent and permissions). Enable the admin consent workflow so every new grant becomes a reviewed ticket — this converts your invisible ~1,000 agents into a governed pipeline.
  • Audit existing grants with the script above. Revoke grants to unverified publishers holding offline_access plus mail/file scopes.

2. Build the agent inventory (this month).

  • Correlate three data sources: OAuth grants (identity), endpoint agent runtimes (EDR/Velociraptor), and network egress to model API domains (proxy/firewall/SWG). No single source sees the whole population — that's the core lesson of the report.
  • Publish a sanctioned AI tooling catalog. Everything not on it is either onboarded through review or removed.

3. Enforce Conditional Access on what you can, and constrain what you can't.

  • Require compliant device and MFA for sanctioned enterprise AI apps. For agents that will never support CA, bound the blast radius: least-privilege scopes, short token lifetimes, and Continuous Access Evaluation where supported.
  • Apply DLP policies to AI application connectors and block upload of regulated data classes (PHI, PCI) to unsanctioned AI endpoints at the secure web gateway.

4. Treat local agent runtimes as managed software.

  • MCP servers and agent frameworks belong in your software allowlist and vulnerability management scope. Rotate any API keys found in plaintext configs discovered during the VQL hunt — assume anything on disk in a user profile has been readable by anything running as that user.

5. Contract and supply-chain controls.

  • Add AI data-flow disclosure requirements to vendor assessments: does the product call external model APIs, where does data go, is it used for training, and how will you be notified when AI features are added post-purchase? The 282-behind-SSO number tells you vendors will not volunteer this.

6. Operationalize the detections.

  • Deploy the Sigma rules and KQL hunts above, tuned to your sanctioned catalog. Alert on new grants and new runtimes rather than the existing baseline — that keeps the signal actionable and the rule alive.

Executive Takeaways

  • The 2026 State of Agent Security data quantifies what many of us suspected: roughly 78% of AI-embedded third-party products operate outside identity governance (~1,000 of 1,280 in studied environments). Assume your ratio is similar until you measure it.
  • This is an identity architecture problem, not a malware problem. The fix is consent governance, inventory correlation, and Conditional Access — not another signature.
  • User-granted OAuth consents are the highest-risk, lowest-visibility vector. Lock down consent and enable the admin approval workflow before anything else.
  • Local agent runtimes and MCP servers are managed software now. Inventory them, allowlist them, and rotate the API keys you find in plaintext configs.
  • Vendor AI features activate post-purchase. Your contracts must require disclosure, or your approved-app list is a snapshot of a moving target.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.