AI asset classwhat you are looking for
On-premisesWorkstations and servers, including OT or industrial segments: managed and unmanaged endpoints, VDI, on-prem VMs, containers, engineering workstations, DMZ
Cloud platformsAzure, AWS, Google Cloud: IaaS, PaaS and managed AI services
SaaS - Internal (in-tenant)AI inside apps you license, for example Microsoft 365 Copilot and in-tenant agents. Your sanctioned AI SaaS usually lives here
SaaS - External / Shadow (egress)Third-party AI reached over the network. Unsanctioned unless your policy approves it
01
Models and model endpoints
Which models run or are called, by whom, and with what data?
Workstations: local runtimes (Ollama, LM Studio, llama.cpp), model weight files on disk, listeners on :11434 / :1234, sustained GPU use. Engineering workstations on OT or industrial segments are a common blind spot. Servers: self-hosted inference (vLLM, Triton, TGI), model registries, GPU nodes, internal model API endpoints, including dev servers calling AI APIs.
Managed model deployments (Azure OpenAI, AWS Bedrock, Vertex AI), including AI services stood up in unsanctioned subscriptions or accounts; model catalogue use; endpoint keys; quota and spend as a discovery signal.
Models embedded in the SaaS you license (the copilot's grounding model, vendor sub-processor models); model version, hosting region, tenant data boundary.
Outbound calls to model APIs (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com); API keys held or funded outside central management.
02
Agents and copilots
What acts on its own, under whose identity, with what permissions?
Workstations: desktop and coding agents (CLI / IDE), browser-driving agents, scheduled agent jobs (cron, Task Scheduler). Servers: agent runtimes and orchestrators (LangGraph, n8n, AutoGen), daemons and containers, service accounts running agent workloads.
Cloud agent services (Azure AI Foundry, Bedrock Agents, Vertex AI Agent Builder); agent non-human and workload identities; roles assumed and actions written to cloud audit logs.
Copilots and agent builders in your suite (for example Microsoft 365 Copilot and Copilot Studio), including maker-built agents and flows published by end users; who published each one, and what knowledge and connectors it holds.
Third-party agent platforms reached over the web; browser agents acting on corporate sessions; OAuth grants letting an external agent act inside your tenant.
03
MCP servers and tool connectors
What can an AI reach into, and who approved that connection?
Workstations: local stdio MCP processes, .mcp.json and client config files, MCP containers, IDE extensions that add connectors. Servers: self-hosted remote MCP endpoints (HTTP / SSE), container images, exposed ports, credentials stored in server-side MCP config.
Hosted MCP services; API gateway routes in front of MCP; secrets issued to MCP clients; consented enterprise applications.
Vendor-supplied MCP connectors inside licensed SaaS; platform connectors (for example Graph or Power Platform) exposed to copilots; scope grants that widen what an agent can read.
Desktop and IDE clients connecting to remote MCP endpoints on the internet; egress to MCP / SSE endpoints; tokens issued to external MCP servers.
04
AI pipelines and data flows
Where does your data go to be embedded, trained on, or retrieved?
Workstations: notebooks, local RAG indexes, local vector stores, bulk data pulled down for embedding. Servers: ETL into vector databases, fine-tune jobs, feature stores. Exports from OT or industrial data stores staged for analytics are often the highest-value data at risk.
ML pipelines (Azure ML, SageMaker, Vertex AI); managed vector stores; training data in object storage; cross-region data movement.
Copilot and vendor RAG indexing your documents, mail and ticket data; semantic index scope; retention and data-residency terms.
Corporate data pasted or uploaded to external AI sites; file uploads to AI services; whether prompts and documents are used for vendor model training.
05
AI tooling, runtimes and supply chain
What AI code and dependencies are installed, and can you trust them?
Workstations: pip / npm AI packages, IDE and browser AI extensions, desktop AI apps installed outside the software catalogue, CUDA and driver stack. Servers: container base images carrying AI libraries, SBOM coverage, CVEs in AI / ML dependencies, hard-coded API keys, models pulled from public hubs.
Managed notebook images; marketplace images; IaC (Terraform, Bicep, CloudFormation) declaring AI services; CI/CD steps calling models.
AI features silently enabled inside licensed SaaS; vendor change notices that turn AI on by default; sub-processor list and contractual AI terms.
Unvetted AI plugins and marketplace installs; model and package pulls from public hubs; extensions and desktop apps that call external AI at runtime.
GOV
Governance and assurance
For whatever runs here: is it approved, is it audited, and can you enforce policy?
Workstations: approved-software catalogue for AI tools, SSO session activity, version and patch state of approved AI clients. Servers: server-side integrations and webhooks to approved AI services, service principals used by automation, key custody.
Subscription or account policy and entitlements; private endpoints; enterprise policy and content-filter configuration.
Approved-app register; copilot and agent audit logs shipped to the SIEM; DLP and sensitivity-label enforcement on AI surfaces; licence and seat inventory.
Unless your policy approves it, nothing here is sanctioned, so can you detect and enforce? Tenant restrictions and SSO enforcement; free-tier signups with corporate email; personal AI accounts on corporate devices.