Shadow-AI discovery & AI agent security posture management (AI-SPM)

Employees paste data into free chatbots, install AI browser extensions, connect copilots to mailboxes via OAuth and spin up agents and MCP servers that nobody registered. Shadow-AI discovery finds these assets from identity, network, endpoint and SaaS telemetry; AI-SPM then scores each AI asset and its non-human identity, flags over-privileged agent access and enforces usage policy. Result: a live inventory instead of a survey, and fewer silent data leaks.

Problem & value

• Today: AI adoption outpaces governance. Security teams learn about tools from invoices, user surveys or incidents. Agents run under personal tokens or shared service accounts with broad scopes, and nobody owns them. Classic CASB/SaaS-discovery catalogues lag behind the pace of new AI apps.
• AI value: classification of long-tail domains and apps as "AI", mapping of agents and MCP servers to owners and entitlements, ranking of the few assets that really matter, and natural-language investigation of "which agents can read HR data?".
• Benefit evidence: vendor surveys report widespread unapproved AI use; treat as directional and measure your own baseline [1][5]. No universal ROI figure exists.
• Distinct from neighbours: SEC-010 protects one known LLM app at runtime; SEC-022 is the documentation/compliance workflow of the AI Act; SEC-013 is the telemetry-driven discovery and control layer that feeds both.

Variants

• Shadow-AI (SaaS and browser) discovery: which GenAI sites, plugins and extensions are used, by whom, with what data.
• Agent and non-human-identity posture: inventory of agents, service principals, API keys, OAuth apps and MCP servers; least-privilege and ownership checks.
• Cloud AI-SPM: misconfigurations of managed AI services (Bedrock, Azure OpenAI/Foundry, Vertex AI), exposed model endpoints, public vector stores, over-broad roles.
• Developer / code-level: AI SDK usage, hard-coded keys and unapproved MCP servers found in repos and CI.
• SMB: use existing IdP / Microsoft 365 / Google Workspace controls (app consent, DLP, web filtering) plus a short AI policy.
• Public sector: same pattern with data-residency and sovereign-hosting constraints and a works-council/staff-council agreement.

How it works

1. telemetry (IdP/OAuth, proxy/DNS, endpoint, SaaS, cloud, repos)
2. AI-asset detection (domain/app/model/MCP classifier + signature catalogue)
3. entity resolution (app ↔ owner ↔ non-human identity ↔ data touched)
4. posture and risk scoring (data sensitivity, scopes, autonomy, vendor terms, region)
5. graph of agent
6. tool
7. data permissions (blast radius, toxic combinations)
8. policy engine (sanction / block / coach / require approval / revoke token)
9. ticket + owner attestation + evidence to governance register

• Detection: mostly rules and catalogues of known AI services, supplemented by classifiers (text classifier / small LLM) that label unknown domains, extension manifests and OAuth app descriptions as AI.
• Graph analysis: an identity/permission graph shows which agent can reach which data and tools; attack-path style queries find "agent with mail-send plus file-read plus external web access".
• LLM assistant: summarises findings, drafts owner outreach and answers investigation questions; it must not hold write access to enforcement without approval.
• Human-in-the-loop: security owner approves new sanctioned tools, risk acceptances and any automatic blocking beyond pre-agreed categories; business owners attest agents periodically.

Data preparation

The "data" here is telemetry, not documents: IdP and OAuth grant logs (Entra ID, Okta, Google Workspace), proxy, DNS and firewall logs, endpoint inventories, SaaS and cloud admin consoles, and code repositories. In an SMB these sit in the M365 or Google admin centre, the firewall, and an endpoint tool; they are rarely correlated.

Typical gaps: no central log retention (firewall logs overwritten after days), missing asset-to-owner mapping, unmanaged devices and private phones, shared or service accounts without named owners, and no written AI policy to measure against (see GUIDE-007).

Preparation steps: 1. Switch on and retain sign-in, OAuth consent and proxy/DNS logs (90 days is a workable start). 2. Build a first inventory of sanctioned tools and owners; clean up service accounts and tokens. 3. Define data classes and what may go into which tool (PREP-024), and clear oversharing before agents get access (PREP-023). 4. Record owners per department (PREP-004).

Tools: the logging features of the existing identity platform, a SIEM or log collector (Wazuh, Graylog), spreadsheets for the first register. Rough share of effort: about 30 percent, mostly log access and ownership clean-up; see GUIDE-003 for the readiness check.

