They often treat discovery as a reporting task instead of a control requirement. An AI-BOM is only useful if it captures agents, tools, model endpoints, and MCP servers well enough to support access review, change control, and incident investigation. Without that linkage, the inventory may look complete while the real attack surface remains invisible.
Why This Matters for Security Teams
AI-BOM and discovery are often treated as inventory exercises, but for autonomous systems they are control foundations. If agents, model endpoints, tool connectors, and NHI attack surfaces are not discoverable, security teams cannot review access, approve change, or investigate misuse with confidence. That gap matters because agentic systems can act, chain tools, and reach data faster than many governance processes update. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but AI inventory now has to support operational decisions, not just documentation.
Practitioners also underestimate how quickly undiscovered credentials and integrations become incident pathways. NHIMG’s DeepSeek breach analysis shows how exposed secrets and data can turn into broad compromise conditions when visibility is weak. In practice, many security teams encounter incomplete AI inventories only after a model, agent, or connector has already been used outside the approved workflow.
How It Works in Practice
Effective AI-BOM work starts by defining what must be in scope: models, prompts, agents, tool chains, plugin endpoints, MCP servers, retrieval layers, service accounts, secrets, and the human owners who can change them. Discovery is not a one-time scan. It is a continuous control that reconciles what is deployed, what is reachable, and what is actually executing. That is why NHI Lifecycle Management Guide is relevant here: identity, credential, and lifecycle state must be tied to the asset record if the inventory is to support governance.
At minimum, AI-BOM data should answer four questions: what is the component, who owns it, what can it access, and how does it change over time. Security teams should connect discovery feeds from cloud, code, CI/CD, and runtime telemetry to policy workflows so that a new agent or connector triggers review before it becomes trusted. This is where Top 10 NHI Issues becomes useful operationally: many failures are not model issues at all, but identity, secrets, or privilege drift issues hidden inside AI tooling.
- Track ownership at the system and component level, not just the application level.
- Link every discovered agent or tool to its credentials, permissions, and approved data sources.
- Reconcile runtime usage against declared inventory so shadow agents and orphaned connectors are visible.
- Require change control for model swaps, endpoint changes, and MCP server additions.
When done well, AI-BOM becomes the evidence layer for access review, incident response, and supplier oversight. These controls tend to break down in fast-moving development environments where agents are spun up by developers, tools are embedded through plugins, and no single system of record owns the full execution path.
Common Variations and Edge Cases
Tighter ai discovery often increases operational overhead, requiring organisations to balance completeness against developer velocity. That tradeoff is real, especially when teams are experimenting with multiple models, vendor-managed copilots, and internal agents that change weekly. Best practice is evolving, and there is no universal standard for this yet, but current guidance suggests that “complete enough for control” matters more than a cosmetically exhaustive inventory.
One common edge case is the externalised model or managed agent where the organisation does not control the runtime but still controls the data path, secrets, and authorisation boundary. Another is the MCP server that looks like a normal integration but can expose broad tool access if it is not separately inventoried and reviewed. A third is the secrets problem: NHIMG research on The State of Secrets in AppSec shows how fragmented secrets practices and slow remediation can undermine central control, which is exactly what happens when AI components are discovered without credential linkage.
Discovery also fails when teams treat “used by AI” as a label rather than a control classification. If the asset record cannot drive review, revocation, or incident investigation, it is not enough for governance. The practical test is simple: if an agent is added, can the organisation prove what it can do, who approved it, and how to disable it quickly?
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Discovery must identify every non-human identity and its ownership. |
| OWASP Agentic AI Top 10 | AIG-03 | Agentic systems require inventory of tools, permissions, and execution paths. |
| CSA MAESTRO | TRUST | MAESTRO stresses trust boundaries and dependencies across agentic workflows. |
| NIST AI RMF | AI RMF GOVERN and MAP functions fit AI-BOM governance and inventory accountability. | |
| NIST CSF 2.0 | ID.AM | Asset management controls align directly to AI-BOM and discovery requirements. |
Build a living NHI inventory with owner, scope, and lifecycle state for every agent and service account.
