Shadow AI発見編

AI Asset Inventory/AI-SBOM（EA-056）を作っても、組織が把握していない利用は台帳に入らない。Shadow AI discoveryは、正式なAI inventoryへ未管理利用を取り込む入口である。一方、network/CASB/SSE製品が見えるのは観測点を通過した通信と既知catalogに照合できた活動であり、「全AI利用の完全発見」と同義ではない。将来版では discovery coverage と inventory completeness を分離する必要がある。

• Enterprise AI Core: inventory / discovery / sanction state / ownership reconciliation
• Governance: sanctioned / tolerated / unsanctioned classification、例外管理、利用者教育
• Organization overlay: endpoint、browser、SSE/CASB、DNS/proxy、cloud audit、SaaS audit、developer tooling telemetryの可用性
• Provider mapping: Microsoft Entra Global Secure Access / Defender for Cloud Apps、Palo Alto AI Access Security等
• Security / Privacy: prompt/file内容inspection、TLS inspection、employee telemetry、DLP
• Interoperability: discovery resultをEA-056のRuntime Asset Registryへ正規化して統合

企業はShadow AIを単一のnetwork scannerだけで十分に発見できるか。発見結果をどの確度で「AI利用」「未承認利用」「データ露出」と判定し、正式inventoryへ昇格させるべきか。

• [standard/playbook] NIST AI RMF Playbook — GOVERN 1.6, National Institute of Standards and Technology. Canonical: https://airc.nist.gov/airmf-resources/playbook/govern/ . Accessed 2026-09-14. Locator: GOVERN 1.6 “Mechanisms are in place to inventory AI systems”; inventory may include system docs, IR plans, implementation links, actors. Label: VERIFIED_SPEC / SOURCE_REPORT. Relation: support/context.
• [standard/profile] Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, NIST, published 2024-07-26; page updated 2026-04-08. Canonical: https://doi.org/10.6028/NIST.AI.600-1 . Accessed 2026-09-14. Label: VERIFIED_SPEC. Relation: governance context; does not prescribe one Shadow-AI detector.
• [official product doc] Shadow AI discovery in Global Secure Access, Microsoft, last updated 2026-06-11. Canonical: https://learn.microsoft.com/en-us/entra/global-secure-access/concept-shadow-ai-discovery . Accessed 2026-09-14. Locator: How shadow AI discovery works / Shadow AI discovery vs. Generative AI Insights. Product state as-of 2026-09-14. Label: VERIFIED_SPEC / PRODUCT_VOLATILE. Relation: support/limit.
• [official product doc] AI agent discovery in Global Secure Access (preview), Microsoft, last updated 2026-06-16. Canonical: https://learn.microsoft.com/en-us/entra/global-secure-access/concept-ai-agent-discovery . Accessed 2026-09-14. Locator: preview capabilities; managed vs shadow agents; prerequisites. Label: VERIFIED_SPEC / PRODUCT_VOLATILE. Relation: support/availability/limit.
• [official product doc] Discover Risks Posed by GenAI Apps, Palo Alto Networks. Canonical: https://docs.paloaltonetworks.com/ai-access-security/administration/discover-risks-posed-by-genai-apps . Accessed 2026-09-14. Locator: “Where Can I Use This? / What Do I Need?” and AI Access Security Insights filters. Label: VERIFIED_SPEC / PRODUCT_VOLATILE. Relation: support/availability.
• [official product doc] What's Supported with AI Access Security?, Palo Alto Networks. Canonical: https://docs.paloaltonetworks.com/ai-access-security/getting-started/whats-supported-with-ai-access-security . Accessed 2026-09-14. Locator: visibility is for GenAI app traffic AI Access Security has visibility into. Label: VERIFIED_SPEC / PRODUCT_VOLATILE. Relation: limit.
• [official product page] AI Access Security, Palo Alto Networks. Canonical: https://www.paloaltonetworks.com/sase/ai-access-security . Accessed 2026-09-14. Locator: GenAI application dictionary / visibility / policy control. Label: SOURCE_REPORT / PRODUCT_VOLATILE. Relation: implementation context; marketing completeness claims are not accepted as universal coverage proof.

• Inventory is a governance outcome, not merely a network scan. NIST AI RMF Playbook GOVERN 1.6 explicitly treats mechanisms to inventory AI systems as a governance capability. Therefore Shadow AI discovery should feed an organizational inventory rather than remain a standalone dashboard.
• Microsoft’s current Shadow AI discovery is network-based. Global Secure Access analyzes internet/Microsoft 365 traffic, maps detected services against the Defender for Cloud Apps catalog, and exposes users, usage statistics and risk scores. Current examples include chatbots, model-provider APIs, SaaS MCP servers and code generators.
• Microsoft separates app-level discovery from payload-level visibility. Shadow AI discovery identifies applications; Generative AI Insights uses TLS inspection/deep packet inspection to log actual prompt content and MCP operations. Thus “app observed” must not be equated with “prompt content observed.”
• Microsoft’s AI agent discovery is explicitly preview as of 2026-09-14. For local agents, the Global Secure Access client, internet access forwarding policy and TLS inspection are prerequisites; managed/shadow classification uses Entra Agent ID registration. This is useful implementation evidence but not a provider-neutral completeness guarantee.
• Palo Alto AI Access Security likewise depends on enforcement points and licensing. Current docs list NGFW/Prisma Access/Prisma Browser plus Strata Logging Service and AI Access Security/CASB/Prisma Browser licensing. Its dashboard can show discovered GenAI apps, users and data usage and allow sanctioned/tolerated/unsanctioned tagging.
• A defensible provider-neutral discovery architecture is layered: (a) network/SSE/CASB application discovery, (b) endpoint/process/browser/IDE telemetry, (c) cloud/SaaS/API audit logs, (d) developer dependency/configuration discovery including extensions/plugins/MCP, (e) DLP/content inspection where lawful and necessary, then (f) reconciliation against the approved Runtime Asset Registry from EA-056. This architecture is INFERENCE/PROPOSAL built from the observed coverage boundaries, not a claimed standard.
• Discovery records need confidence states. Recommended Core vocabulary: OBSERVED_ACCESS (traffic seen), OBSERVED_PROCESS_OR_AGENT (runtime/process attribution), CONFIRMED_AI_ASSET (identity/configuration confirmed), SANCTION_STATUS_UNKNOWN, SANCTIONED, TOLERATED, UNSANCTIONED. A domain hit alone should not become “confirmed data leakage.”

