AI inventory

Overview

Discover → AI inventory lists every AI asset Shield360 can see in the current environment. Each asset has:

• a type, name and vendor
• when it was first and last seen, and how much it was used
• the people and computers using it
• the evidence behind each of those facts
• an approval status, taken from your approved AI list
• an owner and a business owner, its purpose and use case, a risk rating with its rationale, notes and a review date, which your team records
• a recorded decision that can replace the approval status, with its conditions and an expiry date

Shield360 does not keep a copy of what it discovers. It works out the facts from telemetry each time the page loads. Only what people record about an asset is stored.

What is in the inventory

Type	Where it comes from
AI tool	Coding tools the collector reports (Claude Code, Codex, Cursor…), AI desktop apps and AI websites on your computers, and non-browser processes that connect to an AI provider directly. A product seen as both a desktop app and a website is one tool.
Model	Models that coding tools report, and models in the traces from your instrumented applications.
Vendor	The providers behind all of the above, plus the vendors of your subscriptions (Costs → Subscriptions) and your spend connectors.
API key	Live keys that your OpenAI and Anthropic spend connectors list. Shield360 stores only the vendor’s key id and name and a keyed fingerprint of the vendor’s hint, never any character of the key.
Agent	Agents registered in the agent gateway, and applications whose traces show tool calls.
MCP server or API	Tool servers registered in the agent gateway, and MCP servers configured in AI clients on your computers (Claude Desktop, Claude Code, Cursor, VS Code, Windsurf and others), by the name they were given.
AI application	Applications instrumented with OpenTelemetry that call a model but no tools.

AI software the collector finds installed or configured is part of the inventory too: an installed app or local model runtime joins the tool it is (an installed ChatGPT and time in ChatGPT are one asset), an editor extension is a tool keyed by its extension id (ext:github.copilot) across every editor it is in, a configured MCP server is keyed by its name (mcpcfg:github), and the models a local runtime serves are models checked against the approved list with the runtime as their provider. The Presence column and filter separate Installed, Seen in use and Installed, not seen in use; each asset’s page lists the computers and people it is installed for, with the version and where.

The collector, trace and gateway evidence covers the last 90 days. Subscriptions, connectors and registered gateway agents and servers appear for as long as they exist.

Evidence follows the same rules as Shadow AI:

• Browser traffic to a provider is counted as the website, not as a separate connection.
• Traffic to Google shares addresses with Google’s other services, so it counts only when an API key was present.
• Workloads the controller found in your cluster, but which send no traces, are left out. Nothing shows they use AI.

Each asset has a stable key, for example tool:cursor, model:gpt-4o or vendor:openai. What your team records is stored against that key, so it stays with the asset when the facts about it change.

Register AI systems and models by hand

Telemetry finds generative AI in use. It cannot find a pricing GLM, a gradient-boosted fraud model or a vendor’s scoring model running in your own systems. Select Add AI system to register one. This needs the Compliance module and inventory.manage.

Choose the kind

AI System is the primary unit of governance and reporting. AI Model is a component of a system, or a model that stands alone. The NAIC Supplement examines a stand-alone model separately when it independently creates a direct consumer impact or material financial risk.

Name it

The name sets the key: application:<name> for a system and model:<name> for a model, for example model:auto-pricing-glm-v3. A name that is already registered is refused.

Say what it is

Choose its production status, model types and operation areas, and describe its use. Then fill in the rest of its NAIC profile on its page, which opens when you save.

A registered entry shows in the inventory under the name and vendor you gave it. In production, it counts as in use for impact assessments, the EU AI Act system list and the controls, just as an asset seen in telemetry does. A registered entry that is retired or rejected does not count.

Registering a model, or approving it through an AI request, never adds it to the approved-model list the AI proxy enforces when its profile records it as anything other than generative or agentic AI. That list only governs what passes through the proxy. A model with no recorded model type is treated as generative, as before.

NAIC AI system profile

Each AI tool, model, agent, MCP server and application page has a NAIC AI system profile. It holds what the NAIC AI Risk Evaluation Supplement asks about each system: the inventory columns of Exhibit A and the per-model requests of Exhibit C. Discovered and registered assets have the same profile.

