Asset Management for an Estate That Includes AI

Every defensive capability in this book starts from a list: nobody can triage, scope, patch or restore an asset whose existence is a surprise. An estate that includes AI adds assets that the classic inventory of servers, endpoints and applications was never designed to hold: models with versions and origins, agents with identities and tool permissions, prompts and skills that steer behaviour, connectors that give a model reach into other systems, the data that grounds them, and AI features that suppliers switch on inside licensed products. Some of these assets act, so an inventory that records a server but not the agent running on it with write access to production records the wrong thing.

This chapter treats one CSF 2.0 Category, ID.AM Asset Management, whose outcome is that the assets enabling the organisation to achieve its business purposes, including data, hardware, software, systems, services and people, are identified and managed consistent with their relative importance to organisational objectives and the risk strategy (19, NIST, 2024). It reads the Category through the three focus areas of the NIST Cyber AI Profile (20, NIST, 2025).

The chapter builds on two conclusions from the earlier volumes. AI Governance concluded that governance is effective when it is codified, evidenced and proportionate to usage mode and risk (AI Governance, Chapters 2 and 25) (72, Nordqvist, 2026), so an inventory that does not record each AI asset's usage mode cannot support that proportionality. AI Platform and Security concluded that a platform is under control when every model call and tool call passes a policy point outside the model (AI Platform and Security, Chapter 25) (73, Nordqvist, 2026); that policy point is also the most reliable source of truth about AI use, and this chapter puts it to work as a discovery source.

Figure 9.1: Asset inventory reconciliation with AI-assisted discovery.

Assets in an estate that includes AI

What ID.AM asks for

CSF 2.0 breaks ID.AM into Subcategories that together describe a living inventory rather than a spreadsheet compiled for an audit (19, NIST, 2024).

Subcategory	Outcome in CSF 2.0	What it means when the estate includes AI
ID.AM-01	Inventories of hardware are maintained	Accelerators and inference hosts, including reserved hosted capacity
ID.AM-02	Inventories of software, services and systems are maintained	AI systems, models, agents, prompts, skills and connectors as assets in their own right
ID.AM-03	Representations of authorised network communication and data flows are maintained	Model calls, tool calls and retrieval paths, including external model endpoints
ID.AM-04	Inventories of services provided by suppliers are maintained	Hosted models, AI services and supplier-enabled features in licensed products
ID.AM-05	Assets are prioritised by classification, criticality, resources and impact on the mission	Criticality that reflects what an AI asset can do, not only what it stores
ID.AM-07	Inventories of data and metadata for designated data types are maintained	Training, evaluation and retrieval data, embeddings and prompt and output logs
ID.AM-08	Assets are managed throughout their life cycles	Model versions, permission changes and retirement, triggered by change

The last row connects the inventory to a conclusion of AI Governance, Chapter 8: classification is triggered by change, such as a new model version, a drift alert, an incident or a move between usage modes (72, Nordqvist, 2026).

Seven asset classes

An estate with AI needs seven linked asset classes, each with its own owner and record.

1. AI systems, the business-facing units such as the claims assistant or the SOC triage assistant, recorded with usage mode, regulatory role under the AI Act and risk classification.
2. Models, with origin, version, hosting location, licence and approving decision record; a system that switches model version has changed.
3. Agents, any component that selects and executes tool calls, recorded with its machine identity, permission manifest, autonomy level and stop path, in the vocabulary of AI Platform and Security, Chapter 19 (73, Nordqvist, 2026).
4. Prompts and skills, configuration that determines behaviour, versioned and owned like code.
5. Connectors and tools, including Model Context Protocol (MCP) servers loaded at run time; a connector extends the reach of every agent that can call it.
6. Data: training, evaluation and retrieval data, embeddings, and prompt and output logs, which often hold the most sensitive information in the system.
7. Security AI: vendor verdicts in endpoint and email protection, assistants in SOAR and ticketing tools, triage and investigation agents, and the planners of a chaos engineering platform. Because it reads attacker-controlled content by design and often holds privileged access, it is recorded with the same rigour as the systems it protects.

The OWASP Top 10 for Agentic Applications treats the misuse of an agent's identity and privileges and the components an agent loads from its supply chain as distinct risks (15, OWASP, 2025). Recording agents, connectors and skills as separate, linked assets makes both visible.

What every record holds

For AI assets the minimum record holds a stable identifier; a named owner; the asset class and usage mode; links to dependencies and dependants; the identity under which it acts and that identity's permissions; the data it reads and writes, with classification; the content it ingests that others control, such as email, tickets or alert fields; hosting location and jurisdiction; regulatory role; approving decision records; criticality; and the date and source of its last verification. The last field matters most in practice, because it tells the SOC and the auditor whether the record describes the estate or a memory of it.

