Discover Before You Govern

Executive summary

Most organizations are trying to govern AI with a partial map. They know there are copilots, agent SDKs, local models, browser extensions, IDE plugins, internal prototypes, and third-party connectors somewhere in the environment. They usually do not know exactly where, how many, or which ones are already approaching production. That is a governance gap before policy even begins. You cannot govern what you cannot see. This is why discovery must come first. Before an enterprise can enforce runtime controls, define approval boundaries, or produce clean audit evidence, it needs a credible inventory of agentic surfaces:

• custom agents
• orchestration frameworks and SDKs
• MCP servers
• coding and CLI agents
• local model runtimes
• shadow-AI signals and provider-key sprawl
• projects with and without governance coverage

This paper explains why AI discovery is the front door to runtime governance, why conventional asset inventories are not enough, and what separates an evidence-based inventory — with honestly reported limits — from generic "AI visibility" marketing.

The problem: the inventory lags the estate

Most enterprises have some form of asset inventory. Far fewer have a reliable AI-runtime inventory, because the environment changes faster than any register:

• teams add agent frameworks to active repos
• developers run local models on workstations
• MCP servers appear in editor and desktop client configs
• coding agents gain filesystem and tool reach
• provider keys spread through env files, shells, and extensions
• AI features arrive inside existing products before governance teams notice

By the time a formal governance initiative starts, the estate is typically larger and messier than leadership expects. That is why policy-first AI governance often stalls. Teams are trying to answer:

• what should be governed?
• which systems matter most?
• where are the highest-risk gaps?
• which projects already have coverage?

without a reliable inventory layer underneath the questions.

Why traditional asset management is not enough

Generic endpoint and SaaS inventories answer the wrong questions for AI governance. They may reveal:

• installed software
• devices
• cloud resources
• named applications

They usually do not reveal:

• which code projects are building agents
• which retrievers and tool routers are present
• which MCP servers are configured
• which local model runtimes are active
• which coding agents are installed
• which projects already carry a governance harness

That last item is the one leadership actually needs: not just what exists, but what is already inside the control boundary.

The right model: inventory agentic reality before writing policy

A credible AI governance program begins with operational reality, not abstract policy language. The first questions are:

• what is actually running?
• where are the developer and endpoint entry points?
• which projects contain agent frameworks?
• which hosts show shadow-AI signals?
• where is governance already attached, and where is it absent?

Once those questions are answered from evidence, the governance program becomes a sequence instead of an argument.

How discovery works — and how it behaves

Discovery runs as a lightweight, deliberately constrained sensor:

1. The sensor runs on a host or fleet segment and scans for defined agentic signals — frameworks in projects, MCP configurations, local model runtimes, coding and CLI agents, and surrounding risk indicators.
2. Findings are normalized into a structured inventory.
3. Governance coverage is reported per project, not only per machine — so the inventory distinguishes an instrumented agent from an ungoverned one on the same host.
4. Rollout decisions are made from that evidence.

The sensor's conduct is part of the design, not a footnote:

• it is read-only — it observes; it does not modify projects or invoke package managers
• secret-shaped findings are fingerprinted, never collected in plaintext
• project detection is bounded and explicit about what it reads
• degraded or incomplete scans are surfaced as such, never silently folded into "no findings"

One deliberate caution on key findings: a fingerprinted key-shaped value is evidence that a credential-shaped string exists in a scanned location. It is not, by itself, proof that the key is active, valid, or tied to a specific agent. The inventory reports it as a signal to investigate — which is what an honest inventory should do.

What a credible inventory includes

Agent frameworks — identifies where real agentic behavior is being built, not just where a model API is mentioned. MCP servers — tool access is where model risk becomes operational risk. Local model runtimes — local models create execution surfaces outside central platform assumptions. Coding and CLI agents — developer-side agents increasingly touch code, tools, and environment state. Shadow-AI signals — unmanaged keys, extensions, and helper tooling reveal governance gaps quickly. Project-level governance coverage — the difference between a list of findings and a governance instrument. An illustrative inventory record:

"No findings" is not "nothing there" The most important trust signal in any discovery product is honest coverage reporting. "No findings" is meaningless if the system could not see clearly. Serious buyers want to know:

• what was checked
• what could not be checked
• which signals were partial or degraded
• whether a clean result reflects true absence or a visibility limit

A practical way to hold that line is a coverage status carried on every surface in the inventory:

Status Meaning

Governed Instrumented and inside the control boundary — decisions are enforced and evidenced

Observed Visible to discovery, characterized, not yet instrumented

Not visible from here Outside this sensor's scope — covered by other means, or an acknowledged gap That third row matters most. No runtime sensor sees everything: an agent on a host with no sensor, or activity inside a third-party SaaS assistant that exposes only after-the-fact logs, is out of scope for host-based discovery and should be governed by other means — procurement policy, network controls, SaaS audit APIs. An inventory that says so plainly is worth more to a security team than a longer list with silent blind spots. Auditors agree.

Practical enterprise scenarios

Scenario 1: Security team preparing an AI governance rollout

Discovery reveals multiple orchestration frameworks in active repos, local model runtimes on engineering endpoints, several MCP configurations — and that only a subset of projects is already instrumented for governance. Outcome: the team sequences rollout around real exposure instead of arguing in the abstract.

Scenario 2: Regulated enterprise with shadow-AI concerns

Discovery reveals provider-key sprawl, AI IDE plugins, internal code projects with agent SDKs, and unmanaged local runtimes. Outcome: security targets actual hotspots instead of issuing generic warnings.

Scenario 3: Platform team proving coverage progress

Discovery reveals which projects carry the governance harness, which teams are still building outside the boundary, and where coverage is thin by host, group, or business unit. Outcome: governance becomes measurable — and easier to fund.

Discovery as the first phase of governance rollout

Phase 1: Discover

Inventory agentic surfaces, identify unmanaged high-risk zones, establish the coverage baseline.

Phase 2: Prioritize

Rank projects and hosts by business impact and execution reach; decide where runtime governance attaches first.

Phase 3: Govern

Apply retrieval, action, and approval controls where the inventory justifies them. Because discovery and governance share one platform, "we found it" to "it's governed" does not require a second deployment — an instrumented agent self-registers on first contact and starts in observation mode, and coverage grows from its own observed traffic.

Phase 4: Measure

Rerun discovery to prove coverage expansion and gap reduction over time — governed, observed, and not-visible, per business unit, trending the right direction.

Conclusion

AI governance cannot begin with policy alone, because policy has nothing solid to attach to without inventory. Discovery is the evidence layer that makes governance rollout practical — provided it reports its own limits as honestly as its findings. The goal is not the longest list. It is an inventory where every entry carries a coverage status, and where the path from observed to governed is a rollout step, not a new project. Learn more at visiqlabs.com · Technical documentation at docs.visiqlabs.com