Section	Fields
What it is	AI System or AI Model, and for a model the AI System it is part of; description of use and the broader system; operation or program areas (the Supplement’s 13, from Marketing to Other Insurance Practices); lines of business; model type (Generalized Linear Models, Generative AI, Agentic AI, Other AI/ML Models); for agentic AI, its objectives and the actions it may take without human approval
Decisions and impact	Automation, augmentation or support; direct consumer impact (yes or no) and how; material financial impact (yes or no) and its basis; effect on financial statements, risk assessment or controls
Version and status	Version, implementation date, production status (in development, pilot, in production, retired)
Development and vendor	Internal, third party or a mix; the vendor, linked to its vendor: inventory entry when there is one; whether it was purchased, built for the company and can be modified; internally or externally trained
Limitations, risks and oversight	Limitations; model risks (potential adverse consumer impact); whether a human is in the loop; how human review is assured and how exceptions or errors are found and resolved
Risk tiering	The tiering questions, the inherent risk tier with its reasons, the residual risk after controls and its rationale, and a tier set by hand. See Risk tiering.

Each save is written to the audit log as ai_system.profile.update, with the fields that changed and the resulting tiers. Registration is ai_system.register. Neither copies the text you typed into the audit log.

The Risk tier column shows each asset’s reported tier: the tier set by hand when there is one, otherwise the inherent tier. Select High-risk systems, or filter Risk tiers, to list the systems tiered high. This tier is the NAIC-facing one. The 0–100 risk score and the risk rating are unchanged.

Approval status

Approval comes from Settings → Collection & deployment → Approved AI providers and models. Shield360 does not store it separately. The AI proxy can also warn or block requests outside the list. Each use of an asset is checked exactly as the “AI outside the approved list” report checks it:

• A provider is approved as a whole unless you list models. If you list models, only those models are approved, and * matches any run of characters (claude-*).
• A coding tool counts as the provider your prompts pass through. If cursor is approved, a Claude model used through Cursor is approved. The same model used through Claude Code is checked against anthropic.

An asset gets one of three statuses:

Status	Meaning
Approved	Every use is on the approved list.
Not approved	At least one use is outside the list. The asset’s page shows which uses, and whether the provider or the model is the problem.
Not covered	The approved list is off, or there is nothing to check against it. An MCP server, for example, has no provider or model.

Someone who maintains the inventory can record a decision that replaces the status from the list:

• Under review
• Approved by exception, for example use outside the list that you have accepted
• Rejected: the organisation does not allow it. A rejected asset that is still used is counted on the page and raises an alert.
• Retired

A decision can carry conditions (for example “no customer data”) and an expiry date. When the expiry date passes, the status from the approved list applies again, the page shows that the decision lapsed, and Shield360 raises an alert. Shield360 records who made each decision and when, and updates that record whenever the status, conditions or expiry change.

Clear the status to return to the one from the approved list. Its conditions and expiry are cleared with it.

People who do not maintain the inventory can ask for a decision instead. Request approval on an asset that is not approved, not covered, under review or rejected opens an AI request already filled in with the asset. When a reviewer approves the request, the asset is recorded as approved by exception with the request’s owner, rating, conditions and expiry; when they reject it, the asset is recorded as rejected.

Accountability, decision and risk

Open an asset to record:

• Owner: the person or team accountable for running it. For an AI agent (a coding agent, an agent sending traces, or Microsoft 365 Copilot), an administrator can instead assign a member as owner from Agent authorization → Coverage. The member’s name is kept here as the owner, and Shield360 also stores who they are, so it can flag the agent when they leave the organisation. Typing a different owner here removes that link.
• Business owner: the person or team who answers for it to the business.
• Use case: the business use case it serves, for example “customer support replies”.
• Purpose: what it is used for, and on what data.
• Risk rating: low, medium or high. You must give a reason for the rating.
• Notes
• Last reviewed: the date of the last review. An asset without one counts as not reviewed, unless it is retired.
• Status, with its conditions and expiry date, as described in Approval status. The expiry must be after today and within three years.

Each change is written to the audit log (Govern → Records → Audit log) as inventory.asset.update. The entry records which fields changed, the new risk rating, status, expiry, decision date and review date, and the previous rating and status. It does not record the owners, purpose, use case, rationale, conditions or notes, because they may name a person. Opening an asset’s page and exporting the inventory are recorded as data access.

The asset’s page also links to the other governance views where they apply:

• Costs → API keys, for keys that key hygiene says should be revoked
• Agent access, for gateway agents that hold access they do not use
• Settings → Collection & deployment and the AI outside the approved list report, for approval

Risk score

Every asset has a risk score from 0 to 100. Shield360 works it out each time the page loads, from what it observed and what your team recorded, so it changes as soon as behaviour does. The Risk score column sorts the list, and the Risk score filter shows high, medium or low scores.

Open an asset to see where its points come from:

