AI inventories are the control layer governance depends on

At a glance

What this is: JetStream Security says AI governance starts with inventory, because policies, risk controls, and audit evidence fail when organisations cannot see which AI systems, agents, and integrations are actually running.

Why it matters: For IAM, NHI, and AI governance teams, the message is that unidentified AI workflows create ownership, access, and evidence gaps that cannot be closed after the fact.

Context

AI governance begins with discovery, not policy wording. If you cannot identify what AI is running, who owns it, and what data it touches, you cannot apply meaningful controls or produce defensible evidence. The inventory problem is especially acute where AI tools are installed locally, hidden in browser workflows, or embedded in agent and MCP integrations.

This article treats visibility as the governance boundary, because the same blind spot that hides unmanaged AI also hides unmanaged identities, credentials, and runtime dependencies. That makes inventory relevant not only to AI assurance, but to the broader control problem of NHI lifecycle management when machine-like workflows depend on credentials and external services.

Key questions

Q: How should organisations govern AI systems that can make consequential decisions?

A: Organisations should govern consequential AI systems with the same discipline used for high-risk identities: defined ownership, least privilege, logging, approval boundaries, and human override. The critical requirement is to connect model behaviour to real access paths so legal review, security review, and audit evidence all describe the same system.

Q: Why do agentic AI workflows create risk when business context and guardrails are missing?

A: Without business context and guardrails, an AI agent can answer confidently while pulling from the wrong source, making inconsistent decisions, or taking actions that create new risk. In governance and identity workflows, that matters because a plausible answer is not the same as a trusted one. Context, scope, and approval boundaries are what keep automation aligned to policy.

Q: What signals show that an AI governance programme is not working?

A: Warning signs include disconnected models built by different teams, repeated disputes over data ownership, inconsistent approvals and outputs that cannot be explained to stakeholders. If the organisation cannot trace which data supported a decision or who approved the model, governance is already failing at the operating level.

Q: How do AI inventories differ from ordinary software asset inventories?

A: AI inventories must capture runtime behaviour, data use, ownership, and external dependencies, not just installed software. A static asset list may show that a tool exists, but it will not show whether the tool is making decisions, calling external models, or using sensitive credentials. That is why AI inventory needs operational context, not just catalogue accuracy.

Technical breakdown

Why policy does not equal governance without an AI inventory

An AI policy sets intent, but governance requires proof that the intended controls exist in practice. In AI environments, that proof depends on discovery across endpoints, cloud services, browser activity, APIs, and agent integrations. Without an inventory, organisations cannot know whether a system is approved, whether it is in scope for risk treatment, or whether the evidence they present to auditors reflects actual use. The gap is not administrative. It is operational, because control design depends on knowing what exists before deciding how to govern it. Read the Ultimate Guide to NHIs: Key Challenges and Risks.

Practical implication: Treat inventory as the first control input, not the last reporting artifact.

How shadow AI and unmanaged agents create hidden governance exposure

Shadow AI is not only an application discovery issue. It is a governance problem created when employees deploy tools, prompts, models, or agents outside approved workflows. Once these systems begin processing business data or calling external services, they create ownership, privacy, and security obligations that no one has formally accepted. The same applies when agents run with persisted credentials or hidden dependencies, because the organisation inherits the operational risk even if it never sanctioned the workflow. Discovery must therefore include the tool, its runtime context, and the human or team responsible for it. Read Top 10 NHI Issues.

Practical implication: Inventory every AI workflow with a named owner, runtime location, and data path.

Why AI inventories must include credentials and hidden dependencies

A useful AI inventory is not just a catalogue of model names. It must surface the credentials, APIs, and service relationships that make the workflow work, because those are the points where misuse and lateral impact appear. If an AI tool is using cloud access keys, model-provider tokens, or unseen MCP connections, the inventory must record those dependencies as part of the system boundary. This is where AI governance intersects with NHI governance: untracked credentials and hidden service relationships turn an otherwise visible workflow into an ungoverned one.

Practical implication: Map each AI system to the identities and secrets it consumes before you assign control owners.

NHI Mgmt Group analysis

AI inventory debt is now a governance failure, not a documentation gap. When organisations cannot enumerate the systems already in use, every downstream control becomes speculative. Policies, attestations, and risk statements all depend on a defensible inventory, so the absence of one means governance is being asserted rather than executed. Practitioners should treat discovery as the base layer of AI control design.

<> is becoming the boundary between approved AI and shadow AI. The important question is no longer whether employees are using AI, but whether the organisation can distinguish sanctioned systems from unmanaged ones at runtime. That distinction determines whether a workflow is inside the governance model or outside it, which makes discovery a control problem, not a reporting exercise. Practitioners should align inventory scope to runtime reality, not procurement records.

AI governance and NHI governance are converging around the same hidden-risk pattern. Once AI systems rely on cloud credentials, API keys, or agent integrations, the problem looks less like model oversight and more like machine identity sprawl. Visibility has to cover the workflow, the credential, and the dependency chain, otherwise the control boundary is fictional. Practitioners should inventory AI systems as credential-bearing services, not as isolated software features.

Detection without context is not governance. Finding a model name or a file hash tells you little if you cannot answer who owns the workflow, what data it processes, and which external services it invokes. That is why inventory needs to be continuous, not episodic, and tied to ownership and evidence. Practitioners should use visibility to establish accountability, then use accountability to drive risk treatment.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Inventory is the control plane for AI governance. Once AI tools can appear through browser use, local installs, API calls, or agent integrations, the old assumption that procurement records describe reality no longer holds. Organisations need a living inventory that can be updated as fast as the environment changes, because stale records create stale assurance.

Machine identity and AI governance are now overlapping disciplines. The moment an AI workflow depends on credentials, tokens, or service-to-service connections, the inventory must track identity-bearing components as part of the control boundary. That is why visibility programmes increasingly need to cover the same hidden dependencies that matter in NHI governance, not just the model layer.

Visibility gaps become control gaps before they become incidents. If an organisation cannot answer who owns an AI workflow, what it touches, and whether it is approved, every later assurance step is weakened. Continuous discovery and ownership mapping should therefore be treated as programme prerequisites, not optional hardening.

For practitioners

• Build a continuous AI inventory Discover AI apps, agents, local tools, and API-based workflows across endpoint, cloud, browser, and integration layers, then keep the record current as usage changes.
• Assign a named owner to every AI workflow Record business ownership, technical ownership, and the data or system each workflow touches so unmanaged tools cannot hide behind shared responsibility.
• Map credentials and dependencies before approving use Document provider keys, cloud access credentials, model APIs, and MCP-style integrations as part of the system boundary, not as separate exceptions.
• Reconcile policy claims against runtime evidence Compare written AI policy, approved inventory, and observed runtime activity to identify systems that are in use but not governed.

Key takeaways

• AI governance starts with knowing what exists, not with writing a stronger policy.
• Hidden AI workflows create ownership, access, and evidence problems that standard control reviews will miss.
• Continuous discovery is the difference between managed AI use and shadow AI operating outside the governance model.

Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Top 10 NHI Issues · Ultimate Guide to NHIs: Key Challenges and Risks

Key terms

• AI Inventory: An AI inventory is a governed record of all AI-related assets, enriched with owner, purpose, access, and risk context. It turns discovery into something security, compliance, and IAM teams can use to make approval, review, and revocation decisions.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management, giving practitioners a structured baseline for identity-aware control design. It is suited to teams that need to connect governance, access, and evidence across human and non-human systems.