European obligations the inventory serves

Several European instruments assume the inventory exists. NIS 2 lists asset management among the risk-management measures in Article 21(2)(i) (3, European Union, 2022); for entities it covers, including managed security service providers, Implementing Regulation 2024/2690 specifies the classification of assets and an inventory kept current (4, European Commission, 2024), with examples in ENISA's guidance (8, ENISA, 2025). DORA requires financial entities to identify, classify and document their information and ICT assets, map those considered critical and keep the inventories current (Article 8), and to keep a register of information on third-party arrangements (Article 28(3)) (2, European Union, 2022). ISO/IEC 27002 treats the inventory of information and other associated assets as a control in its own right (31, ISO/IEC, 2022).

The AI Act adds an AI-specific layer: a deployer of a high-risk AI system carries the duties of Article 26, and a public-authority deployer must register its use under Article 49 (1, European Union, 2024). The architectural implication is that the AI register required for governance and the asset inventory required for security must be the same list, or two lists reconciled automatically. Following "assure once, comply many" from Architecture as Code (Chapter 10) (71, Nordqvist, 2025), one record then serves NIS 2, DORA, the AI Act and ISO/IEC 27001 controls.

Worked example: asset record for an agent

The illustrative record below is Hansa Mutual's entry for its SOC investigation agent HM-SEC-001, a Mode 5 system operating at Level 2 Supervised under AIDR-0311. It is validated in the pipeline like any configuration, and the platform gateway generates the agent's tool allow-list from it.

# Illustrative: Hansa Mutual asset record for HM-SEC-001
kind: AIAssetRecord
id: HM-SEC-001
name: SOC investigation agent
assetClass: agent
usageMode: 5
decisionRecords: [AIDR-0311]
owner: group-soc-lead
criticality: tier-0
identity: {type: workload, principal: wi-hm-sec-001, tokenCarriesEntity: true}
autonomy: {currentLevel: 2, stopPathHolders: [soc-shift-lead, group-ciso]}
hosting: {site: hansa-dc-frankfurt, jurisdiction: DE}
models:
  - {ref: MDL-SEC-014, origin: self-hosted-open-weight, version: 2.3.1}
promptsAndSkills: [PRM-SEC-001@v12, SKL-ENRICH-ALERT@v4]
connectors:
  - {ref: CON-SIEM-READ, access: read}
  - {ref: CON-EDR-READ, access: read}
  - {ref: CON-SOAR-PROPOSE, access: propose}
untrustedInputs: [alert-fields, email-bodies, url-content]
dataClassification: confidential-personal
lastVerified: {date: 2027-03-04, source: gateway-reconciliation}

During the first reconciliation the gateway logs showed HM-SEC-001 calling a URL-reputation connector that appeared in none of its records; a vendor update to the enrichment skill had added it, and it fetched content from attacker-controlled web pages into the agent's context, widening its exposure to injection without anyone having decided so. The team removed the connector pending review, and the closing control was a gateway change: the tool allow-list is now generated from the asset record, so a call to any unrecorded connector is refused and logged. Replaying the enrichment request in the AI test range showed the call refused, and the finding was closed with the replay as evidence.

AI-assisted discovery and classification

The declared inventory, what owners say exists, is always incomplete; discovery finds what is actually running, and reconciliation brings the two together.

Discovery sources

No single source sees every AI asset, so a practical programme combines several. The AI gateway and policy point is an authoritative inventory of Mode 4 and Mode 5 use, showing which system called which model, with which identity and through which connector, and it found the unexpected connector in the worked example (73, Nordqvist, 2026). Network, proxy and egress logs reveal Mode 1 use outside the approved tool and Mode 3 agents on engineers' machines. Cloud configuration and posture management shows model deployments, vector databases and accelerator instances before anyone registers them; MITRE ATT&CK catalogues cloud service and infrastructure discovery among adversary techniques (T1526, T1580) (10, MITRE, n.d.), and defenders should enumerate their own tenancy first, with authorised read-only access. Endpoint inventories show Mode 2 add-ins, Mode 3 tools and the MCP servers an agent is configured to load. Licence records and supplier release notes show which Mode 0 features are switched on, in which tenant and by default. And code and pipeline repositories show Mode 4 systems in development before they reach production.

What AI adds

