Knostic’s Gartner cool vendor recognition and AI governance gap

At a glance

What this is: This is an analysis of Knostic's Gartner recognition and the AI governance gap it points to, with the key finding that traditional access controls do not fully contain AI-layer oversharing risk.

Why it matters: It matters because IAM, IGA, PAM, and data security teams now have to govern what AI systems can expose from authorised data, not just who can access the source systems.

Context

AI cybersecurity governance is the discipline of controlling what data an AI assistant, LLM, or agent can surface from otherwise authorised sources. The problem is not just model output quality; it is whether the AI layer expands access beyond the user's intended need-to-know boundary.

Knostic's recognition reflects a broader enterprise problem. As organisations adopt Copilot-style assistants and agentic systems, legacy access models and data protection controls often stop at the repository boundary, leaving prompt-time and response-time exposure insufficiently governed.

Key questions

Q: How should security teams govern AI assistants that can access audit data?

A: Treat them as privileged non-human identities with defined scope, logging, and approval boundaries. Access should be limited to the smallest useful data set, and any output that can influence operations should require human authorization before execution. That approach reduces the chance that an AI assistant becomes an unreviewed control point inside security operations.

Q: Why do traditional access controls fall short for enterprise AI governance?

A: Because they were built to decide access to records, not to govern how an assistant transforms records into answers. Once AI can summarise, infer, and combine content, the disclosure risk is no longer limited to the permission on the original item. The control must move closer to the interaction layer.

Q: What are the best signs that AI oversharing risk is not being controlled well?

A: Look for assistants that can answer sensitive questions with details users could not reasonably retrieve through normal application workflows. Other signs include inconsistent redaction, weak topic boundaries, and policy logs that show the data platform is governed but the AI response path is not.

Q: When should organisations prioritise governance over more AI pilots in healthcare?

A: Organisations should prioritise governance when data quality, provenance, or workflow fit is inconsistent across care settings. If the same information cannot be trusted across hospital, outpatient, home, and device-generated contexts, more pilots will increase complexity faster than value. Governance becomes the bottleneck because it determines whether AI can scale safely.

Technical breakdown

Why topic access governance is different from repository access control

Topic access governance governs what an AI system can reveal in response to a prompt, not just what a user can open in the source repository. That distinction matters because an AI assistant can aggregate, infer, or repackage content from multiple authorised locations into an answer that exceeds the user's operational need. In practical terms, the control point shifts from static entitlement checks to contextual mediation over prompts, retrieved content, and generated responses.

Practical implication: treat AI response control as a separate policy layer from source-system access control.

How AI oversharing happens across copilots and LLM chat

AI oversharing occurs when a user with legitimate access to some content can still elicit more sensitive information through an assistant than they should see in direct use. This can happen when the AI layer has broader retrieval scope, weak topic boundaries, or insufficient policy context from DLP and DSPM systems. The result is not a classic permission failure in the source system, but a governance failure at the AI interaction layer.

Practical implication: review where the AI layer can compose answers from data that individual workflows would not normally surface together.

Need-to-know becomes a runtime policy for AI assistants

Need-to-know controls were designed for human-centric access decisions, but AI assistants operationalise them at runtime. That means policy enforcement has to understand topic, business context, and sensitivity before the response is delivered. When integrated with data security and governance tooling, the AI layer can block high-risk prompts or redact responses, but only if those controls are evaluated in the conversation flow rather than after the fact.

Practical implication: enforce need-to-know in the response path, not only through downstream review or audit.

NHI Mgmt Group analysis

AI cybersecurity governance is becoming a distinct control plane, not a branding layer. The article shows that enterprises are no longer just securing models or repositories; they are securing the data exposure path created by AI interaction itself. That changes the unit of governance from access to answer, which is why AI governance now sits alongside IAM, DLP, and DSPM as a separate decision surface. Practitioners should treat AI exposure governance as an operating discipline, not a pilot.

