# AI Visibility Map: Northbridge Corp (fictional example)

> **Fictional example. Northbridge Corp is invented for teaching.**

What AI is running in your environment, and which tool can actually see it.

| Field | Value |
|---|---|
| Prepared by |  |
| Date |  |
| Version | v0.3 |

**Scope:** Approved AI SaaS: Microsoft 365 Copilot, 200-seat pilot, the only sanctioned AI service. All other AI services, including AI features inside already-licensed products, are unsanctioned by policy. Estate: about 2,400 endpoints, 180 servers, a small Azure footprint, a recently acquired subsidiary on its own network, a customer-facing portal and a Microsoft 365 tenant.

## How to use

Each cell asks one question: which tool tells you this AI asset exists here, and what it is doing? Name the tool, then set coverage. Empty or None cells are your blind spots. Coverage means you can discover the asset, see what it does, and keep the evidence. A tool that only blocks, with no inventory or logging, is Partial.

Sanctioned versus shadow is the column axis: SaaS - Internal is the AI you license and approved, SaaS - External / Shadow is everything reached over the network. The governance band at the foot asks whether any of it is approved, audited and enforceable.

- Every cell scored Full, Partial or None must name the tool that provides it. A score with no tool is not coverage.
- Start the tool name with "?" when the tool is deployed and could cover the cell but nobody has confirmed it. Leave those cells Unknown until someone checks.

## Coverage at a glance

| AI asset class | On-premises | Cloud platforms | SaaS - Internal | SaaS - External / Shadow |
|---|---|---|---|---|
| 01 Models and model endpoints | Partial | Partial | Unknown | Partial |
| 02 Agents and copilots | Partial | Partial | Partial | Unknown |
| 03 MCP servers and tool connectors | Unknown | Partial | Partial | Unknown |
| 04 AI pipelines and data flows | Unknown | Partial | Partial | Partial |
| 05 AI tooling, runtimes and supply chain | Partial | Partial | Unknown | Partial |
| GOV Governance and assurance | Partial | Partial | Partial | Unknown |

## The map

### 01 Models and model endpoints

_Which models run or are called, by whom, and with what data?_