Classic discovery produces volume, so the bottleneck is reading and matching records, and AI helps in three steps. In classification, a model reads the evidence for an unknown asset, such as a process name, package list, cloud resource type and contacted domains, and proposes whether it is an AI system, its class, usage mode and likely owner; a cloud function that calls a hosted model endpoint and reads a bucket of claim documents is probably an unregistered Mode 4 prototype. In matching, the model proposes, with confidence and reasons, which records describe the same asset under a host name, a service principal, a gateway identifier and a product name, so that duplicates are merged rather than counted as gaps. In enrichment, it drafts the asset's context from code owners, the data catalogue, the identity provider and decision records, for the owner to confirm.

The discovery AI is itself a Mode 4 system that reads content others control, and a crafted resource description could steer it to present an unregistered agent as a harmless test function. The design response follows AI Platform and Security: the discovery AI proposes and a person decides, it has read-only access to the evidence store and no write access to the inventory of record, and every proposal carries its evidence so that a reviewer can check rather than trust it (73, Nordqvist, 2026).

Reconciliation

Reconciliation sorts every difference between declared and discovered inventory into four outcomes. A match confirms the record and updates its verification date. A drift is an asset that exists in both but differs, such as an agent with an unlisted connector or a newer model version than the one approved. An orphan is a declared asset that discovery no longer finds. An unknown is a discovered asset with no record: shadow AI, a supplier-enabled feature or an inventory gap. Each outcome has an owner and a deadline, shorter for assets that act than for assets that only read.

Practical guide: reconciling the AI inventory with discovered assets

Purpose. Close the gap between the declared AI inventory and what discovery finds, continuously, so that every AI asset that acts has an owner, a criticality and a verified record.

Roles. The asset-management function (owns the process and the inventory of record), AI system owners (confirm classifications), the platform team (gateway and cloud sources), the SOC (consumes context and raises drift seen in alerts), the data protection officer and, where endpoint telemetry is used, employee representatives.

Steps.

1. Keep the inventory of record as code in one repository with a validated schema, with the governance AI register in it or synchronised from it.
2. Connect discovery sources, starting with the gateway, cloud configuration and egress logs, which cover most AI use with the least intrusion; add endpoint inventories only after the data protection assessment and any required consultation.
3. Run classification and matching on every new record with read-only access, storing each proposal with its evidence; the classifier works at Level 1 Assisted.
4. Reconcile daily, routing drift, orphans and unknowns to the owner or the asset-management function. An unknown asset that acts or reads confidential data is escalated to the SOC as a potential security event.
5. Feed confirmed records to SOC enrichment and red-team scoping, and feed closed unknowns back into the discovery rules.
6. Report monthly the unknowns found, median time to close them, the share of acting assets verified in the last 30 days, and unknowns that proved to be security events.

Default values to adapt. Daily reconciliation; 24 hours to resolve drift or an unknown for any asset that acts or reads confidential data, and five to ten days otherwise; verification no older than 7 days for tier-0, 30 for tier-1 and 90 for tier-2 assets; metadata only, never prompt or message content. Adapt to scale and, under DORA, to the ICT risk-management framework.

Definition of done. Every acting AI asset has an owner, a criticality, an identity and a verification date within its limit; overdue unknowns are reported; gateway tool allow-lists are generated from the records; and the SOC sees asset context in triage.

Shadow AI and supplier-enabled features

Shadow AI is AI use the organisation has neither approved nor knows about; it is rarely malicious, usually an employee's faster route or a supplier's unchosen feature.

Where unmanaged AI hides

The usage modes predict where to look. Mode 0 hides inside licensed products and managed services, such as an office suite that adds generated summaries or a security gateway whose classifier changes model, and some of these features already act automatically. Modes 1 and 2 hide on workstations and in browsers, as consumer assistants used instead of the approved tool and add-ins with the user's delegated access. Mode 3 hides in engineers' tools: agents that run with the engineer's credentials and load skills and connectors from configuration files. Unregistered Mode 4 systems appear as prototypes in cloud subscriptions meant to be temporary. A Mode 5 agent should never be shadow AI, but an automation that started as a script and gained a model call can become one quietly. For the supplier route, the organisation's leverage is the contract: Chapter 8 described how deployers require declarations of AI use and advance notice of changes, and discovery verifies those declarations against release notes, consoles and egress records.

Finding it proportionately

Shadow AI discovery uses data about people's work, which in Europe brings obligations of its own. Egress metadata and endpoint inventories are usually proportionate, whereas reading the content of prompts and conversations usually is not. The GDPR (9, European Union, 2016) applies to the telemetry, works councils in several member states must be consulted on tools that can monitor employees, and public authorities must consider which discovery records become requestable under public-access rules. The aim is to find assets, not to judge individuals.

