Despite all the hype around AI, the majority of companies have not yet begun full-scale production deployment. According to McKinsey, 88 percent of organisations report they use AI regularly in at least one business function. But two-thirds of those companies have yet to begin rolling out AI across the enterprise.
For those of us in security, this moment before enterprise AI proliferation is a significant opportunity to ensure that the right rules and guardrails are in place. If not, then we risk AI implementation outside of our control.
So how can IT security teams get ahead? Enter the AI Bill of Materials, or AIBOM.
What Goes Into an AIBOM?
AIBOMs document all the components that make up the AI infrastructure stack. Keeping this list in one place and updated eliminates the mystery when an audit occurs or an event is being investigated. It also simplifies an organization’s ability to track how its infrastructure changes over time. Security teams already use many similar processes surrounding IT asset management and software vulnerabilities to manage infrastructure with Software Bill of Materials (SBOMs). However, AIBOMs must go deeper by tracking all of the specific assets involved in AI systems.
For example, while some organisations will build and host their own AI models, a majority will use third‑party models through APIs and managed platforms. For security teams, improving visibility into the potential attack surface will depend on where the model resides and a better understanding of trust boundaries and non-physical layers, such as fine-tuning, prompt input, data governance, and API connections.
AI systems also rely on model weights and neural networks, tokenisation of inputs, custom datasets, and training pipelines. All of these assets must be known, and their integrations and evolution should be tracked to be able to properly mitigate security risks. Without a central record of these assets, an AIBOM, it will be challenging and time-consuming to discern the variables involved in any given transaction, the status of that asset or component, and any other security issues that can potentially affect the infrastructure or the results it outputs.
From IT to AI Infrastructure: Same Foundations, New Pressure Points
AIBOMs build directly on pre-existing practices security teams use with SBOMs, asset inventory, and cloud-native security. However, AIBOMs cover a wider range of components since, with AI, there are more layers where things can go wrong. There’s no replacing traditional IT security. It’s just being stretched across wider and sometimes less obvious components, like data pipelines and trust boundaries.
Unlike with traditional applications, components such as model lineage and data provenance are necessary to track performance and response validity, as they evolve and influence model output over time. Additionally, dependency mapping across frameworks, software containers, and other components is needed to provide a comprehensive picture of potential risk in the AI stack. An AIBOM helps security teams understand behaviors and discover connections and changes across a system.
Another element here is container security, as more than half of AI workloads are deployed using software containers. Some specific concerns here for AI deployments are only variations of familiar threats, such as data poisoning, exposed APIs, and overly permissive service accounts. However, since these weaknesses affect a model that directly interacts with users and data, the impact of these known risks is amplified.
Where AI Changes Things
The biggest shift comes from how AI infrastructure operates at runtime. Models respond to prompts and API calls in real time, making them attractive targets for a quick information grab. Alongside the AI technology stack itself, attackers can exploit connected services without traditional vulnerability exploitation to achieve persistence and carry out unauthorised agent actions such as input and output manipulation.
A compromised container running an inference service is not a standard workload breach if it has access to API credentials or fine-tuning datasets. From here, an attacker can attempt to escalate privileges and move laterally across the cluster. With access to model artifacts or datasets, they can exfiltrate data, modify model behavior, or initiate unauthorized actions. The security of trust boundaries matters here.
A trust boundary is an invisible line that defines where data, permissions, and assumptions exist, and there are several of them within an AI infrastructure. Managing security across these gaps requires continuous validation of access, segmentation, and enforcement of the principle of least privilege. An AIBOM documents where these boundaries exist, which components are involved, and how they interact.
For Kubernetes-based AI deployments, Kubernetes role‑based access controls (RBACs), network and pod policies, runtime isolation, and account monitoring can limit the blast radius if applied across workloads, identities, and integrations. An AIBOM is a source of truth that makes it easier to track all of these moving parts and their locations across trust boundaries, so that rules can be continuously and consistently applied.
AI outputs don’t always stop at the response to a user input, either. They may feed downstream pipelines, trigger autonomous actions, or be consumed by other services. Without guardrails and visibility, unvalidated output can propagate errors. Runtime visibility and policy enforcement are essential, especially when AI systems are orchestrated at scale.
There are challenges to be solved in AI security, from unclear model training processes to Model Context Protocol (MCP) servers. However, many of the existing security tools and practices you already trust are ready to secure AI today. The same tried‑and‑true practices – microservice security, input sanitisation, data integrity, authentication, segmentation, and infrastructure controls – continue to be effective when applied to the layers of AI infrastructure. AIBOMs make a consistent security application achievable by indicating what exists, where it is, and how it’s connected.
Implementing Effective Change Management With AIBOMs
Leaders and users alike are excited about the benefits AI stands to bring to their business. However, the sheer volume of enterprise AI projects can make it difficult to concentrate on actually securing those deployments. With so much innovation taking place, security teams can easily find themselves rushing to keep up with new requests or integrations. However, it is important to remember that AI is not a total black box of complexity. Instead, it is a set of cloud‑native components that we already know how to secure.
For teams already using SBOM practices across their software stacks, adding processes for AI specifically is a natural next step. For those who have not yet implemented SBOMs, grappling with the challenge of AI security (and governance) will force their hands when it comes to organising and tracking the tech stack. Additionally as an operational bonus, that long-standing history of what was installed or implemented at a given point and by whom is also helpful for compliance reporting when it comes to AI regulations.
Over time, the expansion of AI implementation and the potential business gains associated with its use will lead to a continued increase in enterprise AI deployments. Tracking and managing those deployments over time will inherently fall to the IT security team. AIBOMs stand to become security teams’ best friend, and they may also encourage greater adoption of the BOM approach for other software.
After all, greater transparency and operational insight are never weaknesses. Improved AI security is a goal that every organization should strive for.
Crystal Morin is a senior cybersecurity strategist at Sysdig. She translates complex security concepts and cutting-edge research into clear, actionable guidance for leaders and practitioners alike, helping organizations defend against modern threats. Previously, Crystal served as a linguist and intelligence analyst in the U.S. Air Force, then joined Booz Allen Hamilton, countering terrorism and cyber threats, where she helped build the firm’s cyber threat intelligence community and threat hunting capabilities. She became a threat research engineer at Sysdig in 2022. Beyond her work at Sysdig, Crystal is passionate about mentorship and community education, building on her mission to make the world a safer place.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.