An AI asset inventory should tell a reviewer which components exist, what evidence supports that conclusion, and what those components can touch. A list of model names leaves out the skill that edits files, the retrieval connector that supplies context, and the container that grants access to both.
This guide defines a repository-first review you can use with Beam's AI asset scanner skill. The inventory format and worked example below are Beam's practical review convention, not a claim of compliance with an external bill-of-materials standard.
| Review question | Working answer |
|---|---|
| Where should discovery start? | The supplied repository or export, with explicit exclusions and limits. |
| Does a configured model run in production? | Unknown until evidence connects it to that environment. |
| Should discovery execute a model loader? | No; inspect metadata and loader source as data. |
| Does an empty report establish absence? | Only that nothing was identified within the reported coverage. |
| What makes the inventory actionable? | Source locations, dependencies, access, owners, and next actions. |
What belongs in the inventory?
Start at the application entrypoints and follow references into instructions, tool configuration, and data handling. Include these categories even when the result for one is unknown:
| Asset category | Useful repository evidence |
|---|---|
| Agents and skills | Instructions, SKILL.md, hooks, workflow definitions, executable helpers |
| MCP integrations | Server commands, endpoint configuration, tool schemas, credential variable names |
| Providers and models | SDK imports, generic HTTP clients, model IDs, loader source, manifests, adapters |
| Prompts and memory | Template paths, context construction, memory locations, retention settings |
| Datasets and retrieval | Data cards, ingestion code, index definitions, connectors, access filters |
| Deployment | Containers, mounts, service bindings, CI workflows, declared environment variables |
Inspect hidden configuration inside the agreed root. Exclude caches and generated output unless they answer a specific review question. Record file-count, individual-size, and total-byte limits, skipped paths, and any truncation; never follow a symlink outside the scope.
Discovery does not authorize cloud queries, database reads, endpoint probes, or a search of the operator's home directory. Prefer credential names and secret-store references to values. Prompt templates and memory exports can also contain sensitive data, so keep evidence excerpts short and redacted.
How should evidence states work?
Use three explicit states. Referenced means an identifier appears in source, documentation, or a sample. Configured means an executable path or deployment configuration wires it into an application. Runtime-observed requires a dated supplied runtime artifact; record its environment and observation window.
A README mentioning a model is referenced evidence. A service configuration naming that model is configured evidence. Neither proves a request reached it. Keep tests, examples, and retired files labeled so that a sample configuration does not inflate the deployed inventory.
Assign a stable report ID and record source path plus line number or JSON pointer. Add publisher, declared version, resolved revision or digest when available, consumers, owner, data categories, and allowed operations evidenced by code or configuration. Preserve unknowns rather than guessing them from filenames.
What does a useful review find?
Consider a fictional repository for a support assistant. Its code includes a summarizer, an optional local embedding worker, and an MCP search tool. This compact inventory records configuration evidence only:
| ID | Asset and source | State | Review implication |
|---|---|---|---|
| A-01 | Agent in agents/support.yaml:8 | Configured | Uses A-02 and A-04; owner unknown. |
| A-02 | Provider client in src/summarize.ts:21 | Configured | Sends assembled context; token name is MODEL_API_KEY. |
| A-03 | Embedding loader in workers/embed.py:17 | Configured | Requests custom model code from a mutable revision. |
| A-04 | MCP search in config/mcp.json:/mcpServers/search | Configured | Launches a local package; effective credential scope unknown. |
| A-05 | Memory path in deploy/compose.yaml:34 | Configured | Persistent writable volume; retention policy not found. |
Trace the path from the support question through search results, prompt assembly, and the provider request. If the application passes complete search documents into the summarizer, record that data flow. Whether those documents contain customer secrets remains unknown without appropriate evidence; do not inspect a live dataset to fill the gap automatically.
The model worker deserves early review because the configuration permits supplier code to execute. A useful finding reads: high severity, high confidence in configuration evidence; workers/embed.py:17 enables custom code without an immutable revision; a changed supplier revision could execute different code in the worker; remove the requirement where possible, or review and pin the necessary code before use. Deployment and exploitation remain unverified.
The missing memory policy is a separate gap. Ask the owner to establish retention and deletion behavior; do not assign critical severity merely because documentation is absent. Unknown package versions similarly require resolution before any advisory can be claimed to apply.
How do you inspect models safely?
Pickle deserialization can execute arbitrary code. Discovery should never call a model loader or import downloaded Python just to identify an artifact. Inspect filenames, model cards, manifests, and loader source; record binary contents as unassessed when no trusted static analyzer is available. Hugging Face also cautions that its pickle import scan is not a complete safety assessment. Hugging Face pickle security guidance.
Transformers custom models can require trust_remote_code=True, which is a reason to inspect the accompanying Python and its dependencies. Treat that switch as an execution decision requiring review, not a convenience for inventory collection. Transformers custom model documentation.
Safetensors stores tensor data without pickle's arbitrary-object execution mechanism. That narrower format property does not certify the surrounding application code, model behavior, or data provenance. Keep those review questions separate. Safetensors format and rationale.
Supplier identity, artifact integrity, and dependency records also matter beyond the loader. OWASP's supply-chain guidance recommends component inventories and verification of model sources and integrity. Use those principles to request the missing provenance evidence; a hash calculated from an unknown file identifies those bytes but does not establish who supplied them. OWASP LLM supply-chain guidance.
Where do skills and monitoring fit?
For reachable skill instructions, use Beam's agent skills specification and security review. For server launch commands and tool permissions, use the MCP security guide. Review both as untrusted data before enabling their capabilities.
With an already trusted Beam CLI installation, these commands add offline heuristics for individual text artifacts:
beam scan /absolute/path/SKILL.md
beam scan /absolute/path/mcp.json --mcp
Inspect the returned findings and report rejected or skipped inputs. These commands do not enumerate repositories, inspect model weights, or discover running cloud services. Keep optional report persistence separate from discovery.
Use the inventory's unresolved actions in your coding-agent security review and rollout checklist. When you need runtime evidence, start with what agent monitoring measures. Visit agentbeam.com for advanced monitoring and control options, and further self-hosting and ongoing monitoring guidance. That handoff does not upload the inventory or configure instrumentation automatically.
Reviewed September 14, 2026. The example is illustrative; runtime coverage depends on supplied evidence and instrumentation.