TL;DR: Most organisations have adopted AI, but only a small minority have the visibility and governance depth to control it, and Xygeni’s analysis shows the gap is widening as agentic AI and MCP-based access spread across enterprise workflows. The real issue is not model capability, but continuous oversight of access, behaviour, and auditability before governance debt becomes an operational failure.
NHIMG editorial — based on content published by Xygeni: AI governance is failing at visibility, access, and continuous oversight
By the numbers:
- 88% of organizations are actively using AI across business functions, but only 8% have a comprehensive AI governance framework in place.
- 85% of organizations have integrated AI into core operations or deployed it across multiple functions, but only 25% report comprehensive visibility into how it’s actually being used.
- 74% of organizations plan to adopt agentic AI within two years, but only 21% have a mature governance model for it.
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: What breaks when AI governance is only a one-time review?
A: A one-time review breaks as soon as the agent gains a new tool, a new dataset, or a new workflow.
Q: How do teams know whether AI governance is actually working?
A: Look for evidence that every AI interaction can be traced end to end, from identity and intent to output and enforcement.
Practitioner guidance
- Deploy continuous AI asset discovery Map every AI model, agent, custom GPT, and MCP-connected service to the data sources and tools it can reach, then refresh that inventory continuously as integrations change.
- Tier controls by AI capability Assign different approval, logging, and termination controls to read-only, advisory, and action-capable systems.
- Bind delegated access to revocation paths Require clear ownership, short-lived permissions, and tested shutdown procedures for every agent or integration that can act on behalf of the business.
What's in the full article
Xygeni's full article covers the operational detail this post intentionally leaves for the source:
- A breakdown of how Xygeni maps AI models, agents, and MCP servers across the development lifecycle
- Specific examples of contextual governance decisions for different AI capability levels
- The article's full set of incident statistics and adoption data used to support its governance argument
- Implementation detail on how continuous monitoring is applied to AI-generated code and AI-introduced dependencies
👉 Read Xygeni's analysis of AI governance, monitoring, and contextual control →
AI governance monitoring is lagging. What should teams do next?
Explore further
AI governance debt is now an access problem, not a policy problem. Enterprises are accumulating governance debt when they approve AI use but fail to maintain a living model of who or what the AI can reach. That creates a false sense of control because the documentation says one thing while runtime behaviour says another. For security leaders, the practical conclusion is that governance programmes must measure access drift and behavioural drift together.
A question worth separating out:
Q: Who is accountable when an AI agent uses delegated access incorrectly?
A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.
👉 Read our full editorial: AI governance is failing at visibility, access, and continuous oversight