AI Asset Inventory — Precedent Research

Survey of how existing products present "inventory" pages relevant to Qpoint's AI asset inventory (agents, MCP servers, files, models, etc.). Plan in research-plan.md; executed 2026-07-31.

Screenshots: product screenshots are in precedents/ (Defender AI agent inventory + details panes, Wiz AI-SPM inventory/dashboard/attack-path, Foundry agent store, Docker MCP Toolkit catalog, Langfuse tracing, Astrix NHI discovery, Axonius asset search).

Short answer

The AI asset inventory is no longer speculative — Microsoft ships "Assets > AI Agents" in the Defender portal today, with columns almost identical to Qpoint's intended entity mix: agent name, platform, publish status, MCP servers count, discovered tools, active alerts, risk level. Wiz ships an AI-BOM inventory of models/services/SDKs. The grammar everywhere is the same: filterable table + posture columns + slide-in detail pane, with a dashboard of prioritized risks sitting above the raw list. What nobody unifies yet is the full actor set Qpoint sees — agents and MCP servers and files and model endpoints in one inventory with usage evidence behind each row.

Precedent survey

1. AI-SPM / AI security inventories

Microsoft Defender XDR — AI agent inventory (closest precedent). A first-class asset class in the Defender portal (Assets > AI Agents). Table columns: agent name, platform (Copilot Studio, Foundry, M365, non-Microsoft), publish status, MCP servers count, discovered tools, active alerts, creation time — plus risk level, risk indicators, and recommendation counts. Filter by name/platform/publish-status/risk; columns are customizable. Clicking a row opens a details side pane (not a page-nav): description, version, model, tools, channels, MCP servers. Also queryable as data via Advanced Hunting (AgentsInfo). Covers both platform-registered agents and local agents discovered on endpoints — the sanctioned + shadow split in one list.

Wiz AI-SPM. Extends the cloud inventory to AI: an agentless AI-BOM of every AI service, SDK, model, and training-data store detected in the environment ("immediately detect new AI services introduced into the environment" — shadow-AI framing). Above the inventory sits an AI security dashboard with a prioritized queue of contextualized risks; attack-path analysis renders AI pipeline risk as a graph. Pattern: inventory = evidence layer, dashboard = meaning layer, graph = blast-radius layer.

Zenity (no capture — JS site). Markets a "live inventory of every AI agent" across Copilot Studio, ChatGPT Enterprise, Agentforce, plus homegrown (Foundry/Bedrock/Vertex) — with ownership, permissions, integrations, and risk per agent, explicitly pitched at uncovering shadow AI. Confirms the column set: who created it, what tools it uses, what systems it touches.

Astrix (stylized visual only). Non-human-identity inventory: service accounts, OAuth apps, API keys, and now AI agents/MCP. Their hero visualization is instructive framing: one big count (1,500 integrations) broken down by risk (75 high / 425 medium / 1,000 low) with connected-platform icons — concentration-first, list second.

2. Agent observability

Langfuse. Dev-facing rather than security-facing: the inventory-like surfaces are the trace list (per-trace model, tokens, cost, latency) and per-model/per-user cost aggregations. The lesson for Qpoint is the usage evidence: every asset row can carry observed activity (calls, tokens, cost, last-seen) rather than just registration metadata. LangSmith/Arize/Galileo follow the same shape (not captured).

3. Cloud consoles

Azure AI Foundry. Agents are a left-nav list per project; published agents appear in an Agent Store / registry — a card catalog with publisher and description. First-party consoles inventory only their own agents — which is exactly the gap third-party inventories (Defender, Zenity, Qpoint) exist to close: cross-platform + shadow coverage. AWS Bedrock / Vertex not captured but same shape (per-service resource lists).

4. MCP registries & gateways

Docker MCP Catalog / Toolkit. MCP servers presented as a card catalog (icon, name, publisher, description, tool count), discoverable by capability/category. The trust story is the differentiator: verified-publisher vs community badges, signed images, SBOMs, provenance. The official MCP registry is API-only; Smithery is the same card-catalog shape. Nobody presents MCP servers as observed infrastructure in your environment — registries answer "what can I install," not "what is running and is it sanctioned."

5. Classic inventory grammar

