Transitive AI Is The New Shadow Cloud

Turns recent AI cloud and engineering reports into a concrete operator framework for finding transitive AI exposure before agents become production dependencies.

The next AI governance problem will not start with a team buying a model API. It will start with a dependency, IDE extension, internal agent, MCP server, managed cloud feature, or vendor tool that quietly gives AI access to code, data, credentials, or workflow state.

The thesis: operators need to inventory AI as infrastructure they may inherit, not just software they intentionally deploy.

Why This Matters Now

Recent data points all point in the same direction. Wiz's 2026 cloud report says AI is now embedded across cloud environments and development workflows, with managed AI services, self-hosted models, AI IDE extensions, agents, and MCP servers showing up at high rates in observed environments. Datadog's 2026 engineering report says multi-model production stacks are common, agent framework adoption doubled year over year, and production AI requests are already failing from operational causes such as capacity limits.

At the same time, frontier models are becoming more capable at tool-heavy work. OpenAI's GPT-5.5 release frames the model around agentic coding, computer use, research, documents, spreadsheets, and software operation across tools. That is useful. It also changes the risk model.

An assistant that drafts text is an app. An agent that can inspect repositories, call tools, route between models, read business data, or trigger actions is infrastructure.

The Transitive AI Problem

Shadow AI used to mean employees using unsanctioned chatbots. That is too small now.

The more important category is transitive AI: model, agent, runtime, or tool exposure inherited through another system.

A product team may not think it runs self-hosted models, but a vendor package might. A security team may not have approved an agent platform, but an engineering group might have installed an IDE extension that can read source code. A platform team may not expose a model directly, but an MCP server might connect a model to ticketing, databases, cloud metadata, or file systems.

The danger is not only breach risk. It is operational blindness. Teams cannot govern prompts they do not know exist, meter requests they do not see, route failures they cannot trace, or constrain tools they never inventoried.

The Operator Framework

Treat AI inventory as a four-layer map.

First, model access. List every managed model, self-hosted model, API provider, embedded model, and model gateway. Include the vendor software that brings a model along indirectly.

Second, tool access. List every agent framework, MCP server, browser automation layer, code execution tool, IDE extension, workflow bot, and connector. For each one, record what it can read, write, execute, and call.

Third, identity and permission. Tie every AI surface to service accounts, user tokens, cloud roles, repository permissions, secrets, network access, and approval rules. If an agent can act, it needs an identity boundary.

Fourth, runtime evidence. Capture traces, model choice, tool calls, retries, failures, capacity errors, prompt-cache behavior, and human approvals. Datadog's production-failure data is a reminder that AI systems fail like distributed systems, not like static documents.

This map should be owned by platform, security, and application teams together. If it lives only in an innovation team, it will miss the places AI actually enters the stack.

What Builders Should Do This Week

Start with a dependency scan, not a policy memo. Search repositories, cloud accounts, package manifests, IDE policy, and vendor contracts for model providers, agent frameworks, MCP servers, code execution tools, and AI-enabled developer extensions.

Then classify every surface by capability: read-only, write-capable, execution-capable, transaction-capable, or externally exposed. The jump from read to write is the moment governance changes.

Next, create two budgets. One is a reliability budget: acceptable failure rate, retry policy, fallback path, latency ceiling, and capacity alerting. The other is a permission budget: which data, tools, accounts, and networks an agent can reach before a human reviews the action.

Finally, make AI inventory part of normal change management. New MCP server? Review it like an internal API. New IDE extension? Review it like source-code access. New model route? Review it like production infrastructure. New agent with tools? Review it like automation that can make changes.

The Takeaway

The companies that move fastest with agents will not be the ones with the most experimental demos. They will be the ones that know where AI already exists, what it can touch, who owns it, how it fails, and what evidence it leaves behind.

Transitive AI is not a reason to slow down. It is a reason to make the invisible stack visible before autonomy turns it into a production dependency.