Thwarting the attacker who finds it first

Unknown assets are the entry points attackers look for, and AI makes their search faster. The UK National Cyber Security Centre has assessed that AI will continue to make elements of intrusion operations more effective and efficient, that threat actors are already using it in victim reconnaissance, and that the growing incorporation of AI models and systems across the UK's technology base increases the attack surface for adversaries (37, NCSC, 2025); MITRE ATLAS catalogues reconnaissance and discovery techniques aimed at an organisation's AI models and artefacts (11, MITRE, n.d.). An exposed test endpoint or a forgotten agent credential is found by automated reconnaissance before any annual audit. Continuous reconciliation is therefore part of thwarting AI-enabled attacks, not an administrative exercise.

Criticality and context

ID.AM-05 asks for assets to be prioritised by classification, criticality, resources and impact on the mission (19, NIST, 2024). For classic assets criticality follows the data held and the service supported; for AI assets it must also follow what the asset can do. Five factors decide it, and the highest sets the tier.

Factor	Raises criticality when
Reach	The asset can write to production, change identities or act on customers or residents
Identity	It has its own privileged identity or uses a privileged person's credentials
Exposure	It reads email, web content, tickets or alert fields an attacker can shape
Data	It handles special-category data, case files or security telemetry
Dependency	A critical or important function, or the SOC itself, stops without it

The table explains why security AI is often tier-0. A SOC investigation agent reads attacker-controlled content by design, sees telemetry from across the estate and may propose containment; if manipulated, it can hide an intrusion or disrupt the business. Criticality also changes with the asset: a move to Level 3 Bounded, a new connector with write access or a new source of untrusted input triggers reassessment, in line with AI Governance, Chapter 8 (72, Nordqvist, 2026).

Context for the SOC. An analyst needs to know within seconds whether a host runs an AI service, which agent identities are active on it, what they can reach and who owns them. The inventory provides this as SIEM and SOAR enrichment, so an alert of unusual API activity from an agent's identity reads differently when the record shows the identity may only read, and an alert on an asset with no record is itself a finding. Chapter 18 builds on this enrichment.

Context for the red team. Rules of engagement under Chapter 7 name targets and exclusions by asset identifier, so that an exercise reaches exactly what it is authorised to test. The records also show the interesting paths: an agent with broad reach and exposure to untrusted content is a natural target for AI red teaming (Chapter 13), and an unknown asset a natural objective for adversary emulation (Chapter 12). Every unrecorded asset the red team finds is a reconciliation failure the purple loop closes.

Across the usage modes

Each mode leaves different traces in the inventory (see Chapter 6).

Mode	Where it appears	Characteristic vulnerability	Who judges, with whose identity
Mode 0 Ambient AI	Licensed products and managed services	Default-on features acting outside the inventory	The supplier's model, the product's identity
Mode 1 Conversational assistants	Egress logs from workstations	Unapproved tools receiving confidential data	A person, own identity
Mode 2 Embedded workplace assistants	Add-ins and tenant settings	Delegated access wider than the task	A person, delegated identity
Mode 3 Agentic work tools	Engineers' workstations and configuration files	Agent acting with an engineer's credentials	A person at review, engineer's identity
Mode 4 Built AI applications	Gateway, cloud configuration, repositories	Prototypes that bypass the gateway	Design and a person, service identity
Mode 5 Autonomous production agents	Gateway, identity provider, permission manifests	Unrecorded connector widening reach unnoticed	The agent within boundaries, own identity

Across the autonomy levels

The levels apply to the discovery AI itself, whose errors spread quickly into access control, SOC enrichment and red-team scope (see Chapter 6).

Level	Use in asset management
Level 0 Advisory	The AI reports likely unknowns and duplicates; people investigate
Level 1 Assisted	The AI drafts classifications, matches and enrichments with evidence; the owner confirms; the recommended default
Level 2 Supervised	The AI applies a classification or merge after approval
Level 3 Bounded	The AI tags unregistered resources in test subscriptions and opens the case, within a reversible playbook
Level 4 Autonomous	Not used for the inventory of record or actions on discovered assets

Verifying with security chaos engineering

The experiment follows the Identify example of Chapter 25. The chaos platform deploys an unregistered, benign AI service in a test subscription: a function that calls an approved model endpoint with synthetic data and reads a canary bucket. The steady-state hypothesis is that discovery finds the service, the classifier proposes it as an unknown Mode 4 asset with the correct evidence, and the reconciliation case reaches asset management and the SOC, within 24 hours for discovery and a further 24 hours for the case. A second experiment adds a connector to a test agent without updating its record and verifies that the gateway refuses the call and reconciliation reports the drift within a day.

