AI governance starts with inventory, not policy

At a glance

What this is: This whitepaper argues that AI governance should begin with discovery because organisations cannot apply runtime controls, approval boundaries, or audit evidence to an inventory they do not yet have.

Why it matters: For IAM, NHI, and AI governance teams, the key issue is establishing a trustworthy control boundary around agentic surfaces, developer tooling, and hidden access paths before policy and enforcement can be made meaningful.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, making organisations failing to scope AI access properly 4.5x more likely to experience a security incident.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.

👉 Read Visiq Labs' whitepaper on discovering AI before you govern it

Context

AI governance fails when organisations try to write policy before they can see the actual estate. In practice, agent frameworks, MCP servers, local runtimes, coding agents, and provider keys often spread faster than inventory processes can keep up, leaving governance teams with a partial map and an incomplete control boundary.

A credible discovery layer changes the question from "what policy should we adopt?" to "what is actually running, where is it running, and which projects are already governed?" That matters directly to NHI, IAM, and agentic AI programmes because every unmanaged agentic surface creates a new access and oversight problem, not just a visibility problem.

This is a typical failure mode for mature enterprises with active development environments, not an edge case. The gap appears because conventional asset management was built for software and infrastructure inventory, not for runtime agent surfaces, shadow AI, or identity-rich toolchains.

Key questions

Q: What breaks when AI governance starts with policy instead of inventory?

A: Policy-first programmes usually stall because teams cannot define scope, boundaries, or ownership with confidence. Without a credible inventory of agentic surfaces, controls are aimed at an incomplete estate, audit evidence is partial, and hidden access paths remain outside governance. The result is formal policy with weak operational reach.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: How do you know if AI discovery is actually working?

A: AI discovery is working when the organisation can produce one authoritative inventory, classify tools consistently, and explain which data and permissions each tool can reach. If the team still has to switch between dashboards or cannot map runtime usage back to policy, discovery is incomplete even if coverage looks broad.

Q: Who is accountable when an AI agent acts outside its intended scope?

A: The organisation is accountable, but operational responsibility should sit with a named owner and a governance process that can explain the agent’s purpose, access, and recorded actions. Without that, autonomous behaviour becomes unassignable risk rather than managed automation.

Technical breakdown

Why conventional asset inventories miss agentic surfaces

Traditional asset inventories are built to track devices, applications, and cloud resources. AI governance needs something narrower and more operational: evidence of agent frameworks, retrievers, tool routers, local model runtimes, CLI and coding agents, and MCP configurations. Those elements are not just software labels. They define where the model can act, what it can reach, and how far a mistake or misuse can propagate. Without that context, an inventory may show the application but miss the execution surface that creates risk.

Practical implication: treat AI discovery as runtime surface mapping, not software cataloguing.

What makes an evidence-based inventory credible

A credible inventory distinguishes observation from control. It records what was seen, what was not visible, and whether a project is already instrumented for governance. That means a read-only sensor, explicit coverage status, and normalised findings that can be attached to a project rather than merely a host. The most useful result is not a list of findings but a map of governed, observed, and not-visible surfaces. Honest blind spots are a control feature, not a weakness, because they prevent false assurance.

Practical implication: require coverage status on every surface so a clean result cannot be mistaken for full control.

Why project-level governance matters more than device-level counts

AI risk often appears inside a project, not on an endpoint in isolation. One machine can host both governed and ungoverned agentic work, so counting devices alone misses whether the risky workflow is actually inside the control boundary. Project-level governance shows where a harness exists, where it is missing, and which teams are building outside policy. That is the difference between seeing activity and being able to govern it. For agentic AI, governance without project context is usually an incomplete answer.

Practical implication: measure coverage by project and workflow, not by machine count alone.

Threat narrative

Attacker objective: The objective is to exploit unmanaged agentic surfaces and hidden credentials to gain operational reach before governance can detect or constrain them.

1. Entry begins when agent frameworks, MCP servers, browser extensions, or provider keys appear faster than governance teams can inventory them.
2. Escalation occurs when those surfaces gain filesystem, tool, or API reach without a verified control boundary.
3. Impact follows when unmanaged agentic access expands the organisation's attack surface, creates blind spots in audit evidence, and leaves sensitive workflows outside governance.

NHI Mgmt Group analysis

