AI governance platforms are exposing gaps in runtime AI risk

At a glance

What this is: This is an independent comparison of five AI governance platforms, and its core finding is that AI governance now requires discovery, runtime enforcement, and risk management across shadow AI, models, and agentic workflows.

Why it matters: It matters because IAM and security teams must decide whether to extend existing SSE or zero-trust stacks, or adopt dedicated AI governance controls, to cover non-human and autonomous AI activity safely.

👉 Read WitnessAI's comparison of five AI governance platforms

Context

AI governance is no longer a documentation exercise. The primary keyword here is AI governance, but the operational problem is that enterprises now need visibility into shadow AI, policy enforcement at runtime, and controls that can follow model usage as it moves across browser tools, native apps, and agentic workflows.

That shift matters to identity teams because AI systems are now acting like non-human identities in practice: they access data, call tools, and execute workflows that create entitlement, data, and accountability questions. Existing GRC tooling can describe policy, but it cannot by itself govern runtime behaviour across the AI footprint.

Key questions

Q: How should security teams govern shadow AI across enterprise users and apps?

A: Security teams should start by discovering where AI is already being used, including personal accounts, embedded AI features, native apps, and agentic workflows. Then they should apply runtime policy controls that can inspect data sensitivity and user context during the session, because governance that only exists in policy documents does not reduce live exposure.

Q: Why do traditional GRC tools fall short for AI governance?

A: Traditional GRC tools are strong at documentation and evidence collection, but AI risk now shows up during execution. If a system can make API calls, query databases, or route prompts in real time, the control must intervene at runtime. Without that, the organisation can prove policy exists while still leaving the activity effectively unmanaged.

Q: What breaks when AI governance only covers browser activity?

A: Coverage breaks wherever AI use moves outside the browser, such as into native applications, IDEs, embedded copilots, and API-driven agent workflows. That creates blind spots in identity, data, and audit coverage. A browser-only model can miss the actor, the action, and the evidence needed to govern the interaction properly.

Q: Should organisations extend zero trust or adopt a dedicated AI governance platform?

A: That depends on the AI footprint and the gap you are trying to close. If the issue is visibility for existing users and apps, an existing zero-trust or SSE stack may be enough. If the problem is shadow AI, runtime policy, and agentic actions, a dedicated AI governance layer is usually the cleaner fit.

Technical breakdown

Runtime AI governance versus static GRC

Static GRC treats governance as an artifact problem: write the policy, map the control, collect the evidence. Runtime AI governance is different because AI activity changes state while work is happening. The platform must observe usage, apply intent-based policy, and intervene before or during a model interaction. That is why browser-only visibility is incomplete when the same AI workload appears in native apps, IDEs, embedded copilots, or agent chains. In identity terms, the control surface now includes who or what initiated the action, which data was touched, and whether the system can explain and constrain the interaction in motion.

Practical implication: validate whether your current controls can inspect and govern AI activity during execution, not only after the fact.

Shadow AI discovery across browser, app, and agent layers

Shadow AI is undiscovered or unmanaged AI use, and it becomes an identity problem as soon as users rely on personal accounts, unapproved services, or embedded AI features inside sanctioned apps. Discovery therefore has to go beyond a browser extension and map activity across the enterprise footprint. That includes tools in use, who is using them, and what data they touch. For IAM and NHI programmes, this is the same structural issue seen in unmanaged service accounts: if you cannot enumerate the actor, you cannot govern its access path or lifecycle. The challenge is not volume alone, but incomplete visibility into the actual identity surface.

Practical implication: require discovery coverage for sanctioned, unsanctioned, and embedded AI usage before you design governance controls.

MCP agents and the new control surface for AI identity

Model Context Protocol, or MCP, gives AI agents a structured way to connect to tools and data sources, which expands the identity problem from application access to delegated execution. Once an agent can call tools, query databases, and execute multi-step tasks, the key questions become scope, context, and authorization boundaries. That is why agentic workflows are not just another data-loss issue. They introduce a programmable control surface where the identity is selecting actions dynamically at runtime. Traditional governance built for human-paced approvals does not map cleanly to that pattern, especially when the agent can chain calls across systems with no human loop in between.

