---
title: "You Can’t Govern the AI You Can’t See"
id: "3395"
type: "insight"
slug: "ai-visibility-inventory"
published_at: "2026-08-07T18:15:48+00:00"
modified_at: "2026-08-07T18:15:49+00:00"
url: "https://jetstream.security/insights/ai-visibility-inventory/"
markdown_url: "https://jetstream.security/insights/ai-visibility-inventory.md"
excerpt: "Every AI standard starts with an inventory. Here's how to build the one your governance program depends on."
taxonomy_insight_category:
  - "AI Advisory"
taxonomy_insight_type:
  - "Editorial"
taxonomy_insight_tags:
  - "Agentic AI"
  - "AI Advisory"
  - "AI Risk"
  - "Governance"
  - "Shadow AI"
---

AI Advisory

# You Can’t Govern the AI You Can’t See

Every AI standard starts with an inventory. Here's how to build the one your governance program depends on.

[Agentic AI](https://jetstream.security/insights/insight_tags/agentic-ai/)
[AI Advisory](https://jetstream.security/insights/insight_tags/ai-advisory/)
[AI Risk](https://jetstream.security/insights/insight_tags/ai-risk/)
[Governance](https://jetstream.security/insights/insight_tags/governance/)
[Shadow AI](https://jetstream.security/insights/insight_tags/shadow-ai/)

[Keith Weisman](https://jetstream.security/author-bio/keith-weisman/)
Head of Forward Deployed Engineering

Editorial

*This is installment two of seven in our AI risk management series. [Previously: the standards grade evidence, not policy, and the point of the evidence is trust.](https://jetstream.security/insights/audit-the-evidence-ai-policy/)
 This installment: you cannot produce any evidence for a system you cannot see.*

Before you can govern AI, secure it, or put a number on what it costs, you must answer one foundational question: What AI is running in your environment? I spend a significant amount of my time in the field working with customers, and it’s not uncommon to see organizations unable to provide data around the AI usage question.

In my field experience, written AI policies are far more common than reliable inventories of the AI systems actually in use. That distance between the policy and the inventory is where the risk sits, because a policy with no technical enforcement behind it does not actually govern anything. It only records that you meant to govern.

From an audit standpoint, that’s probably worse than having no policy at all. Writing the policy means you acknowledged the need, and it sets the bar your auditors and your third-party business partners will hold you to. You’ve told them where the line is. Then, with no way to enforce that line or show it held, you are on record against a standard you cannot prove you meet. AI as we know it today hasn’t been around all that long. Its pace puts many enterprises in exactly that spot: They have the policy and nothing underneath it.

##### **The AI risk you may not be seeing**

Your people are already building. But without visibility, you have no idea *how*they’re building. With the best intentions, you don’t know if they are building by sharing potentially sensitive and privileged information with no confidentiality protections. Personally, I love the innovation, but it can be an all-you-can-eat blind spot buffet. A marketing manager automated a reporting pipeline last week. A sales analyst created a lead-scoring tool over the weekend using a non-enterprise AI IDE (Artificial Intelligence Integrated Development Environment). A renewals analyst vibe coded an agent to draft renewal emails via [an MCP server he found on Reddit](https://jetstream.security/insights/jetstream-verified-mcp-governance-layer-for-enterprise-ai-agents/)
. Customer service upgraded the CRM to include the AI-enabled functions.

JetStream assessments commonly find unapproved coding agents and a general-purpose chat assistant nobody logged. Provider credentials, cloud access credentials and model-provider APIs, all residing in the clear on user devices. AI tools active at runtime that were never on the approved list.

Employees are solving real problems with tools that finally let them move at their pace. The consequence is your organization now owns these AI workflows. This forces you to consider the data being processed and how these workflows could impact compliance, data privacy, and security of your organization.

This is the kind of governance gap auditors may identify when policy commitments are not supported by inventory, ownership, monitoring, and evidence. An unidentified AI system can create a material governance gap under NIST AI RMF GOVERN 1.6. If the system qualifies as high-risk under the EU AI Act, failing to identify it may also prevent the organization from applying the risk-management obligations associated with that system.

You don’t want this.

##### **What**it costs

You already understand technical and security debt. AI has its own version, and it compounds the same way, quietly, until an audit or an incident forces you to pay it. It’s why security breaches are commonly considered “the compelling event” that allows teams to finally fund and fix ongoing, longstanding issues.

In the field, we commonly see the following:

- Undocumented prompts, the instructions that shape what a system does, written nowhere anyone can review

- Unmanaged agents, running in production with no one watching the behavior

- Orphaned models and agentic workflows

- Missing ownership: agents and tools with no accountable human ownership

- Hidden API relationships, with one service quietly depending on another; this means the blast radius of a failure is unknown

- Stale risk assessments, written at launch for a system that has changed a dozen times since

- Costly token usage, such as paying for a frontier model when a smaller one would do

##### Every standard starts with the same question

This is not just a JetStream opinion. An inventory is not merely implied by the frameworks; it is written into them.

The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)
 identifies AI-system inventory as an explicit governance outcome under GOVERN 1.6. It calls for mechanisms to inventory AI systems, resourced to the organization’s risk priorities. MAP 1 requires organizations to establish and understand the context of AI systems. In practice, organizations cannot consistently perform that work unless they first know which systems are in scope. You are unable to Measure or Manage a system you never listed.

[ISO/IEC 42001](https://www.iso.org/standard/42001)
 does not prescribe a specific document called an AI inventory. However, organizations need a reliable record of the AI systems and activities within the AIMS scope to define that scope, assess risks, select controls, and produce defensible audit evidence. In my mind, a solid inventory is a reliable record.

For AI systems classified as high-risk under the [EU AI Act](https://artificialintelligenceact.eu/)
, identification is a practical prerequisite to applying the relevant risk-management, data-governance, record-keeping, and post-market-monitoring requirements. The Act does not separately mandate a universal enterprise AI inventory, but organizations need a reliable identification process to determine which systems fall within its requirements. An inventory helps with that too.

Every one of them begins where I do as a practitioner. Let’s define what we’re dealing with, because you cannot govern what you have not inventoried.

Here is what that looks like as an exhibit: the finding types of discovery must surface, the requirement each one answers, and the test that produces it.

##### **Exhibit:** **from discovery finding to standard.**

| What discovery must surface | NIST AI RMF | EU AI Act | ISO/IEC 42001 | JetStream |
| --- | --- | --- | --- | --- |
| Unapproved AI apps in use | GOVERN 1.6 | Art. 9 | A.9.2, A.9.4, A.4.4 | Flags AI apps in use that were never approved |
| Exposed provider credentials that may create cyber weakness | GOVERN 1.6 | Art. 9 (with Art. 15) | A.10.3, A.4.4, A.6.2.6 | Finds provider credentials persisted in clear text |
| AI tools running (especially on high-risk systems) that are off the approved list | GOVERN 1.6 | Art. 9 (with Art. 72) | A.6.2.6, A.9.2, A.4.4 | Surfaces AI tools active at runtime that were never listed |

##### **Why your existing tools are not built for AI nuances**

Here is the uncomfortable part for a mature security program: the controls you already deployed were not built for the AI use case. They were built for a world of devices, users, endpoints, and human identities. AI has redefined each and every one of those constructs.

Your perimeter firewall sees the connections crossing the boundary, so it can tell you someone reached a known AI service. It cannot see the local client installed on a laptop, or the production credential sitting in a file on someone’s workstation.

Your Endpoint Detection and Response (EDR) tooling can search for an application’s inventory by keyword or file hash, which is genuinely useful, but AI moves faster than anyone can maintain those search criteria, and some of what you need lives inside configuration files.

Finding an MCP configuration requires reading the contents of a JSON file (purposeful file inspection), not simply matching a file hash.

##### **What visibility takes (today)**

The answer to this problem is a purpose-built AI governance system that accounts for the nuances of AI deployments.

It is continuous, because the environment changes between snapshots. An inventory that is current in April is probably outdated by June. It is comprehensive, reaching the endpoint, the cloud, the browser, the API, and the agent and MCP integration points, not just the models you already knew about.

It is frictionless enough that it gets executed. The benefit must exceed the lift of execution and analysis. It produces a living inventory in which every tool, identity, and workflow is attributed to a named owner. “We found it” is only half of what an auditor is really asking. The other half is “who is responsible for it?”

##### **Citizen developers**

[Citizen developers](https://jetstream.security/insights/citizen-developer-employees-risk/)
 are increasing in numbers because employees are experimenting with ways to fix job friction and suboptimal processes. I love the innovation I see all around as creative professionals announce with glee they’ve created a better way to solve some issue that’s been dogging them forever. Some of this work is blessed by corporate; some of it isn’t and is technically shadow AI.

JetStream’s position is that governance is the accelerator, not the brake. We are simply saying that with a few well-placed AI-native controls, knowledge workers can innovate and flourish to the benefit of everyone.

AI Inventories are the foundation. Start with visibility, not because it is the exciting part. It is the foundation of your future decisions and go-forward plan. Every control you design and every attestation you sign is built on the inventory. Right now, organizations are making critical decisions based on a hypothesis. The ones that will govern AI well are simply the ones who decided to look first. In this new age, AI usage brings a competitive advantage. Those that embrace it responsibly will gain a distinct advantage.

*Next installment: seeing a system is not the same as knowing what it is supposed to be. Next, turning a discovered system into one you can approve.*

## Stay ahead with our newsletter

Stay informed on industry trends, expert analysis, and product updates.

#### Explore more insights

[See all Insights](/insights)

[https://jetstream.security/insights/mcp-vs-skills/](https://jetstream.security/insights/mcp-vs-skills/)
Aug 18, 2026

###### MCP vs. Skills: A False Debate

MCP gives an agent its tools and Skills give it the instructions. The teams winning with Claude run both, and governance is what keeps the pairing safe.

[https://jetstream.security/insights/mcp-vs-skills/](https://jetstream.security/insights/mcp-vs-skills/)

[https://jetstream.security/insights/a-policy-is-not-a-control/](https://jetstream.security/insights/a-policy-is-not-a-control/)
Aug 14, 2026

###### A Policy Is Not a Control

Approval happens in a moment, but the system keeps moving. Design control is the artifact that makes every AI change visible and every deviation provable, which…

[https://jetstream.security/insights/a-policy-is-not-a-control/](https://jetstream.security/insights/a-policy-is-not-a-control/)

[https://jetstream.security/insights/leaked-api-key-what-to-do/](https://jetstream.security/insights/leaked-api-key-what-to-do/)
Aug 11, 2026

###### Burt has a key problem. Make sure that you don't.

One leaked API key shouldn't be able to stop your business. With a virtual key, it can't.

[https://jetstream.security/insights/leaked-api-key-what-to-do/](https://jetstream.security/insights/leaked-api-key-what-to-do/)

## Top Articles

01

Press Release

### [JetStream Security Achieves FedRAMP Class D (High) Certification Through Second Front](https://jetstream.security/insights/jetstream-security-fedramp-high-certification/)

July 22, 2026

02

Press Release

### [JetStream Releases ‘AI Kill Switch’ to Shut Down Individual Agents](https://jetstream.security/insights/jetstream-ai-kill-switch-agents/)

July 27, 2026

03

Press Release

### [JetStream Announces Verified MCP Governance Layer for Enterprise AI Agents](https://jetstream.security/insights/jetstream-verified-mcp-governance-layer-for-enterprise-ai-agents/)

July 13, 2026

## Featured Experts

[https://jetstream.security/author-bio/patrick-zeller/](https://jetstream.security/author-bio/patrick-zeller/)

### [Patrick E. Zeller](https://jetstream.security/author-bio/patrick-zeller/)

General Counsel, Legal and Compliance

Patrick has spent over twenty years advising Fortune 100 companies on privacy, cybersecurity, and data protection — including...

[https://jetstream.security/author-bio/keith-weisman/](https://jetstream.security/author-bio/keith-weisman/)

### [Keith Weisman](https://jetstream.security/author-bio/keith-weisman/)

Head of Forward Deployed Engineering

Keith brings thirty years of hands-on cybersecurity and services leadership, beginning with enterprise security consulting at Accenture and...

[https://jetstream.security/author-bio/tommy-hui/](https://jetstream.security/author-bio/tommy-hui/)

### [Tommy Hui](https://jetstream.security/author-bio/tommy-hui/)

Head of Sales Engineering

Tommy Hui has spent more than a decade leading sales engineering at security companies, including six years at...