Inventory is now a governance control, not an administrative task. AI governance programmes fail when discovery is treated as a preamble instead of the control layer that determines what can be governed at all. In agentic environments, the inventory is part of the control plane because it establishes scope, ownership, and coverage status. Practitioners should treat incomplete discovery as an active governance deficiency, not a documentation issue.

Agentic AI creates a visibility gap that traditional IAM and asset tooling were never designed to close. Standard inventories answer what is installed, but not what can act, what can route tools, or what can access sensitive runtime state. That is a distinct category of governance debt. The field needs to recognise that the identity of the system, not just the software package, has become relevant to control design.

Coverage honesty is the real differentiator in AI discovery. The strongest inventory is not the one with the longest list, but the one that can distinguish governed, observed, and not-visible surfaces without ambiguity. That framing aligns discovery to NIST AI Risk Management Framework governance and measurement expectations, while also supporting better identity lifecycle decisions for keys, agents, and tool access. Practitioners should reject any discovery result that hides its blind spots.

Project-level governance is the named concept this market needs to standardise. A project can be governed even when the host is only partially observed, and a host can look clean while the risky workflow remains outside the control boundary. This is the point where AI governance, NHI governance, and developer access management converge. Teams should build around project-level coverage as the unit of trust.

This discovery pattern validates the shift from static inventories to lifecycle-aware governance. AI agents, provider keys, and MCP configurations change too quickly for annual review models to remain meaningful. The practical takeaway is that inventory must feed rotation, approval, and offboarding decisions continuously, especially where tools can create new access paths without human review.

What this signals

A useful AI governance programme now needs discovery, inventory, and lifecycle control to operate as one chain. If teams cannot identify where agents, keys, and MCP configurations exist, they cannot claim reliable enforcement, and that gap will show up first in auditability and later in incident response.

Project-level coverage debt: the practical risk is not just that AI exists, but that some projects are already inside governance while adjacent ones are still invisible. That split will drive uneven control maturity across engineering, infrastructure, and security teams, so the next step is to align inventory with identity lifecycle and access review workflows.

Discovery also changes how practitioners should use external guidance such as the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026. Those references matter most when they are translated into measurable coverage states, not treated as policy language.

For practitioners

• Establish a project-level AI inventory baseline Map agent frameworks, MCP servers, local runtimes, coding agents, and provider-key sprawl by project so governance coverage is visible at the workflow level.
• Classify every surface as governed, observed, or not visible Use explicit coverage states to prevent clean scans from being mistaken for full control and to drive follow-up on blind spots.
• Treat provider keys and tool credentials as lifecycle assets Track where keys appear in env files, shells, extensions, and repos, then connect discovery to rotation and revocation workflows.
• Prioritise write-capable agentic projects first Roll out governance to the projects with filesystem, tool, or API reach before lower-risk observation-only surfaces.

Key takeaways

• AI governance fails early when organisations try to enforce policy before they have a credible inventory of agentic surfaces.
• The most useful discovery output is not a long asset list, but a coverage model that distinguishes governed, observed, and not-visible systems.
• Identity teams should treat AI discovery as the foundation for access control, lifecycle management, and audit evidence across agentic workflows.

Key terms

• Agentic Surface: The agentic surface is the set of connections, permissions, and actions available to an AI system that can initiate work, call tools, or trigger downstream processes. For governance, it is the point where a model stops being a text engine and starts becoming an access actor.
• Coverage Status: Coverage status describes whether a surface is governed, merely observed, or not visible to the discovery process. It turns an inventory into a control instrument by showing where security can enforce policy and where it still lacks line of sight.
• Project-Level Governance: Project-level governance is the practice of attaching security controls, evidence, and ownership to a specific AI workflow rather than only to a machine or application. It matters because the same host can contain both controlled and uncontrolled agentic activity.
• 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.

What's in the full article

Visiq Labs' full whitepaper covers the operational detail this post intentionally leaves for the source:

• How the discovery sensor identifies frameworks, MCP configurations, local model runtimes, and shadow-AI signals across hosts and projects
• How coverage states are assigned so teams can distinguish governed, observed, and not-visible surfaces
• How the rollout sequence moves from discovery to prioritisation and then to runtime governance without starting a separate project
• How read-only scanning and secret fingerprinting are handled to avoid collecting plaintext credentials

👉 Visiq Labs' full whitepaper covers the discovery model, coverage states, and rollout sequence in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps practitioners connect discovery, control boundaries, and lifecycle management across identity programmes.