Implementation paths

Which path for whom

• SMB: Path A — the discovery features already sit in the identity, endpoint and web-gateway products SMBs use (Entra/Defender, Google Workspace, Okta) and the process is standard, so a self-built catalogue would not pay off.
• Enterprise: Path A — shadow-AI discovery is a commodity security function; mature CASB/SSPM/AI-SPM products cover it, and building and maintaining the AI-app signature catalogue yourself is rarely worth it (Path B/C only for agent-specific graph analysis on top).
• Public sector: Path A — choose an EU-hosted or on-premises product that is already in a procurement framework; the telemetry contains staff data, so it should stay in a sovereign environment.

Path A — Buy (off-the-shelf)

• Identity-centric: Okta (Identity Security Posture Management with AI-agent discovery), Microsoft Entra (Agent ID, app governance) with Microsoft Defender and Purview, Google Workspace admin controls, CyberArk and SailPoint for non-human identities.
• Endpoint/network-centric: CrowdStrike Falcon (shadow-AI discovery), Palo Alto Networks (Prisma AIRS, AI Access Security), Zscaler, Netskope and Cloudflare (AI app visibility and control via gateway/CASB).
• Dedicated AI-SPM / AI security: Wiz AI-SPM, Microsoft Defender for Cloud AI posture, Orca, Prisma Cloud, Cyera and Varonis for data context; start-ups such as Noma Security, Zenity, Lasso Security, Prompt Security (now SentinelOne), Witness AI and Aim Security (now Cato Networks); the vendor landscape consolidates quickly. EU-native specialists are few: check EU hosting, log retention and works-council features.
• Choose A when: you already run an IdP, EDR or SASE stack; extending it is the fastest route.

Path B — Build on cloud APIs

• Data sources: Microsoft Graph (OAuth grants, service principals, sign-in logs), Okta System Log API, Google Workspace Admin SDK, cloud inventory APIs (AWS Config, Azure Resource Graph, GCP Asset Inventory), GitHub code search for SDK/MCP configs.
• Classification and triage: an EU-hosted LLM (Mistral, or Claude/GPT/Gemini in EU regions) with structured outputs to label unknown apps and summarise OAuth scopes; store in a SIEM (Microsoft Sentinel, Splunk, Elastic) and a graph store.
• Choose B when: you need custom joins across your own telemetry or a lightweight SMB version.

Path C — Self-host (open source)

• Telemetry: Zeek/Suricata, OpenSearch/Wazuh, osquery or Fleet for endpoints, Steampipe/CloudQuery for inventory, Neo4j/Memgraph for the permission graph.
• Cloud posture: Prowler and Cartography cover cloud and identity graphs; some AI-service checks exist, coverage varies.
• AI-specific: open scanners for MCP servers and agent configs (e.g. Invariant Labs mcp-scan, Cisco MCP scanner) and OWASP resources for classification of risks; a small local LLM (Llama, Qwen, Mistral small, ≤8B) for labelling.
• Hardware: HW1 (CPU server) is enough; labelling LLM optional on HW2.

Path D — Custom training

Rarely worthwhile. A fine-tuned domain classifier for "is this traffic or app GenAI?" can help very large networks that cannot send telemetry to vendors; the training data is your own labelled proxy and DNS logs.

State of the art (2026)

• Scope moved from chatbots to agents: vendors now inventory agents, MCP servers and their non-human identities, not only GenAI websites. Okta announced agent discovery in ISPM and Microsoft introduced Entra Agent ID for agent identities [2][3].
• Convergence: AI-SPM merges with CSPM/DSPM (cloud), ITDR/ISPM (identity) and SASE/CASB (network); expect AI features inside existing platforms rather than a separate category in the long run.
• Frameworks: OWASP Top 10 for LLM Applications and the OWASP agentic-AI threat work, MITRE ATLAS and NIST AI RMF provide the risk vocabulary and control mapping [4][6].
• Limits: encrypted or local usage (on-device models, personal phones) escapes network telemetry; signature catalogues lag new apps; AI features embedded in approved SaaS are hard to separate from the host app; risk scores are vendor-specific and not comparable; agent behaviour is non-deterministic, so entitlements, not intent, are the reliable control. Blocking without a sanctioned alternative drives usage underground.

Shared resources & combinations