Factor	Points
Approval status	Rejected and still in use 30 (rejected, not seen 10), outside the approved list 20, under review 8, not covered by the list 4, approved by exception 2
Open risks	The worst open risk linked to the asset in the risk register, likelihood × impact × 0.8, plus 2 for each other open risk, up to 25
Violations (30 days)	4 for each critical violation, 2 for each warning and 1 for every two informational ones, up to 20
Recorded risk rating	High 15, medium 8, low 2; an asset in use that is not rated 4
Unused access	5 for each grant the access review found unused, up to 10
Key hygiene	Owner’s account disabled 8, no known owner or owner not in the directory 5, stale 3, never used 2, up to 10
Lapsed decision	8 when a recorded decision has expired
No owner	5 for an asset in use that nobody owns

The total is capped at 100. A score of 70 or more is high and 40 or more is medium. Violations count against an asset when they name it as the tool or model involved.

When an asset’s score rises to the threshold (70 unless you change it on the risk register page), Shield360 raises a risk.threshold alert, once per crossing. See Risk register → Alerts.

The asset’s page also lists the risks linked to it, if your role may read the risk register.

Alerts

Every hour, Shield360 checks each environment for assets it has not seen before and adds them to the register. For each one it raises an inventory.new_asset alert with the dedupe key inventory:<asset key>. An asset outside the approved list is raised as a warning; any other is raised as info.

• The first check in an environment adds everything already there without an alert for each.
• An asset is raised once. It is not raised again when it goes quiet and comes back, or when two checks run at the same time.
• A single check raises at most 25 alerts, plus one alert that counts the rest.
• Alerts name the asset and its vendor, never the people who use it.

The same check raises two alerts for the decisions your team records:

Kind	When	Dedupe key
inventory.decision_expired	A decision’s expiry date passed since the previous check. Each lapse is raised once.	inventory:expired:<asset key>:<expiry>
inventory.rejected_in_use	A rejected asset was used since the previous check. It is raised at most once a day per asset.	inventory:rejected:<asset key>

Both are warnings, and both give counts of people and computers rather than names.

To send these alerts to a channel, add an Event rule for the kind under Alerts → Rules. The schedule can be changed with the AI_INVENTORY_SCAN_SCHEDULE environment variable, which takes a cron expression. The default is 41 * * * *.

Lifecycle: new, changed and vanished assets

The same hourly check tracks what each asset is, so your team sees when it changes or goes away. Each asset has a lifecycle state, shown in its own column on the inventory page and on the asset’s page:

State	Meaning
Pending review	Seen, and nobody has reviewed or accepted it yet.
Unchanged	Seen, and it matches what a reviewer accepted.
Changed	Seen, and its material attributes no longer match what a reviewer accepted.
Vanished	Not seen for the grace period, while every source that reported it kept working.
Unknown (source unhealthy)	Not seen for the grace period, but a source that reported it is silent or could not be read. It may still be in use.
Retired	A reviewer acknowledged that it is gone. If it is seen again, it is pending review again.

The Review queues above the list filter it to pending, changed, vanished or unknown assets. You can also filter with lifecycle= (new, unchanged, changed, vanished, unknown or retired).

What is compared

An asset is identified by its key. What is compared is a fingerprint of its material attributes, which depend on its type:

Type	Compared
AI tool	Vendor, the models it used, and the providers it reached directly
Model	Vendor, and the providers it was reached through
Vendor	How it is paid for (subscription, spend connector, vendor keys), and subscription plans
API key	Vendor, the key’s name and product
Agent	Models, providers, tool count, active gateway grants and the linked application
MCP server or API	Kind, whether it is enabled, the tool names in its catalogue, and the endpoint’s host
AI application	Models and providers

Usage, people, computers and dates are never compared. When an asset changes, its page shows what was added and removed for each attribute. Select Accept change to make what is seen now the new baseline. A pending asset is accepted with Accept as reviewed, or by recording a review date. Shield360 checks that the asset has not changed again since you looked at it.

Vanished assets and unhealthy sources

An asset is vanished only when every source that last reported it is working. Otherwise it is unknown, and no alert is raised. A source is treated as unhealthy when:

• it could not be read during the check;
• for desktop, browser and network activity, a computer that reported the asset is revoked or has not reported for 24 hours (or, when no computer is known, none has);
• for traces, no application has sent traces for 24 hours;
• for spend connectors, nothing has been billed for 3 days.

The agent gateway, subscriptions and the vendor key list describe what is configured, so an asset they list counts as seen at every check. Select Acknowledge and retire on a vanished or unknown asset to retire it. Its register status becomes Retired.

Alerts

