AI Asset Inventory
Overview
AI Gateway → AI Asset Inventory builds a complete list of the AI assets defined in your installation (LLM provider connections, models, MCP and A2A targets) and compares it against real traffic to report shadow AI usage findings — model or provider use outside your allow-list, targets not in the catalog, unregistered MCP/A2A servers, and catalog drift. This is a standalone screen, not a tab embedded in the main Analytics (ai-dashboard) hub — it has its own menu entry, but shares the same viewing permission as Analytics.
This report corresponds to the AI system inventory concept required by ISO/IEC 42001 (knowing every AI asset in your installation) and to the GOVERN (inventory, governance) and MAP (mapping actual usage) functions of the NIST AI RMF. It is not presented as a compliance certificate — it's a starting point for reviewing where your installation stands against those frameworks.
Two-Plane Model
The report works by taking the difference between two independent data sources:
Reflects current configuration: registered LLM provider connections, the model catalog, the aiRouting definitions of deployed proxies, and both registered and inline (embedded in a proxy) MCP/A2A targets. Independent of any time range — it always shows "what's defined right now."
Pulls the model/provider names actually used in your chosen time window from traffic logs with a single aggregation query. It only adds "was this used / when was it last seen" — it doesn't replace the inventory.
Shadow usage is the difference between these two planes. Some findings — allow-list violations and unregistered inline MCP/A2A targets — come only from the inventory plane: Elasticsearch cannot observe a blocked request (and therefore which model it tried to reach), because the request was rejected before it ever reached the provider.
Findings and Inventory Tables
The screen shows two separate tables:
- Shadow AI Usage Findings — one row per detection (finding code, severity, the asset involved, observed request count, last-seen time)
- AI Asset Inventory — one row per asset (type, name, provider, whether it's in the catalog, whether an allow-list is enforced, health status, whether drift was detected, how many proxies use it)
The KPI counters at the top (Total Assets, Critical Findings, Warning Findings, Unrestricted Providers, Uncataloged Models, Unregistered MCP/A2A Targets) are always the true, pre-filter counts — the severity filter only narrows the findings table below, it never affects the KPI counters.
The time range and environment filters affect only the observation plane (Elasticsearch); the inventory plane always shows current configuration regardless of these filters. The severity filter (All / Critical only / Warning only) narrows only the findings table.
Finding Codes
On screen, finding codes, asset types, and severities are shown as translated labels rather than the raw values below — the raw value stays visible alongside the label (for example, in a tooltip or a secondary line) for anyone matching a finding to logs, exports, or an alert payload.
| Code | Severity | Meaning |
|---|---|---|
PROVIDER_NOT_IN_CATALOG | Warning | The connection's catalog reference is empty or not found in the catalog (legacy/manual definition) |
PROVIDER_UNRESTRICTED | Warning | The connection's allowed-model list is empty — any model can be used through this provider |
PROVIDER_ENDPOINT_MISMATCH | Warning | The connection's endpoint differs from the catalog's default endpoint |
PROVIDER_OBSERVED_NOT_CONFIGURED | Critical | A provider observed in Elasticsearch doesn't match any enabled connection (a stale deployment or a deleted connection) |
MODEL_NOT_IN_CATALOG | Critical if observed, Warning otherwise | A model used in a proxy's routing is found neither in the model catalog nor the connection's supported-model list |
MODEL_NOT_IN_ALLOWLIST | Critical | The model isn't in the connection's allowed-model list — this can produce a runtime error or a silent failover |
MCP_TARGET_UNREGISTERED / A2A_TARGET_UNREGISTERED | Critical | An MCP/A2A target embedded (inline) in a proxy isn't found in the set of registered connections |
MCP_CATALOG_DRIFT / A2A_CATALOG_DRIFT | Warning | Drift detected between the approved catalog hash and the target's live tool/capability list |
Limits of the Observation Plane
This report can only see traffic that goes through the Apinizer AI Gateway. Calls an application makes directly to an LLM provider without going through Apinizer at all — genuinely "shadow" usage in the fullest sense — are not visible in this report: Apinizer does not perform any egress or DNS monitoring. The report audits the consistency of known (gateway-routed) AI traffic against your inventory; it is not a complete external audit of every AI use across your organization.
The observation plane can also be truncated in large installations: if the number of distinct model/provider/tenant names exceeds an internal term limit, the screen shows a "the observation plane truncated some results" banner and the report should be treated as incomplete for that period — narrowing the time range is recommended in that case.
XLSX Export
The report can be exported as a two-sheet Excel workbook, Findings and Inventory; the exported data includes all findings for the selected time range, independent of the on-screen severity filter.
Wiring Into an Alert
The critical finding count from this report can be wired into an alert through the AI Shadow Asset Count trigger. The counter doesn't accumulate over a time window — each check reads the currently critical finding count (a state counter, not an event counter); setting the threshold to 1 gives you an alert for "any shadow AI asset exists at all."