Google Cloud now spans AI Protection, Model Armor, Agent Engine, and SBOM tooling; this deep dive shows how to turn that into AI-BOM governance. Read now.
What AI-BOM governance means for Shadow AI
Shadow AI is any model, agent, or prompt pipeline that runs outside a controlled inventory: a team’s private notebook calling a hosted model, a chatbot wired into a ticket system, or an internal tool that quietly embeds third-party weights. An AI Bill of Materials (AI-BOM) is the inventory and provenance record for that stack—models, agents, datasets, prompts, guardrails, and the services that host them. On Google Cloud, the pieces needed to build that inventory already exist as separate products. The work is to treat AI Protection, Model Armor, Agent Engine, and SBOM tooling as one governance loop instead of four disconnected security features.
Governance here is operational, not ceremonial. You need a single place that answers: what models are running, who owns them, what they can touch, how they are filtered, and whether their software supply chain is known. Without that, shadow AI stays invisible until something fails—data leaves a project, an agent takes an unsafe action, or a dependency changes without review.
Map Google Cloud controls onto the AI-BOM
Start by assigning each control a role in the bill of materials rather than a product checklist. AI Protection is the policy and detection layer for AI workloads: what is allowed, what is monitored, and how findings surface for review. Model Armor sits closer to the model boundary—sanitizing inputs and outputs so prompts and responses do not become an untracked channel for secrets or policy bypass. Agent Engine is where multi-step agents are defined, run, and observed; every agent runtime, tool binding, and identity should appear as a first-class AI-BOM entry. SBOM tooling covers the traditional software lineage of services, libraries, and containers that wrap models and agents so the “AI” layer is not orphaned from the rest of the supply chain.
- AI Protection — policies, detection, and ownership of AI assets in the inventory.
- Model Armor — input/output controls recorded as protective controls on each model endpoint.
- Agent Engine — agent definitions, tools, identities, and runtime environments as BOM nodes.
- SBOM tooling — package and image lineage for the services that host or call models.
The AI-BOM itself can live as structured metadata next to your existing asset inventory: model name and provider, endpoint or project, data classes it may process, guardrail profile, agent tools, and links to the relevant SBOM for the deployment. Prefer fields you can refresh from APIs and pipeline outputs over one-off spreadsheets that go stale.
A practical governance loop for teams
Build the loop around intake, enforcement, and review. On intake, any new model call, agent, or AI-backed service must declare an owner, purpose, and data scope before it is promoted beyond a sandbox. Wire Model Armor profiles and AI Protection policies to that declaration so the same record that lists the asset also lists how it is protected. For agents in Agent Engine, require tool allowlists and identity scopes in the same record; an agent without documented tools is incomplete inventory, not a finished product.
On a fixed cadence, reconcile runtime reality with the BOM. Compare active endpoints, agent deployments, and SBOM artifacts against registered entries. Treat unexplained traffic or undeclared agents as shadow AI tickets, not optional cleanup. When something drifts—new tool added, model swapped, filter disabled—update the BOM in the same change as the code or config, and block promotion if the inventory and the deployment disagree.
What “good” looks like without boiling the ocean
You do not need perfect coverage on day one. Start with production and near-production surfaces: customer-facing agents, jobs that touch regulated or sensitive data, and any model endpoint reachable outside a single team. Record minimum viable fields for each asset, attach Model Armor and AI Protection settings as control evidence, link Agent Engine agents to owners and tools, and attach SBOMs for the wrapping services. Expand the inventory as new patterns appear rather than inventing a massive schema no one maintains.
Success is simple to check: a security or platform engineer can name every active AI surface on Google Cloud in the inventory, see how each is protected, and open an incident when something runs that is not listed. That is AI-BOM governance applied to Shadow AI—Google Cloud’s AI Protection, Model Armor, Agent Engine, and SBOM tooling used as one system of record, not four product logos on a slide.