| Environment | What to look for | Visibility tool(s) | Coverage |
|---|---|---|---|
| On-premises | 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. | Defender for Endpoint + Defender for Servers: local runtimes and self-hosted inference via software inventory and advanced hunting. Endpoints in the acquired subsidiary are NOT onboarded. | Partial |
| Cloud platforms | 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. | Microsoft Defender for Cloud + Azure Policy: Azure OpenAI deployments and model endpoints in the control plane | Partial |
| SaaS - Internal | Models embedded in the SaaS you license (the copilot's grounding model, vendor sub-processor models); model version, hosting region, tenant data boundary. | Microsoft contract, DPA and sub-processor list: documentation, not telemetry. No tool reports model version, hosting region or tenant data boundary. | Unknown |
| SaaS - External / Shadow | Outbound calls to model APIs (api.openai.com, api.anthropic.com, generativelanguage.googleapis.com); API keys held or funded outside central management. | Palo Alto NGFW + URL Filtering: egress to known model API domains, by category | Partial |

### 02 Agents and copilots

_What acts on its own, under whose identity, with what permissions?_

| Environment | What to look for | Visibility tool(s) | Coverage |
|---|---|---|---|
| On-premises | 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. | Defender for Endpoint + Defender for Servers: agent processes and binaries; no view of agent identity, permissions or what the agent connects to | Partial |
| Cloud platforms | 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. | Microsoft Defender for Cloud + Entra workload identities: Foundry agent services and the roles they assume | Partial |
| SaaS - Internal | 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. | Microsoft 365 admin centre + Power Platform admin: Copilot and Copilot Studio agents, including maker-built | Partial |
| SaaS - External / Shadow | Third-party agent platforms reached over the web; browser agents acting on corporate sessions; OAuth grants letting an external agent act inside your tenant. |  | Unknown |

### 03 MCP servers and tool connectors

_What can an AI reach into, and who approved that connection?_

| Environment | What to look for | Visibility tool(s) | Coverage |
|---|---|---|---|
| On-premises | 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. | ?Defender advanced hunting: no MCP-aware detection exists out of the box; this would need custom KQL that nobody has written yet | Unknown |
| Cloud platforms | Hosted MCP services; API gateway routes in front of MCP; secrets issued to MCP clients; consented enterprise applications. | Microsoft Defender for Cloud: hosted services and exposed ports only; no MCP-level detail | Partial |
| SaaS - Internal | 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. | Power Platform connector inventory: connectors exposed to Copilot and their scope grants | Partial |
| SaaS - External / Shadow | Desktop and IDE clients connecting to remote MCP endpoints on the internet; egress to MCP / SSE endpoints; tokens issued to external MCP servers. | ?Palo Alto NGFW: egress to remote MCP / SSE endpoints is not a URL-filtering category; traffic is allowed and uncategorised | Unknown |

### 04 AI pipelines and data flows

_Where does your data go to be embedded, trained on, or retrieved?_

| Environment | What to look for | Visibility tool(s) | Coverage |
|---|---|---|---|
| On-premises | 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. |  | Unknown |
| Cloud platforms | ML pipelines (Azure ML, SageMaker, Vertex AI); managed vector stores; training data in object storage; cross-region data movement. | Microsoft Defender for Cloud: Azure ML pipelines, managed vector stores and training data exposure | Partial |
| SaaS - Internal | Copilot and vendor RAG indexing your documents, mail and ticket data; semantic index scope; retention and data-residency terms. | Microsoft Purview: what Copilot is grounded on; DLP and sensitivity labels on SharePoint and OneDrive | Partial |
| SaaS - External / Shadow | Corporate data pasted or uploaded to external AI sites; file uploads to AI services; whether prompts and documents are used for vendor model training. | Palo Alto NGFW + URL Filtering: destination and upload volume only. No content inspection, so nobody can say WHAT data left. | Partial |

### 05 AI tooling, runtimes and supply chain

_What AI code and dependencies are installed, and can you trust them?_

| Environment | What to look for | Visibility tool(s) | Coverage |
|---|---|---|---|
| On-premises | 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. | Defender for Endpoint + TVM / Defender for Servers + TVM: AI packages, IDE and browser extensions, CVEs in AI libraries | Partial |
| Cloud platforms | Managed notebook images; marketplace images; IaC (Terraform, Bicep, CloudFormation) declaring AI services; CI/CD steps calling models. | Microsoft Defender for Cloud: container image and IaC scanning | Partial |
| SaaS - Internal | AI features silently enabled inside licensed SaaS; vendor change notices that turn AI on by default; sub-processor list and contractual AI terms. |  | Unknown |
| SaaS - External / Shadow | Unvetted AI plugins and marketplace installs; model and package pulls from public hubs; extensions and desktop apps that call external AI at runtime. | Palo Alto NGFW + URL Filtering: egress generated by extensions and marketplace installs at runtime | Partial |

### GOV Governance and assurance

_For whatever runs here: is it approved, is it audited, and can you enforce policy?_

| Environment | What to look for | Visibility tool(s) | Coverage |
|---|---|---|---|
| On-premises | 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. | Intune approved-software catalogue: AI clients on managed devices only; unmanaged and BYOD are out of scope | Partial |
| Cloud platforms | Subscription or account policy and entitlements; private endpoints; enterprise policy and content-filter configuration. | Azure Policy + Entra app registrations: subscription guardrails and consented enterprise applications | Partial |
| SaaS - Internal | Approved-app register; copilot and agent audit logs shipped to the SIEM; DLP and sensitivity-label enforcement on AI surfaces; licence and seat inventory. | Microsoft 365 admin centre + Purview audit, shipped to Microsoft Sentinel: approved-app register and Copilot interaction audit | Partial |
| SaaS - External / Shadow | 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. |  | Unknown |

## Tool register

One row per tool that gives you AI visibility today. If a tool's logs do not reach the SIEM, its coverage is Partial no matter how good the tool is.

| Tool / product | Vendor | Type of signal | Environment | Map rows covered | Depth | Logs to SIEM | Known blind spot / gap | Owner |
|---|---|---|---|---|---|---|---|---|
| Defender for Endpoint | Microsoft | Endpoint agent | On-premises | 01, 02, 03, 05, GOV | Detect | Yes | Sees processes and binaries, not agent identity, permissions or what the agent connects to. No unmanaged or BYOD devices. Reports no GPU telemetry; per-user installs can evade software inventory. |  |
| Defender for Servers | Microsoft | Endpoint agent | On-premises | 01, 02, 03, 05 | Detect | Yes | Same limits as endpoint. Container and GPU host coverage is unconfirmed. Does not extend to the acquired subsidiary. |  |
| Microsoft Defender for Cloud | Microsoft | Cloud posture - CSPM / CNAPP | Cloud platforms | 01, 02, 03, 04, 05, GOV | Discover | Yes | Control-plane and posture visibility. Cloud only: no on-prem, and it does not cover Microsoft 365 Copilot or Power Platform. Runtime process visibility on IaaS VMs depends on Defender for Servers being onboarded. |  |
| Palo Alto NGFW + URL Filtering | Palo Alto Networks | Network - firewall / URL filtering | SaaS - External / Shadow | 01, 03, 04, 05 | Detect | Yes | Destination and volume only: no content inspection, so it cannot say what data left. No user attribution without correlation to identity logs. MCP / SSE endpoints are not a filtering category. Off-network and BYOD traffic never passes through it. |  |
| Microsoft Purview | Microsoft | SaaS admin and audit API | SaaS - Internal | 04, GOV | Discover | Yes | Confirm DLP and sensitivity-label enforcement actually applies on Copilot surfaces, not just in SharePoint. |  |
| Microsoft 365 + Power Platform admin centres | Microsoft | SaaS admin and audit API | SaaS - Internal | 02, 03, GOV | Discover | Yes | Inventories agents and connectors but does not judge whether a maker-built agent is safe. No alerting on newly published agents. |  |
| Microsoft Sentinel | Microsoft | SIEM / log analytics | Multiple | GOV | Detect | Yes | Receives Copilot audit and Defender telemetry. No AI-specific analytics rules or workbooks are deployed: the data arrives and nothing looks at it. |  |
| Subsidiary firewall |  | Network - firewall / URL filtering | On-premises |  |  | No | Run by the acquired subsidiary's own IT. Its logs never reach Sentinel and nobody at Northbridge has checked whether it blocks or even sees AI traffic. |  |
| NO CASB DEPLOYED |  | Other | SaaS - External / Shadow | 02, GOV |  |  | Listed on purpose. Northbridge has egress detection via the firewall but no CASB, so there is no app-level governance, no OAuth grant review, and no way to enforce against unsanctioned AI use. |  |
|  |  |  |  |  |  |  |  |  |
|  |  |  |  |  |  |  |  |  |

## Blind spots to close

Every None and every empty cell on the map becomes a gap with an owner and a target date.

| # | Gap / blind spot | AI asset class | Environment | Proposed tool or approach | Owner | Target date | Status |
|---|---|---|---|---|---|---|---|
| 1 | Shadow AI can be seen but not stopped. The firewall reports egress to AI domains, but with no CASB there is no approval workflow, no OAuth grant review and no enforcement. Detection without enforcement is not a control. | GOV Governance and assurance | SaaS - External / Shadow | Decide the enforcement path: CASB, tenant restrictions, or firewall blocking with an exception process. Pick one and fund it. |  |  | Not started |
| 2 | The recently acquired subsidiary has no AI visibility of any kind. Its endpoints are not onboarded to Defender and its firewall logs never reach Sentinel. | 01 Models and model endpoints | On-premises | Set a date to onboard the subsidiary's endpoints to Defender and ship its firewall logs to Sentinel; until then, treat AI use there as unknown |  |  | Not started |
| 3 | No tool offers a native MCP asset inventory. MCP visibility would rest entirely on custom hunting queries that have not been written. | 03 MCP servers and tool connectors | Multiple | Write and schedule the hunting queries; alert on new MCP clients and servers |  |  | Not started |
| 4 | No named tool covers third-party agent platforms or OAuth grants to them. An external agent could be granted rights inside the tenant and nothing would report it. | 02 Agents and copilots | SaaS - External / Shadow | Run an Entra enterprise-application and OAuth consent-grant review for AI apps; make it recurring |  |  | Not started |
| 5 | AI pipelines and data flows on-prem are unmapped. No tool is named for notebooks, local vector stores, or bulk data exports staged for embedding. | 04 AI pipelines and data flows | On-premises | Identify on-prem vector stores, notebooks and GPU workloads; treat bulk exports of customer data as the highest-value data at risk |  |  | Not started |
| 6 | Nothing detects a vendor enabling an AI feature by default inside software Northbridge already licenses. | 05 AI tooling, runtimes and supply chain | SaaS - Internal | Assign an owner for vendor change notices and sub-processor updates; route them into the approved-app register |  |  | Not started |
| 7 | Copilot audit reaches Sentinel but no AI-specific analytics rule or workbook exists. The telemetry lands and nothing reads it. | GOV Governance and assurance | SaaS - Internal | Build the first three AI analytics rules: new agent published, unusual Copilot data access, first-seen AI egress domain |  |  | Not started |
| 8 | Local model runtime detection is unvalidated. Defender reports no GPU telemetry and per-user installs can evade software inventory. | 01 Models and model endpoints | On-premises | Validate the detection against a known test install of Ollama and LM Studio |  |  | Not started |
| 9 | Model version, hosting region and tenant data boundary for Copilot are contract questions, not telemetry. No tool answers them. | 01 Models and model endpoints | SaaS - Internal | Review the Microsoft contract, DPA and sub-processor list; record the answer in this map |  |  | Not started |
| 10 |  |  |  |  |  |  |  |
| 11 |  |  |  |  |  |  |  |

## Decisions requested

| # | Decision | Owner | By when |
|---|---|---|---|
| 1 | Northbridge can detect shadow AI and cannot stop it. Decide the enforcement path (CASB, tenant restrictions, or firewall blocking with an exception process) before the Copilot pilot grows beyond 200 seats |  |  |
| 2 | Set the date to onboard the acquired subsidiary to Defender and Sentinel, and decide what AI use is allowed there until it is |  |  |
| 3 | Assign an owner for AI visibility. Every gap in this map is unowned today, which is why they are all still open |  |  |
| 4 | Confirm Purview DLP and sensitivity-label enforcement actually applies on Copilot surfaces before more AI SaaS is approved |  |  |
| 5 | Build the first three AI analytics rules in Sentinel. The audit data is already arriving and nothing reads it |  |  |
| 6 | Set the date for a re-scored coverage map |  |  |

## How to score

| Coverage | Meaning |
|---|---|
| Full | Discovered, monitored, and the logs land in the SIEM |
| Partial | Some assets or some signal only |
| None | Confirmed blind spot |
| Unknown | Not assessed yet, or the tool is unverified |

- Every cell scored Full, Partial or None must name the tool that provides it. A score with no tool is not coverage.
- Start the tool name with "?" when the tool is deployed and could cover the cell but nobody has confirmed it. Leave those cells Unknown until someone checks.
- Coverage means you can discover the asset, see what it does, and keep the evidence. A tool that only blocks, with no inventory or logging, is Partial.
- If a tool's logs do not reach the SIEM, its coverage is Partial no matter how good the tool is.
- Score = (Full + half of Partial) / cells assessed. Unknown cells are left out of the score, so a map full of Unknowns is not a good score, it is an unfinished map.

| Depth | Meaning |
|---|---|
| Discover | Sees that the asset exists |
| Detect | Sees what the asset is doing |
| Control | Can stop or restrict it |

### Steps

1. **Set the scope.** Write one paragraph: which AI services are approved, the size of the estate, cloud footprint, tenants, and any OT or industrial segments.
2. **List your tools.** Fill the tool register with every tool that could give AI visibility today: endpoint, network, identity, cloud posture, SaaS audit, SIEM.
3. **Map tools to cells.** For each cell, name the tool that answers its question. Use "?" for tools that are deployed but not verified.
4. **Score each cell.** Full, Partial, None or Unknown. A score needs a named tool.
5. **List the blind spots.** Every None and every empty cell becomes a gap with an owner and a target date.
6. **Ask for decisions.** Take the few decisions only leadership can make to the next meeting.
7. **Re-score.** Set a date to score the map again. Coverage drifts as fast as AI adoption does.

---

Blue Marshal, bluemarshal.dev | framework v0.1.0