The three AI focus areas

Securing AI systems. AI systems, models, agents, prompts, connectors and data are inventoried assets with owners, criticality and verified records, and the record is the source from which controls are generated, so that the gateway refuses what the record does not allow (20, NIST, 2025).

AI-enabled cyber defence. AI-assisted classification, matching and enrichment make a reconciled inventory feasible at scale, at Level 1 Assisted, with read-only access and evidence for every proposal.

Thwarting AI-enabled attacks. Unknown assets and shadow AI are what AI-enabled reconnaissance finds first, so continuous reconciliation that treats every acting unknown as a potential security event shortens their exposure.

Nordvik Region and Hansa Mutual

Nordvik Region reconciles its AI register, which lists the benefits-triage system, the staff assistant, the citizen-service assistant and the correspondence classifier, with the AI its suppliers have enabled, adding the phishing-report classifier in the email gateway, generated summaries in the SIEM service and ambient AI in office software. The SOC triage assistant NR-SEC-001 is registered with its owner, read-only identity and alert sources, and the platform team's Mode 3 tools with the credentials they use. Because one set of records serves both its AI Act duties as a deployer and NIS 2, the Region keeps them together and classifies the security AI records so that public-access requests receive the register without the security context.

Hansa Mutual runs discovery across seven markets and the Polish service centre from cloud posture management, egress logs and endpoint telemetry, within the agreements reached with each works council. Mode 5 systems, including HM-SEC-001, the claims-triage agent and the IT-operations agent, are recorded with identities, permissions, owners and criticality, and the gateway generates each agent's tool allow-list from its record. The red team scopes HM-SEC-004 from the same records, and the SOC sees criticality and permissions in every alert. Nordvik's main gap is supplier-enabled features it did not choose; Hansa's is the volume and spread of AI across a large engineering estate.

Summary

ID.AM Asset Management must inventory AI systems, models, agents, prompts and skills, connectors and data, together with the security AI itself, each with an owner, a criticality, the usage mode and, for agents, the machine identity and tool permissions. The AI register and the asset inventory should be one set of records serving NIS 2, DORA, the AI Act and ISO/IEC 27001 at once, and the record becomes a control when the gateway generates an agent's tool allow-list from it.

AI-assisted classification, matching and enrichment, at Level 1 Assisted and without write access to the inventory of record, turn gateway records, logs, licences and cloud configuration into a reconciled inventory. Criticality follows reach, identity, exposure, data and dependency, which places most security AI at tier-0, and the usage modes decide where to look for what is missing.

Because AI-enabled attackers find unknown assets first, the gap must be closed continuously and proportionately, as the chaos experiment verifies. Chapter 10 builds on the inventory with AI-assisted threat modelling and risk assessment.

Sources

1. National Institute of Standards and Technology. The NIST Cybersecurity Framework (CSF) 2.0. (19, NIST, 2024)
2. National Institute of Standards and Technology. Cybersecurity Framework Profile for Artificial Intelligence (Cyber AI Profile). (20, NIST, 2025)
3. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2 Directive). (3, European Union, 2022)
4. European Commission. Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards technical and methodological requirements of cybersecurity risk-management measures. (4, European Commission, 2024)
5. European Union Agency for Cybersecurity. Technical implementation guidance on Commission Implementing Regulation (EU) 2024/2690. (8, ENISA, 2025)
6. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). (2, European Union, 2022)
7. European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (1, European Union, 2024)
8. International Organization for Standardization and International Electrotechnical Commission. ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection — Information security controls. (31, ISO/IEC, 2022)
9. OWASP Foundation. OWASP Top 10 for Agentic Applications for 2026. (15, OWASP, 2025)
10. MITRE Corporation. MITRE ATT&CK: Adversarial Tactics, Techniques, and Common Knowledge. (10, MITRE, n.d.)
11. MITRE Corporation. MITRE ATLAS: Adversarial Threat Landscape for AI Systems. (11, MITRE, n.d.)
12. National Cyber Security Centre. Impact of AI on cyber threat from now to 2027. (37, NCSC, 2025)
13. Nordqvist, G. Architecture as Code. (71, Nordqvist, 2025)
14. Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (72, Nordqvist, 2026)
15. Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (73, Nordqvist, 2026)
16. European Parliament and Council of the European Union. Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data (General Data Protection Regulation). (9, European Union, 2016)