Part 1 of "Trust the Machine" -> a series on building AI infrastructure that is secure, compliant, and governable by design.
Most organizations can produce an accurate catalog of the web services they operate. Far fewer can produce an equivalent catalog of the AI systems they run — the models, fine-tunes, retrieval pipelines, agents, and third-party AI APIs now embedded throughout their products and internal tooling. This asymmetry defines the state of AI security in 2026.
Adoption has outpaced oversight. Industry reporting this year has described a surge in enterprise AI activity on the order of 83% year over year, with governance and visibility lagging well behind. The consequence is a large and only partially mapped attack surface — one that many organizations cannot fully enumerate, let alone defend.
Every mature security program rests on a single first principle: you cannot protect what you cannot see. Artificial intelligence is no exception. Before threat-modeling an agent or authoring a guardrail, an organization must be able to answer a deceptively difficult question: what AI is running across the environment, and who is accountable for it?
This post examines how to build that answer.
Shadow IT — the unsanctioned adoption of tools outside official channels has been a recognized challenge for decades. Shadow AI is its faster-moving successor, and it appears in more forms than most inventories are designed to detect:
None of these resemble a conventional asset. They lack a hostname, a port, or a record in a configuration management database. Yet each represents a point at which sensitive data may leave the organization, untrusted input may enter, or an action may be taken on the organization's behalf. That risk cannot be reasoned about if the system's existence is unknown.
Traditional inventories catalog things that run: hosts, containers, services, and endpoints. AI systems do not map cleanly onto that model, because the risk-relevant unit is distributed across several artifacts that no single scanner observes together:
A model is not a static binary to be scanned once. It is a behavioral asset whose risk profile depends on all five dimensions simultaneously. An inventory entry noting only "we use model X" conveys little. An entry recording "service Y calls model X with these tools, on this data, exposed to these users" conveys nearly everything that matters.
The software industry addressed a comparable problem with the Software Bill of Materials (SBOM) — a machine-readable manifest of the components in a build. In 2026, its counterpart for AI, the AI-BOM (AI Bill of Materials), is moving from concept to expectation.
An AI-BOM is a structured record of the composition of a given AI system. At minimum, it should capture:
Models — name, version, provenance (self-trained, vendor, open-weights), and license.
Datasets — training and retrieval sources, with associated rights and consent status.
Dependencies — frameworks, inference runtimes, and any third-party AI services invoked.
Capabilities — the tools, functions, and external actions the system can perform.
Owner and purpose — the accountable party, and the function the system serves.
The AI-BOM offers two advantages beyond documentation -
First, it provides the natural unit of an inventory, such as one manifest per system, generated automatically rather than assembled by hand.
Second, it seeds the work that follows in this series: supply-chain verification (Post 2) draws on the model and dependency fields, data governance (Post 3) draws on the dataset fields, and compliance evidence (Post 4) is largely the AI-BOM combined with test results. The artifact is built once and applied across all three disciplines.
An inventory compiled by survey each quarter is outdated by the time it is complete. The objective is a living inventory—one that discovers AI continuously and from multiple vantage points, because no single signal is sufficient on its own.
=> ** Discover from multiple signals**. Self-reporting is necessary but insufficient. Triangulate across independent sources:
Network and egress: outbound traffic to known AI API endpoints reliably indicates embedded model usage.
Code and configuration: repositories and infrastructure-as-code can be scanned for AI SDK imports, model identifiers, and prompt templates
Cloud and billing: AI service spend and GPU allocation surface projects that bypassed review.
SaaS administration: audit which copilots and AI features are enabled across sanctioned platforms.
Identity: enumerate the non-human identities and API keys with access to AI services.
=> ** Normalize into AI-BOMs**. Each discovered system produces a manifest. Generation should be automated wherever possible; a build step that emits an AI-BOM on every deployment is more reliable than a manually maintained page.
=> ** Assign an owner and a purpose to every entry**. An AI system without an accountable owner is a latent incident that cannot be attributed. Purpose is equally consequential: it later determines regulatory risk tiers and internal review requirements.
=> ** Classify by risk**. Not all systems warrant equal scrutiny. A straightforward tiering - does the system handle sensitive data, take autonomous actions, face untrusted input, or drive consequential decisions? directs effort toward the areas of greatest potential impact. Systems scoring high on autonomy and untrusted input are the subject of Post 2.
=> ** Maintain freshness and monitor for drift**. Re-discovery should run on a schedule. Alerts should fire when a new system appears without an owner, when a model version changes, or when a system acquires a new capability. A model substitution or a newly granted tool alters the risk posture and should be treated as the configuration change that it is.
It is tempting to regard this as a tooling exercise. It is not. The most difficult element of an AI inventory is not discovery but accountability. The output that matters is a map in which every AI system has a name, an owner, a purpose, and a risk tier. That single artifact serves three functions at once:
a security control, enabling blast-radius analysis and incident response;
a compliance artifact, evidencing what the organization operates and why; and
a governance primitive, allowing leadership to make decisions about a portfolio it can finally observe.
Three outcomes, one underlying capability. This is the throughline of the series: security, compliance, and governance are not separate programs but three views of the same capability, knowing and controlling what AI systems do with data and actions. That capability begins with visibility.
Coming up
Post 2 -> Agents Gone Rogue: Securing Autonomous AI. With visibility established, the series turns to the highest-risk category of AI system. When a model moves from answering questions to taking actions, the trust boundary shifts inside its reasoning loop and this is where the most significant incidents of 2026 are expected to originate. The next post examines the agentic risk classes and the controls that contain them.
The central point of Post 1 is straightforward: the first AI security control is not a firewall or a guardrail but an accurate, continuously maintained inventory. An organization cannot secure, govern, or certify what it cannot see.