Practical implication: inventory MCP-connected agents separately from general AI use and set explicit runtime boundaries for tool invocation and data access.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI governance has become an identity problem, not just a compliance problem. The article shows that enterprises now need discovery, runtime enforcement, and oversight across shadow AI, model usage, and agentic workflows. That means the governance question is no longer whether policy exists, but whether the identity layer can see and constrain AI behaviour where work actually happens. Practitioners should treat AI activity as part of the enterprise identity surface.

Browser-only AI controls create a false sense of coverage. The article notes that AI activity increasingly extends into native apps, IDEs, and embedded experiences, which browser-layer tools can miss. That gap matters because discovery that misses a large part of the AI footprint will also miss the access, data, and audit trail that security teams need. The practical conclusion is that visibility architecture must match the real execution surface, not the most convenient one.

Runtime defense is now the differentiator between policy and control. AI governance that stops at documentation cannot handle prompt injection, jailbreaks, harmful content, or context-aware data exposure during a live session. The field should stop treating governance as a pre-launch checklist and start treating it as an operational discipline tied to execution time. Practitioners need controls that can observe, evaluate, and intervene while the interaction is still in progress.

MCP creates a named concept we should call the agentic control plane. Once agents can connect to tools and data sources through MCP, the control problem shifts from application access to delegated execution across multiple systems. That control plane has to account for tool selection, data context, and policy enforcement at runtime. For identity teams, the implication is that agent governance and NHI governance are converging around the same runtime authorization problem.

Traditional GRC is being outpaced by live AI behaviour. The article's own comparison shows why documentation-led governance is insufficient when systems make API calls, query databases, and take autonomous actions. The market is moving toward platforms that combine discovery, policy, and runtime enforcement because the old model leaves too much unsupervised action in the gap. Practitioners should re-evaluate whether their current stack can actually reduce exposure or only report it.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, which fragments control and slows consistent governance across teams.
• For a broader view of identity risk, see Top 10 NHI Issues, which connects visibility gaps, lifecycle weaknesses, and governance drift.

What this signals

Ephemeral AI access does not remove identity risk, it changes where the risk shows up. If organisations cannot see shadow AI and agentic execution paths, they will not be able to govern entitlements consistently, regardless of how mature their policy framework looks on paper. The next phase of AI governance will be decided by which teams can connect discovery, context, and runtime enforcement into one operating model.

Agentic AI and NHI governance are converging around runtime authorization. Once agents can connect to tools through MCP or similar control planes, security teams need identity logic that understands delegated execution rather than just user login. That makes OWASP Agentic AI Top 10 relevant to identity teams, because tool abuse, scope drift, and unauthorized action are now part of the governance problem.

For practitioners

• Map the full AI footprint Inventory sanctioned AI tools, shadow AI use, embedded AI features, and agentic workflows across browser, native app, IDE, and API paths before choosing controls.
• Separate visibility from enforcement Do not treat discovery as governance. Require runtime controls that can allow, warn, block, or route AI interactions based on context, data sensitivity, and user intent.
• Define MCP-specific guardrails For agentic use cases, document which tools, databases, and actions each MCP-connected agent may reach, and verify those permissions can be enforced during execution.
• Test your audit evidence path Validate that the platform can produce records showing who used the AI system, what data was touched, and which policy response was applied for each interaction.

Key takeaways

• AI governance is moving from documentation to runtime control, and that changes the identity problem.
• Discovery gaps across browser, native app, and agent layers are the main reason many AI programmes overestimate their coverage.
• Teams that cannot enforce policy during execution will keep producing compliance evidence while leaving live AI risk in place.

Key terms

• Shadow AI: Shadow AI is AI use that security and identity teams have not approved, inventoried, or governed. It often appears through personal accounts, embedded features, or unsanctioned services. The risk is not only data leakage, but also untracked identity activity and unowned access paths.
• Runtime Enforcement: Runtime enforcement is the act of applying policy while an AI interaction is happening, rather than after it ends. In practice, it means the control layer can allow, warn, block, or route activity based on context, data sensitivity, and behaviour at execution time.
• Model Context Protocol: Model Context Protocol is a way for AI agents to connect to tools and data sources in a structured manner. For governance teams, it expands the identity surface because an agent may now invoke systems, move data, and chain actions across services with delegated authority.

Deepen your knowledge

AI governance, runtime enforcement, and agentic control surfaces are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into AI systems with shadow use and delegated execution, it is worth exploring.

This post draws on content published by WitnessAI: a comparison of five AI governance platforms for enterprise risk management. Read the original.