Kind	Severity	When	Dedupe key
inventory.changed	Warning	An accepted asset’s attributes moved away from its baseline. Raised once for each new fingerprint.	inventory:changed:<asset key>:<fingerprint>
inventory.vanished	Info	An asset went unseen for the grace period on healthy sources. Raised once each time it disappears.	inventory:vanished:<asset key>:<time>

The first check in an environment only records the baseline and raises no alerts. A single check raises at most 25 alerts of each kind, plus one alert that counts the rest. A change alert names the attributes that changed, never their values.

History

Each check records the day’s snapshot of the inventory: every tracked asset’s key, type, name, vendor, state and fingerprint. It also records what was added, removed, changed or changed state since the day before. The Inventory history panel lists the days. Select Changes to see a day’s delta, or As of to download the inventory as it stood that day. The asset’s page shows its own history.

curl -H "Authorization: Bearer $SHIELD360_API_KEY" \
  -H "x-shield360-organisation-id: $ORG_ID" \
  -H "x-shield360-project-id: $PROJECT_ID" \
  -H "x-shield360-environment: production" \
  "https://your-shield360-host/api/governance/inventory/export?format=csv&asOf=2026-10-01"

asOf returns the newest snapshot on or before that day.

Settings

Under Lifecycle settings, an organisation role with inventory.manage can change two values for the whole organisation:

Setting	Default	Range
Grace period	7 days	1 to 90 days
History retention	400 days	30 to 1,096 days

History older than the retention is deleted by the hourly check.

Export for auditors

The page has two downloads, both limited by the filters you have set:

• Export CSV: one row per asset, with the counts of people and computers, the evidence sources, the approval, the recorded decision with its conditions and expiry, the risk score, and the other recorded fields. It also has a column for each field of the NAIC AI system profile, from naic_kind and operation_areas to inherent_risk, inherent_risk_reasons, risk_override, reported_risk and residual_risk. Operation areas and model types use the Supplement’s wording.
• Export JSON: every asset in full, including its evidence, its risk score with the factors behind it, the names of the people and computers using it, and its aiSystemProfile with the inherent tier and its reasons. The organisation’s riskMethodology (materiality threshold and risk criteria) is at the top.

An export with asOf is unchanged: it is the day’s snapshot and has no profile columns.

You can also call the API directly:

curl -H "Authorization: Bearer $SHIELD360_API_KEY" \
  -H "x-shield360-organisation-id: $ORG_ID" \
  -H "x-shield360-project-id: $PROJECT_ID" \
  -H "x-shield360-environment: production" \
  "https://your-shield360-host/api/governance/inventory/export?format=csv&status=not_approved"

The filters are type, status, risk (low, medium, high or unrated), score (low, medium or high), tier (high, moderate, low or untiered), owner (text, or unassigned), vendor and q (name).

Impact assessments

Applications and agents in use, tools rated high risk, tools and models tiered high, and stand-alone models with a direct consumer or material financial impact need an impact assessment for ISO/IEC 42001 A.5.2–A.5.5. An asset’s page shows its current assessment and next review date, and Start assessment for someone who may manage assessments. Approving an assessment records its residual risk as the asset’s risk rating here.

Permissions

Permission	Allows	Held by
inventory.read	Viewing and exporting the inventory, and the NAIC AI system profiles and risk tiering	Owner, Administrator, Compliance officer, Analyst, Member, Viewer
inventory.manage	Recording owners, purpose, use case, risk, notes, review date and decisions; accepting changes and retiring vanished assets; registering AI systems and models, recording their NAIC profile and setting a tier by hand; changing the lifecycle settings and the materiality threshold (organisation role only)	Owner, Administrator, Compliance officer

The server checks both permissions. Every read and change applies to the environment you have selected. A database config named in the request is ignored.

Personal data

The inventory computes people and computers from telemetry, so it stores nothing about them. The owners, purpose, use case, risk rationale, conditions and notes are free text, though, and can name a person:

• A person export includes every register entry in which one of those fields names the person as a whole word.
• Erasure clears those fields and keeps the entry, so the asset stays in the register.
• An organisation export includes every register entry as ai_inventory_records, and the lifecycle and its history as ai_inventory_lifecycle, ai_inventory_history, ai_inventory_history_changes and ai_inventory_lifecycle_settings. These hold asset keys, names, states and fingerprints, and collector device ids rather than computer names. The NAIC AI system profiles are exported as ai_system_profiles, and the materiality threshold and risk criteria as ai_risk_methodology.

Limits

• Coding agents that send traces report how many people used them, but not who. Those assets show a count without names.
• Request counts from traces cover the last day, as on the Agents page.
• An Azure OpenAI connector is listed under the vendor microsoft, and AWS Bedrock under aws.