Axonius (cyber-asset management). The mature reference: one huge table per asset class (Devices, Software, …), a query wizard composing filter expressions over any field ("Windows devices seen in last 7 days"), saved queries, and an asset graph for relationships. Last-seen recency is a first-class field — inventories are about observed presence, not registration. ServiceNow CMDB / SaaS-management / API-inventory tools share the grammar: facets + query + table + detail + freshness.

6. Internal prior art (bob-wire)

• c6 built the raw inventory surface; c12 refined it: a category thesis per entity class, list + representative-detail pages, jump selects between them, and repos added as a first-class entity. c12's "every category page answers what matters about that entity type" is a stronger idea than any external precedent's generic table and should survive.
• c16 fleet data (app/data/c16-fleet.ts) already carries the agent/MCP vocabulary (agents, findings, policy state) an inventory would be built from; c13 (ai-agent-policies.ts) has the actor/trust vocabulary.

Round 2 — general inventory precedents (non-AI)

A second pass over inventory UIs from any domain, read for grammar rather than competition.

NetBox — network/infrastructure inventory (DCIM/IPAM)

The strongest open-source example of a multi-class inventory. The home dashboard is a wall of per-object-class counts (devices, IPs, prefixes, racks, connections…) — each count is the door into that class's list. List views are dense tables with two ideas worth stealing: inline utilization bars (a prefix row shows its usage as a bar, not a number) and status as a colored badge vocabulary shared across all object classes (active/planned/deprecated). Every object class gets the same table grammar — columns differ, the rhythm doesn't.

Backstage — software catalog

Spotify's internal-software inventory, now the default answer to "catalog of what we run." Its defining choice: ownership is the first-class column — every entity (service, website, library, ML model) must have an owner, and the catalog is pitched as "who owns what, made discoverable." Type/lifecycle/owner columns + tag filters; entity detail is a full page with relations (part-of-system, depends-on). The catalog is fed by metadata files colocated with code and harvested — registration is decentralized, the inventory is the aggregation.

Ralph — IT asset management

Open-source ITAM/DCIM from Allegro: the traditional back-office inventory — hardware assets with lifecycle (in-use / spare / liquidated), location, owner, and financials. Representative of the ITAM genus (Snipe-IT, GLPI): inventories where the lifecycle state machine is the core column, a dimension the security tools mostly lack.

Tenable — vulnerability-centric asset inventory

Explore > Assets: one table for hosts, web apps, cloud resources, and identities, with computed scores as columns — exposure score and asset criticality rating per row — plus source (which scanner/connector saw it) and last-seen. The notable move: the inventory doesn't just list assets, it ranks them by how much they matter, and shows provenance of the observation (which sensor reported this asset) as a column.

Surveyed without capture

• Intune / Jamf / device fleets — Devices > All devices: compliance state as the hero column (compliant/non-compliant badge), OS/version columns, bulk actions on selection. The fleet grammar is table + compliance badge + remote-action toolbar.
• ServiceNow CMDB — the maximal precedent: every asset a configuration item in classed tables with relationship maps. Its known failure mode is the cautionary tale: CMDBs decay when population is manual — inventories must be fed by observation, not data entry (Axonius/Tenable/Qpoint all exist because of this).
• Commerce stock inventories (Shopify/WooCommerce/Square) — a genuinely different genus: the row is a SKU and the core column is a mutable quantity with thresholds (low-stock alerts), adjustment history, and multi-location breakdown. The transferable idea is the threshold alert on a per-row metric, not the layout.
• GitHub dependency graph — dependencies as an inventory: auto-detected from manifests, each row flagged with known vulnerabilities (Dependabot). Proof that "inventory + advisory feed join" reads naturally as a list with warning rows.

Extracted patterns

What the good inventory pages consistently do:

