// 06.1 / Read
AI Agents
as Identities
Every AI tool that connects to your environment authenticates as an identity. It has credentials, permissions, and a trust relationship with your directory. Most of them are less governed than the average intern account.
The Scale Problem
You are adding AI identities faster than you can audit them
AI-related access configurations with excessive permissions increased from 12% to 39% of organisations between 2024 and 2026 per Gammatek research. Microsoft's 2026 Data Security Index found that 32% of data security incidents now involve generative AI tools. Clutch Security research found that in a typical 10,000-person organisation, 15.28% of employees are running an average of 2 MCP servers each, totalling 3,056 deployments with no governance, no credential rotation, and no visibility in the identity infrastructure. The average security team has no inventory of these deployments.
Identity Type
AI Tool OAuth Grants
Every AI tool connected via OAuth is a service principal in your Entra ID tenant with granted permissions. Notion, Grammarly, the AI meeting summariser someone installed, the code review tool the engineering team approved. Each holds a grant that persists until explicitly revoked. The Vercel breach showed exactly what happens when one of these tools is compromised. The tool becomes the entry point.
Identity Type
AI Agent Service Principals
Enterprise AI agents like Microsoft Copilot, GitHub Copilot, and custom-built agents authenticate as service principals. Their permissions are defined by whatever Graph API permissions were granted at deployment. Most enterprise deployments of AI agents have not had their permission scope reviewed since initial setup. An over-permissioned AI agent with Mail.ReadWrite.All and Files.ReadWrite.All is a tenant-wide data exposure risk before an attacker is anywhere near it.
Identity Type
MCP Server Credentials
When a developer spins up an MCP server to connect their AI client to a database, a Salesforce instance, or a GitHub repository, they authenticate with a Personal Access Token or OAuth credential. Clutch Security found that credential lands on their laptop with no rotation schedule, no expiry, and no governance. One stolen laptop is one breach. 13,000 MCP servers launched on GitHub in 2025 alone.
Identity Type
Shadow AI Agents
Employees install AI tools without IT approval, connect them to corporate email and calendar via OAuth, and create service principals that never appear in a formal onboarding process. These shadow agents operate with whatever permissions the user had at the time of consent, often significantly more than the AI tool needs. They are invisible to your CMDB, your access reviews, and your incident response procedures.
AI Identity Type
Typical Permission Scope
Governance Gap
Shadow OAuth App
Mail.Read, Calendars.ReadWrite, Files.ReadWrite granted by the consenting user
Not in any inventory. Survives user offboarding if grant not revoked.
Enterprise AI Agent
Application permissions set at deployment. Often broader than needed.
Permissions rarely reviewed post-deployment. No owner assigned.
Developer MCP Server
PAT or OAuth credential with scope defined by the developer at setup
Credential on laptop. No rotation. No central visibility.
Autonomous AI Agent
Workload identity with task-defined permissions. Often overly broad.
No standing permissions model exists for most deployments.
The question to ask this week: How many OAuth grants in your Entra ID tenant came from AI tools added in the last 12 months? Run a Graph API query against all OAuth2PermissionGrants and filter on application creation date. The number you get back will probably surprise you. Most security teams have never run this query.
Start here
// 06.2 / Read
OAuth and the
AI Trust Problem
OAuth consent grants were already a known risk before AI tools multiplied their scale by an order of magnitude. The Vercel breach is not an isolated case. It is the pattern that plays out every time an AI tool in the corporate trust graph is compromised.
// Real World // Vercel via Context.ai 2025 (revisited with AI lens)
The AI trust graph attack at scale
The Vercel breach was covered in Module 04 from a permission perspective. From an AI identity perspective it demonstrates something different: the attack did not target Vercel. It targeted a third-party AI tool that a Vercel employee had connected to their Google Workspace via an OAuth consent grant. The attacker's path was not through Vercel's security controls. It was through Context.ai's security controls, which Vercel had no visibility into and no ability to enforce standards on. This is the AI trust graph problem: your security posture is now partially determined by the security posture of every AI tool your employees have connected to corporate accounts. You cannot audit what you cannot see.
The Consent Grant Accumulation Problem
Token sprawl created when many employees click Allow over time
Oasis Security documented in March 2026 that in large organisations, token sprawl occurs when many employees independently connect the same AI tool via OAuth, each creating a separate refresh token tied to their own account with their own permission scope. Each token persists independently. When an employee leaves and their account is offboarded, the OAuth grants tied to their account may or may not be revoked depending on the offboarding process. Oasis's recommendation is to ensure that no human users act as integration identities and to collapse distributed refresh tokens into a single, controlled grant under a service account with explicitly scoped permissions.
Attack Vector 01
Compromised AI Vendor Supply Chain
An AI tool in your corporate trust graph is compromised at the vendor level. Every organisation that connected the tool via OAuth is now affected through the same initial access. The attacker does not need to target each organisation individually. They target one AI vendor and receive access to all connected tenants. OWASP ranks this as one of the highest-impact AI supply chain risks for 2025 and 2026.
Attack Vector 02
AI-Assisted Consent Phishing
Attackers create malicious OAuth applications designed to look like legitimate AI productivity tools. They distribute them via phishing emails with "try this new AI tool" framing. When users click through and consent, the attacker receives OAuth tokens for the user's corporate account with whatever permissions the consent screen listed. AI tools have normalised the experience of consenting to broad permissions because users expect AI tools to need access to email and calendar.
Attack Vector 03
Stale Grant Persistence
Gainsight via Salesforce, March 2026
OAuth tokens from AI tools persist for the lifetime of the credential, often up to two years. When the AI tool is no longer actively used but the grant was never revoked, the token remains valid. An attacker who compromises the AI vendor's infrastructure months after a corporate customer stopped using the tool still has access to that customer's data via the stale grant.
Attack Vector 04
Prompt Injection via AI Tool Data Access
An AI tool with Mail.Read or Files.Read processes documents and emails from the corporate environment. An attacker who controls content that the AI tool will process can embed instructions in that content. The AI tool reads the malicious document or email and follows the embedded instructions, such as forwarding sensitive content to an attacker-controlled address. This is indirect prompt injection and it requires no credential compromise.
The Gainsight and Salesforce OAuth incident (March 2026): Oasis Security documented an incident where OAuth tokens from a Gainsight integration persisted in Salesforce environments after the integration was no longer actively used. The incident demonstrated that third-party OAuth access is part of the identity perimeter. Attackers are increasingly targeting connected applications rather than hardened SaaS platforms directly. The recommendation: continuous inventory, least privilege, short-lived tokens where possible, and fast revocation capability built before an incident requires it.
// 06.3 / Read
EvilTokens and
Device Code
Module 02 introduced EvilTokens as the first PhaaS kit built specifically for device code phishing. This section covers the mechanics in depth and explains why it is particularly effective against AI workflows.
Background / Module 02 Summary
What device code phishing is
Device code phishing exploits the OAuth 2.0 device authorization grant flow. This flow exists for devices that cannot display a browser, such as smart TVs and printers. It works by having the device display a code and a URL. The user visits the URL on another device, enters the code, and authenticates. The device then receives tokens without the user directly interacting with it. An attacker initiates this flow on behalf of a target, sends them the code and URL via email or chat, and when the target authenticates, the attacker receives access and refresh tokens for the target's account. MFA is satisfied by the legitimate user as part of the flow.
EvilTokens // February 2026
The first PhaaS kit built specifically for AI workflow exploitation
EvilTokens launched in February 2026 as the first Phishing-as-a-Service kit designed explicitly around device code phishing targeting AI workflows. Unlike earlier device code phishing tools that required manual setup, EvilTokens provides a fully managed infrastructure: phishing templates, token harvesting, and a management interface for operating compromised sessions at scale. What makes it specifically targeted at AI workflows is the client ID it uses. Storm-2372, the threat actor behind early device code campaigns, exploited a Microsoft-owned client ID for a core productivity application that could not be blocked without breaking the legitimate application. EvilTokens extended this approach to AI-specific client IDs, targeting the OAuth flows used by Microsoft Copilot and other AI productivity tools. Users who believe they are authenticating a new AI tool are actually handing over tokens with broad corporate access.
Why AI Workflows Are Targeted
AI Normalises the Authentication Friction
Every time a user sets up a new AI tool they expect an authentication step. They expect to visit a URL, enter a code, or click a consent prompt. This normalised experience is exactly what device code phishing exploits. A user who receives a message saying "to set up your new AI assistant, visit this URL and enter this code" is following a pattern they have done many times legitimately. The social engineering friction is near zero.
The Client ID Problem
Blocking the Flow Breaks Legitimate Tools
Storm-2372 used a Microsoft-owned client ID for an application that has legitimate enterprise use. Blocking that client ID in Conditional Access breaks the legitimate application for all users. This is the reason device code phishing persists despite being a known technique. The defensive options are constrained by the collateral impact of blocking the affected client IDs. EvilTokens exploited this constraint by targeting AI-specific client IDs that are increasingly difficult to block without breaking enterprise AI tool functionality.
What the Attacker Receives
Tokens With Full MFA Satisfaction
The device code flow has the legitimate user complete MFA as part of the process. The attacker receives tokens that have MFA already satisfied. These tokens can be used to access all resources the user has access to, including MFA-protected resources, without the attacker needing the user's phone or any MFA device. The received refresh token can be used to mint new access tokens continuously until it expires or is explicitly revoked.
Detection
What It Looks Like in SigninLogs
Device code phishing sign-ins appear in SigninLogs with ClientAppUsed showing Device Code Flow or the specific application name. The sign-in IP will be the attacker's IP, not the user's. The CorrelationId links the user's authentication to the attacker's token receipt. Alert on successful authentications via the device code flow from unexpected IPs, particularly where the authenticating IP differs from the IP that initiated the device code request.
Defensive options against device code phishing: Conditional Access can block the device code authentication flow entirely for users who do not need it. This is the most effective control. The Conditional Access policy condition is Authentication flows with Device code flow selected. Deploy this policy for all users in cloud-only environments or for privileged users in hybrid environments. For environments where device code is legitimately needed for specific hardware, scope the block to user populations and exempt the specific device groups that require it.
// 06.4 / Read
MCP Servers
and Identity
Model Context Protocol is the standard that connects AI agents to tools and data sources. It was donated to the Linux Foundation in December 2025. It has 13,000 servers on GitHub. And 43% of publicly available MCP servers were found vulnerable in a February 2026 audit.
What MCP Is
The plumbing that connects AI agents to enterprise resources
Model Context Protocol standardises how AI agents connect to external tools and data sources. A developer builds an MCP server that exposes their Salesforce data, their GitHub repositories, or their database as tools an AI agent can call. The AI client connects to the MCP server, authenticates, and can then invoke those tools as part of an agent workflow. MCP added OAuth 2.1 support in January 2026, mandating PKCE and prohibiting implicit and password grants. The June 2025 MCP specification classified MCP servers as OAuth Resource Servers and mandated RFC 8707 resource indicators to prevent token mis-redemption attacks. As of 2026, 86% of enterprise MCP servers have implemented these indicators per Clutch Security research.
MCP Security Risk 01
No Per-Tool Authentication
Once an agent authenticates to an MCP server, it gains implicit access to every tool that server exposes. There is no per-tool credential check. A developer who connects an MCP server exposing both low-sensitivity analytics data and high-sensitivity financial records gives any agent that authenticates to that server access to both, with no distinction. The April 2026 AI Identity paper identified this as a fundamental authorization failure in the MCP specification.
MCP Security Risk 02
Confused Deputy Risk
Because all tools on an MCP server share the server's execution context, a tool invoked with low-sensitivity input can be induced to perform high-sensitivity actions using the server's ambient privileges. An attacker who can control the input to one tool can potentially invoke actions that require permissions the tool itself should not have, by exploiting the shared execution context of the server.
MCP Security Risk 03
Supply Chain Compromise
A February 2026 audit found 43% of publicly available MCP servers are vulnerable. A Postmark MCP server supply chain attack was documented where a single line of malicious code caused compromised servers to blind-copy every outgoing email to the attackers. CVE-2025-6514, a critical OS command injection in mcp-remote, affected 437,000 environments and could steal API keys, cloud credentials, SSH keys, and Git repository contents.
MCP Security Risk 04
Fragmented Audit Trail
MCP tool invocations scatter across tool-specific logs with no unified trail linking a user request to the downstream calls it produced. If an AI agent using an MCP server performs a high-sensitivity action, the audit trail required to understand what happened, who initiated it, and what data was accessed is fragmented across the AI client logs, the MCP server logs, and the downstream API logs. IR for an MCP-involved incident requires correlating all three.
// Real World // OpenClaw February 2026
The first major AI agent security crisis
OpenClaw was the fastest-growing open-source AI agent project in GitHub history with 188,000 stars and a marketplace of 5,700 community-built skills. In February 2026, malicious actors uploaded skills to the marketplace that appeared to perform legitimate automation tasks but secretly exfiltrated sensitive data from users' local machines. Over 21,000 exposed instances were identified. The skills had access to the agent's full execution context including credentials and local files. The attack demonstrated that the AI agent supply chain has the same vulnerability as the npm supply chain, but with an AI agent as the unwitting delivery mechanism. The agent that was supposed to help was helping itself to user files.
The privilege concentration problem: Every tool on an MCP server sits behind a single authentication point. Compromising that authentication point yields the union of every tool's permissions simultaneously. Strata Identity's research recommends ephemeral task-scoped tokens that collapse the reachable state space. Instead of granting an agent standing access to all possible resources, tokens are minted when the agent attempts to access a specific protected resource, scoped to that specific task and those specific tools. Even if the token is compromised, it grants access only to what was needed for that particular operation.
// 06.5 / Read
Governing
AI Identities
The governance framework for AI identities is the same framework that governs service principals and OAuth grants. It just needs to be applied to a category of identity that most organisations have not yet formally recognised as requiring governance.
The Inventory Problem
You cannot govern what you cannot see
The first governance action is inventory. Query your Entra ID tenant for all service principals created in the last 12 months. Filter for those with no documented owner, no ITSM record, or creation dates that correlate with AI tool adoption timelines in your organisation. Cross-reference against your approved AI tool list. Every service principal not on that list is either shadow IT or requires documentation. Run the same query against all OAuth2PermissionGrants filtered by application creation date. This gives you the scope of what you are actually governing.
Control 01
Restrict OAuth Consent
Configure Entra ID to allow users to consent only to apps from verified publishers, or to require admin consent for all applications. This eliminates shadow OAuth apps from individual user consent while preserving the ability for approved AI tools to be onboarded via a formal process. The setting is in Enterprise Applications under Consent and permissions. Turning it to Admin only stops all new shadow grants immediately.
Control 02
Block Device Code Flow
Deploy a Conditional Access policy blocking the device code authentication flow for users who do not require it for legitimate device management. This directly addresses the EvilTokens and Storm-2372 attack surface. The policy condition is Authentication flows with Device code flow. For most cloud-only organisations, this flow is not required and can be blocked tenant-wide without impacting legitimate workflows.
Control 03
Least Privilege for AI Agent Permissions
AI agents should be granted only the minimum Graph API permissions required for their specific function. Mail.Read instead of Mail.ReadWrite if the agent only reads email. Files.Read instead of Files.ReadWrite.All if the agent only needs to access specific documents. Review all existing AI agent service principals against what they actually need. Overly broad permissions granted at deployment rarely get reviewed after the fact.
Control 04
MCP Governance Baseline
Require all MCP server deployments to go through a formal review process before connecting to corporate systems. Use only MCP servers registered in your corporate identity provider with service account identities rather than personal access tokens. Tie MCP access to SSO so that deprovisioning a user revokes all downstream AI access automatically. Clutch Security confirms this eliminates the credential-on-laptop problem at scale.
Governance Action
What It Addresses
How to Implement
AI Identity Inventory
Unknown service principals and OAuth grants from AI tools
Graph API query on SP creation date and OAuth2PermissionGrants
Consent Policy
Shadow OAuth apps from individual user consent
Entra ID Enterprise Apps consent settings set to Admin only
Device Code Block
EvilTokens, Storm-2372, device code phishing attacks
CA policy blocking Authentication flows / Device code flow
Access Reviews
Stale AI tool grants and unused AI agent permissions
Entra ID Access Reviews on all SP app role assignments quarterly
Offboarding Process
Stale grants persisting after user departure
Include OAuth grant revocation in offboarding checklist explicitly
MCP Review Process
Shadow MCP servers with uncontrolled credentials
Formal approval required before MCP connects to corporate systems
The offboarding gap specific to AI tools: Standard offboarding processes check whether a user's Entra account is disabled, their email access is removed, and their physical access is terminated. Very few offboarding checklists include explicit steps to revoke OAuth grants made by the departing user. A former employee's AI tool grant persists after account disable unless the offboarding process includes an explicit step to enumerate and revoke OAuth2PermissionGrants for the departing user's service principals. Add this to your offboarding runbook now, before the next departure.
// 06.6 / Reinforce
Flashcards
Click to flip. Review Again flips back. Got It advances.
Card 1 of 10
// Tap to reveal answer
// Answer
Click card to flip
// 06.7 / Reinforce
Spot the
Risk
Three AI identity configurations. Identify the highest-risk element and the correct remediation.
AI Identity Audit // Tenant: NordicCorp // Service PrincipalsScenario 01
Application Name
AIWritingAssistant-UserGrant
Permissions Granted
Mail.ReadWrite, Files.ReadWrite.All, Calendars.ReadWrite
Grant Type
Delegated (user consented individually)
Unique Consenting Users
47
Owner / ITSM Record
None
What is the highest-risk element and what is the correct first remediation action?
The combination is the risk. 47 individual delegated grants means 47 separate refresh tokens each with Mail.ReadWrite and Files.ReadWrite.All, each persisting independently, each surviving offboarding unless explicitly revoked. An unowned AI tool with no ITSM record and no admin approval is a shadow application. The correct action is to revoke all 47 grants via the Graph API, restrict consent to admin-only to prevent re-occurrence, and formally evaluate whether the tool should be onboarded through the approved process with scoped read-only permissions.
Device Code Authentication // NordicCorp // SigninLogsScenario 02
UserPrincipalName
mikael.berg@nordiccorp.se
ClientAppUsed
Device Code Flow
ResultType
0 (Success)
IPAddress (Code Initiation)
195.67.x.x (Stockholm)
IPAddress (Token Receipt)
45.155.205.x (Netherlands, Tor-adjacent)
The token receipt IP differs from the code initiation IP. What does this tell you and what is the correct immediate action?
In device code phishing, the attacker initiates the code on their own device at their own IP, sends the code to the victim, the victim authenticates from their IP satisfying MFA, and the tokens are delivered back to the attacker's original device at the attacker's IP. The IP mismatch between code initiation and token receipt is the signature of this attack. This is not a VPN. Revoke Mikael's sessions immediately, block the device code flow in Conditional Access if not already done, and treat this as an active identity compromise.
MCP Server Deployment // NordicCorp Dev TeamScenario 03
MCP Server
GitHub MCP (community build)
Authentication Method
Personal Access Token (all repo access)
Token Storage
Plaintext in .env file on developer laptop
Review Status
Not reviewed. Installed from GitHub by developer.
Rotation Schedule
None. No expiry set.
Three distinct risks are present. Identify them and the priority remediation order.
All three risks are real but the priority order is: first, the plaintext credential in a .env file on a laptop is one stolen device away from full GitHub access. Move to a secrets manager immediately. Second, the all-repository PAT scope means a credential compromise gives access to every repository in the organisation. Scope to minimum required repositories. Third, the community build has not been reviewed for supply chain integrity. 43% of publicly available MCP servers were found vulnerable in February 2026. Replace with an audited build or conduct a review before continued use. The no-rotation issue is downstream of fixing the credential storage first.
// 06.8 / Test
Module
Quiz
20 questions. Pass at 15. AI identity types, OAuth trust risks, EvilTokens mechanics, MCP vulnerabilities, and governance controls.
out of 20
// 06.9 / Timed Assessment
Timed
Assessment
10 questions. 10 minutes. AI identity risks, attack mechanics, and governance decisions. Pass at 8.
// Assessment Parameters
Questions
10
Time Limit
10 minutes
Pass
8 / 10
10:00
Remaining