Static scans break down because AI workloads load models, embeddings, and connectors at runtime, often after deployment checks have finished. A build-time SBOM may be accurate in CI, yet the running workload can use different components and data paths. Without runtime inventory, security teams miss exposed dependencies, hidden trust paths, and changing attack surface.
Why This Matters for Security Teams
Static scans are still useful, but they only describe what was present at build time. AI workloads often assemble their effective attack surface later, when a model downloads weights, a RAG pipeline reaches into a vector store, or an agent calls a tool endpoint. That means a clean scan can coexist with an unsafe runtime path. Current guidance from NIST AI Risk Management Framework treats this as a lifecycle problem, not a one-time software assurance task.
The practical risk is that defenders mistake a package inventory for a trust inventory. A dependency list can show the libraries shipped in the artifact, yet miss the retrieval service, hosted model endpoint, plugin, secret store, or identity broker the system depends on once it is live. For AI security, that gap matters because data paths are often dynamic and externalised, and small changes can materially change the behaviour of the system. In practice, many security teams encounter hidden AI dependencies only after an incident review reveals that the real runtime graph was never measured intentionally.
How It Works in Practice
Effective coverage requires runtime visibility across the model supply chain, the application layer, and the identities used to connect them. Build-time scanning should remain part of the control set, but it needs to be supplemented with runtime inventory, authenticated service discovery, and policy enforcement at the point of use. The goal is to know not just what was compiled into the workload, but what the workload can actually reach today.
A practical approach usually includes:
- Runtime dependency discovery for models, embedding services, vector databases, and external APIs.
- Verification of artifact provenance and version drift between CI output and deployed components.
- Identity-based access controls for AI services, using workload identity rather than static secrets where possible.
- Monitoring for new tool calls, new retrieval sources, and new outbound network destinations after deployment.
- Validation of model inputs and outputs so that late-bound components do not become silent trust extensions.
For workload identity, the SPIFFE workload identity specification is a strong reference point because it lets systems authenticate workloads dynamically instead of relying on long-lived credentials. That matters for AI stacks where services may be short-lived, autoscaled, or stitched together from multiple providers. Security teams should also compare runtime observations with the build record so that drift is visible when a model version, connector, or hosted inference endpoint changes outside the release process. Best practice is evolving, but the direction is clear: static evidence alone is not enough for AI systems with runtime expansion of trust boundaries. These controls tend to break down in serverless and agentic environments because execution paths are short-lived, remote, and highly dynamic.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance visibility against agility. That tradeoff is especially sharp in AI environments that rely on third-party model hosting, managed retrieval services, or rapid experimentation by data science teams. There is no universal standard for this yet, so teams should distinguish between what is mandatory for production and what is acceptable in research or sandbox environments.
One common edge case is a model that appears self-contained during testing but reaches external data sources after a prompt triggers a tool or retrieval action. Another is a build pipeline that produces an SBOM for the application container while the actual AI logic lives in separately managed model assets and platform plugins. The CISA Secure by Design guidance is relevant here because it reinforces the need to reduce implicit trust and make dependencies explicit. For organisations operating under regulated AI governance, alignment with the EU AI Act resource hub can also help frame accountability for deployed system behaviour, even when the implementation is distributed across multiple services.
Where this approach gets hardest is in multi-tenant platforms, ephemeral agent workflows, and hybrid stacks that mix self-hosted and vendor-managed components. In those environments, the security question is not whether a dependency exists in source control, but whether it is trusted, authenticated, and still approved at the moment the AI workload uses it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF covers lifecycle risk that build-time scans miss at runtime. | |
| OWASP Agentic AI Top 10 | Agentic systems often add tools and paths after deployment checks finish. | |
| MITRE ATLAS | AML.TA0001 | Runtime AI components can be abused through adversarial access and manipulation. |
| NIST CSF 2.0 | DE.CM-8 | Continuous monitoring is needed when assets and trust paths change after build. |
| NIST Zero Trust (SP 800-207) | SA-3 | Dynamic AI services need identity-verified access rather than static trust. |
Assess tool use, prompt flows, and runtime guardrails for newly exposed attack paths.
