AI assets and attack surfaces

Begin with assets, not only components

An asset is anything whose confidentiality, integrity, availability, authenticity, authorization, provenance, or correct operation matters to the AI system. A component may contain several assets, and the same asset may pass through several components and lifecycle stages.

Threat modelling becomes incomplete when the inventory contains only the model and application.

AI asset categories

Inventory at least these categories:

• Purpose and decisions: intended purpose, prohibited uses, approval criteria, exceptions, and human decision authority.
• Data and knowledge: source documents, prompts, outputs, embeddings, indexes, labels, evaluation data, logs, caches, and backups.
• Models and behavior: weights, adapters, quantization, system instructions, prompt templates, tool definitions, routing policy, and safety configuration.
• Software and artifacts: source, containers, packages, drivers, manifests, SBOMs, signatures, checksums, and build automation.
• Identity and authority: users, service identities, administrators, credentials, keys, tokens, roles, policy decisions, and approval records.
• Infrastructure and operations: compute, accelerators, storage, networks, control planes, observability, deployment pipelines, backups, and recovery processes.
• Evidence: architecture decisions, evaluation results, model and artifact identities, policy events, tool receipts, incidents, and change records.
• Capability and continuity: operating knowledge, runbooks, specialist skills, provider support, portability assets, and exit procedures.

For each asset, state the owner, classification, authoritative source, lifecycle state, required properties, and recovery requirement.

Attack-surface categories

An attack surface is a place where an actor can interact with, influence, observe, replace, bypass, or disrupt an asset. Map surfaces across:

• User interfaces, APIs, file uploads, prompts, and model endpoints.
• Ingestion, parsing, chunking, embedding, retrieval, reranking, and citation flows.
• Model import, packaging, registries, package repositories, builds, and deployment.
• Identity, secrets, administrative interfaces, support access, and control planes.
• Tool registries, agent memory, approval workflows, sandboxes, and external integrations.
• Logs, metrics, traces, evaluation stores, evidence exports, and backup paths.
• Physical hardware, removable media, edge devices, and maintenance channels.

Include lifecycle surfaces. A runtime with no internet access can still be compromised through its update and artifact-import process.

Connect assets to boundaries and actors

Use the trust-boundary method. For every important asset, identify:

Asset and owner:
Required security or control property:
Where it is created, stored, processed, and retired:
Trust boundaries crossed:
Human and machine actors with access:
Interfaces and attack surfaces:
Existing controls and evidence:
Recovery or replacement method:

Review for hidden assets

Ask what can change system behavior without changing the model weights. Prompt templates, retrieval indexes, tool descriptions, routing rules, permissions, runtime flags, and package versions are frequent answers.

Also ask what an attacker would target to hide their actions. Evidence pipelines, clocks, identities, approvals, and evaluation results are assets in their own right.

The output is an asset-to-surface matrix that SAI-110 uses for threat discovery and SAI-120 uses to test architecture completeness.