• Same stack (telemetry + graph + small LLM): SEC-005 (identity anomaly detection), SEC-001 (SOC triage), SEC-020 (access reviews and least privilege) reuse the identity logs and graph.
• Runtime protection: SEC-010 guardrails for apps discovered here; SEC-017 data discovery/AI-DLP decides what data may reach which AI asset; SEC-016 scans malicious model and MCP packages.
• Governance: SEC-022 consumes the inventory for AI Act classification; SEC-009 uses it as ISO 27001/NIS2 evidence; AGENT-025 covers fleet observability and evaluation of agents you build.

Effort, cost & KPIs

• Path A: days to weeks to switch on in an existing platform; typically priced per user or per asset, often as an add-on licence.
• Path B: 1–3 months for a connector set, scoring and a dashboard.
• Path C: 2–4 months plus continuous catalogue maintenance.
• KPIs: share of AI assets with a named owner; unsanctioned-to-sanctioned ratio; time to discover a new AI app or agent; agents with excess privilege (count, trend); stale tokens revoked; sensitive-data events towards unsanctioned AI; policy exceptions open beyond expiry.

People & change

Start with management and IT security: they set the AI policy (GUIDE-007) and decide whether discovery leads to blocking or coaching. Involve the data protection officer early, because sign-in, proxy and endpoint logs are personal data; a DPIA is likely if logs are linked to named employees at scale (GUIDE-005).

Works council: yes. The tool logs which AI services individuals use, so it is objectively suited to monitor behaviour and triggers co-determination under §87(1) no. 6 BetrVG; §90(1) no. 3 requires early information, and §80(3) allows an AI expert. Agree a works agreement (GUIDE-004) that limits analysis to the AI-asset level, forbids individual performance evaluation and sets log retention. In public bodies the staff council (Personalrat) has the same role.

Communicate before switching on: why, what is logged, what is not. Position the tool as "coach, then block" and offer approved alternatives, otherwise staff move to private devices. Pick IT and one department as pilot group. Typical concerns are surveillance and loss of useful tools; answer with transparency and a quick approval path for new tools. Support AI literacy (Art. 4 AI Act) with short training on what may be pasted into which tool (GUIDE-006, GUIDE-008). Humans decide on blocks and risk acceptances.

Risks, regulation & compliance

• EU AI Act: the control itself is minimal risk (AI literacy, Art. 4). It supports deployer duties such as inventory and oversight under Art. 26 and Art. 4. Caution (Art. 5): do not use it to infer employee emotions or to build behavioural scores of individuals; employee-monitoring features that profile workers could fall into high-risk (Annex III, employment) or prohibited territory. Keep analysis at asset and identity level [7].
• GDPR: logs link people to the content and timing of AI use, so this is personal data and employee monitoring. Needs a legal basis (Art. 6(1)(f) with balancing test), transparency, data minimisation, DPIA where monitoring is systematic, retention limits and, in Germany, works-council co-determination (§87(1) no. 6 BetrVG). Prefer pseudonymised, aggregated reporting by default.
• NIS2 / DORA / ISO 27001: asset inventory and supply-chain controls are required; AI-asset discovery supplies the evidence [8].
• Risks and mitigations: over-blocking (provide approved tools), false labelling (human review), the discovery tool itself holding broad read access (least privilege, vendor DPA, EU hosting), and vendor lock-in (export inventory in open formats).

Getting started

1. Publish a short AI usage policy and an approved-tool list; name an owner for the AI inventory.
2. Pull OAuth grants and service principals from your IdP and list every AI app and agent with scopes.
3. Enable AI-app visibility in your existing gateway/CASB/EDR in monitor-only mode for 30 days.
4. Rank by data sensitivity and privilege; revoke or right-size the top 10 findings and offer sanctioned alternatives.
5. Agree monitoring scope with the data protection officer and works council, then set quarterly owner attestations.

Sources

1. Okta — Identity Security Posture Management — https://www.okta.com/products/identity-security-posture-management/
2. Microsoft — Microsoft Entra Agent ID overview — https://learn.microsoft.com/entra/agent-id/
3. Microsoft — Defender for Cloud AI security posture management — https://learn.microsoft.com/azure/defender-for-cloud/ai-security-posture
4. OWASP — Top 10 for LLM Applications / GenAI Security Project — https://genai.owasp.org/
5. CrowdStrike — Falcon platform and shadow AI visibility — https://www.crowdstrike.com/
6. NIST — AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
9. MITRE ATLAS — https://atlas.mitre.org/