• Network-based tools see traffic routed through their observation/enforcement path. Devices, personal networks, unmanaged browsers, or workloads outside that path can be absent.
• Catalog-based discovery depends on catalog freshness and classification. New services, custom domains, embedded AI features and self-hosted endpoints can evade or be misclassified by catalog matching.
• Local/offline models that generate no inspected network traffic require endpoint/process/software inventory telemetry; network discovery alone cannot prove their absence.
• Seeing bytes sent/received does not prove sensitive data was disclosed. Content-level DLP/inspection or application audit evidence is a separate claim.
• TLS/payload inspection improves event-level visibility but increases privacy, legal, secret-handling and retention obligations. It must not be enabled merely to maximize discovery coverage without organization policy.
• Vendor phrases such as “complete visibility” are product claims. They are not accepted here as evidence of universal visibility across every endpoint, tenant, local model, extension, personal API key or encrypted path.
• Sanction state can be wrong or stale unless discovery results are reconciled with owners, approved services and EA-056 registry records.

• Microsoft Global Secure Access features require traffic to traverse the relevant Global Secure Access path; AI agent discovery is preview as of 2026-09-14 and has documented endpoint/client/TLS prerequisites.
• Microsoft Defender for Cloud Apps / related Global Secure Access capabilities depend on tenant licensing/configuration and appropriate admin roles.
• Palo Alto AI Access Security requires supported enforcement points plus listed Strata Logging Service and AI Access Security/CASB/Prisma Browser licensing combinations. Public docs prove feature existence, not availability in any specific tenant.

IMPLEMENTABLE NOW with existing SSE/CASB, endpoint and audit telemetry, but no single detector establishes completeness. Minimum deployable pattern: discovery feeds -> normalized observed-asset/event schema -> identity/owner resolution -> sanction reconciliation -> Runtime Asset Registry -> risk triage. Keep source sensor, observation timestamp, confidence, coverage zone and evidence locator on every record.

No provider-neutral benchmark was found that converts a Shadow-AI detector’s observed app count into enterprise-wide recall. Future evaluation should use a seeded test inventory containing: known SaaS AI, browser extension, IDE assistant, model API, SaaS MCP, local agent, local/offline model and embedded SaaS AI. Measure per-sensor precision/recall only against that bounded test set; do not extrapolate to universal enterprise coverage.

• Security: discovery should trigger risk review and sanction workflow, not automatic accusation based only on domain/catalog match.
• Privacy: prompt/MCP/file inspection can collect highly sensitive employee/customer data; minimize collected payload, restrict access, define retention and legal basis.
• Audit: retain sensor/source, matched app identity, user/device/process where available, sanction decision, decision owner, timestamp and policy action.
• Cost: full payload/TLS inspection and endpoint telemetry are materially heavier than app-level network metadata; coverage must be risk-tiered.
• Operability: catalog drift and new AI services require continuous classification updates and a manual unknown-app review path.

「Shadow AIの発見は、未承認AIを一度のスキャンで完全列挙する機能ではない。SSE/CASB、endpoint/process、browser/IDE、cloud/SaaS/API auditなど複数の観測面から“観測された利用”を集め、承認台帳と突合して初めて運用上のShadow AI inventoryになる。アプリへの通信観測、実際のprompt内容観測、機密データ露出の確認は別の証拠レベルとして扱う。」

• EA-056 Runtime Asset Registryへ discovery_source, coverage_zone, confidence_state, first_seen, last_seen, user/device/process, sanction_state, owner, evidence_locator を追加する候補。
• Provider mappingではMicrosoft Global Secure Access/Defender for Cloud AppsとPalo Alto AI Access Securityをcurrent implementation例として再確認する。
• 本文採用時は“complete visibility”等のvendor marketing表現をCore claimに昇格させない。
• 後続TEST_PROFILE: 認証済みtenant操作なしでは実測不可。将来、安全な検証tenantでseeded AI tool setを用意し、network/endpoint/browser/cloud各sensorのbounded recallを測る。今回は未実施。

OPEN: unmanaged mobile/BYOD、browser extension、IDE plugin、local/offline model、custom model endpoint、embedded SaaS AIの各検出面についてprovider-neutralな最低telemetry setを標準化できるか。OPEN: AI catalogの更新遅延を定量評価する共通benchmark。STOP CONDITION: inventoryの必要性、主要な現行実装、coverage limitation、availability gate、将来test profileまで確立したためEA-057初回packetはbounded complete。

---

---

Microsoft AI agent discovery remains Preview and coverage depends on Global Secure Access traffic/prerequisites; Palo Alto AI Access Security visibility remains bounded by supported enforcement points, licensing and app visibility/DLP coverage.