Topic access governance is the clearest example of policy moving closer to the prompt. Traditional access control decides whether a user may reach a dataset, but AI assistants can reveal meaning that the user never directly requested from the system of record. That creates a governance gap where authorised access becomes unauthorised disclosure by composition. The named concept here is AI-layer oversharing risk: information becomes exposed not because access was absent, but because access was too broad for conversational reuse. Practitioners need to reframe policy around what an assistant can safely surface.

Gartner's recognition underscores a market shift toward control points that sit between data platforms and AI experiences. The article's emphasis on integration with Purview, DLP, and DSPM reflects where operational demand is heading. Security teams are looking for policy consistency across the data estate and the AI interface, not another isolated control silo. That means governance programmes should map where AI-specific policy can complement existing data security controls without assuming those controls already cover AI.

Need-to-know principles survive only if they are made machine-readable at inference time. Human governance models assume a person asks for data and a system returns a bounded result; AI assistants collapse that sequence by mediating access through generated output. The implication is that access certification, audit, and data classification must all account for the AI response layer. Practitioners should assume that AI will expose control gaps faster than traditional review cycles can catch them.

This category is moving from experimentation to accountability. As AI assistants and agents enter production, organisations will be judged on whether they can explain why certain answers were allowed, blocked, or redacted. That elevates logging, policy traceability, and cross-team ownership from nice-to-have capabilities to core governance requirements. Practitioners should expect AI cybersecurity governance to become a standard part of security and compliance review.

From our research library:

• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• 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, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

AI-layer oversharing risk: The governance problem is no longer only who can reach data, but what an AI assistant can safely surface from it. That shifts policy design toward inference-time controls, because repository access alone does not contain conversational disclosure.

Enterprises should expect AI governance to converge with data security governance, especially where DLP and DSPM already exist. The hard question is whether those controls can express topic sensitivity and business context strongly enough to manage assistant responses without breaking legitimate use.

Knostic's recognition is a signal that security teams will be asked to govern AI exposure with evidence, not intent. That means traceable policy enforcement, defensible logging, and clear ownership between identity, data, and AI platform teams.

For practitioners

• Map AI response exposure boundaries Document which prompts, topics, and connected sources can cause an assistant to reveal information beyond direct source access, then classify those exposures by sensitivity and business context.
• Align DLP and DSPM with AI interactions Extend existing data security policies so they evaluate retrieved content and generated responses, not just stored data and transport controls.
• Define topic-level approval rules Create rules for high-risk topics where AI responses must be blocked, narrowed, or redacted before delivery to the user.
• Instrument AI governance logging Capture which topics were queried, which policy checks ran, and whether the system allowed, limited, or denied the response.

Key takeaways

• AI assistants create a governance problem that goes beyond source-system permissions because they can expose more than the underlying application would.
• The article points to a real control gap at the AI interaction layer, where prompts and responses need policy enforcement alongside DLP and DSPM.
• Security teams should treat AI governance as a separate control surface and define what an assistant may surface before broad deployment.

Key terms

• AI Cybersecurity Policy: AI cybersecurity policy is the set of rules and accountabilities that govern how AI is approved, monitored, and controlled in security environments. It turns broad governance goals into operational expectations for ownership, logging, review, and escalation across technical and business teams.
• Topic Access Governance: A control approach that limits what an AI system may reveal based on the user’s topic-level entitlement, not only source data permissions. It tries to prevent oversharing by governing conversational disclosure, which is a different problem from standard file or application access control.
• AI Oversharing: The exposure of information through an AI assistant that exceeds what the user should reasonably receive in that context. The data may be technically accessible somewhere in the environment, but the model combines it into a response that breaks need-to-know expectations.
• Need-to-know access: Need-to-know access means granting data access only when a user or identity requires it for a specific business purpose. In PCI and identity governance terms, it is a scope control that should be time-bound, owner-approved, and removable when the task ends, otherwise it becomes standing privilege by another name.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.