1. Counts before rows. A summary strip — total assets, breakdown by risk or type, what's new — sits above the table (Astrix's 1,500-by-risk, Wiz's dashboard queue, Defender's alert counts).
2. Table, not cards, for owned assets. Cards appear only in marketplace contexts (Docker catalog, Foundry store). Everything that answers "what's in my environment" is a dense filterable table.
3. Posture as columns. Risk level, active alerts, publish status, recommendations — the governance story is carried in 2–3 badge columns on the row, not on a separate page.
4. Slide-in detail pane first, full page second. Defender's details pane keeps you in the list while answering "what is this agent"; deep-dive is a second click.
5. Relationship counts as columns. Defender's "MCP servers: 3" and "discovered tools: 12" per agent row — cross-entity linkage compressed to a number that invites the drill.
6. Shadow vs sanctioned in one list. Defender mixes endpoint-discovered local agents with platform-registered ones; Wiz leads with "detect new AI services immediately." The unapproved asset is a row with a flag, not a separate product area.
7. Observed presence over registration. Axonius's last-seen, Langfuse's usage/cost — credible inventories prove the asset is real and active, not just declared.
8. Trust/verification badges for third-party components. Docker's verified-publisher markers are the model for MCP-server rows: provenance is a column.

Added by Round 2:

9. Per-class counts as the front door. NetBox's dashboard of object-class counts is the cleanest multi-entity entry point — each count is a link into that class's list (converges with pattern 1).
10. Every asset has an owner. Backstage makes ownership mandatory and primary; an inventory row without an accountable owner is an open question, not a record.
11. Inline micro-visualizations on rows. NetBox's utilization bars — a per-row metric rendered as a bar/spark beats a numeric column for scanning.
12. Computed rank, not just state. Tenable's exposure + criticality scores order the inventory by how much each asset matters, not alphabetically.
13. Observation provenance as a column. Tenable shows which sensor saw this asset; for multi-source inventories, "how do we know" belongs on the row.
14. Lifecycle state machines. ITAM's in-use/spare/retired dimension — sanctioned AI assets will need approved/trial/deprecated states, not just risk states.
15. Fed by observation, not data entry. The CMDB decay lesson: rows must appear because something was seen (harvested metadata, network traffic, scanners), never because someone typed them in.

What nobody draws yet

• The unified actor inventory. Defender inventories agents (MCP servers only as a count column); Docker catalogs MCP servers (but as a marketplace, not your environment); nobody inventories agents + MCP servers + files/repos + model endpoints as peer entity classes in one governed inventory — which is exactly the c12/c16 direction with governance columns added.
• Files as AI assets. No precedent treats "files/data touched by agents" as an inventory class; DSPM tools inventory data stores but don't join them to agent activity.
• Traffic-grounded evidence. Every security precedent infers from platform APIs and cloud config; none grounds each row in observed wire traffic the way Qpoint can (per-asset usage evidence à la Langfuse, but from the network).

Implications for the c19 brief

1. Lead with a summary strip: total AI assets, by type, by posture, new-this-week — before any table.
2. One inventory, segmented by entity class (agents / MCP servers / models / files-repos), each class with its own thesis columns (c12 pattern) but a shared row grammar.
3. Carry posture in 3 badge columns max: sanctioned/shadow status, risk/trust level, open findings count.
4. Put relationship counts on rows (agent → MCP servers, tools, files touched) as the drill invitation.
5. Last-seen / usage evidence on every row — the Qpoint differentiator; consider a sparkline or call count per asset.
6. Row click opens a detail pane, not a page; full detail page is the second hop (matches Defender and c12's list→detail rhythm).
7. Flag shadow assets inline with a filter chip, never as a separate page.
8. MCP-server rows get provenance/verification badges (known publisher vs unknown), borrowing Docker's trust grammar.
9. Keep a query/filter affordance stronger than dropdowns (Axonius direction) but wireframe-simple: a filter bar with composable chips.

Added by Round 2:

10. Owner column on every entity class (Backstage) — for agents especially: who runs this agent is as important as what it touches.
11. Usage as an inline bar/spark per row (NetBox utilization) — render the traffic-evidence differentiator visually, not as a raw count.
12. Order by computed importance (Tenable) — a risk-or-usage rank as the default sort, so the inventory opens on what matters.
13. Show observation source per row ("seen in traffic", "declared in config", "found on endpoint") — Qpoint's wire-observation is a provenance story; make it a column, not a footnote.
14. Give sanctioned assets a lifecycle (ITAM approved/trial/deprecated) alongside the shadow flag, so the inventory governs the whole asset lifespan, not just discovery.