Seclore’s Glean partnership exposes the AI data governance gap

At a glance

What this is: Seclore’s partnership analysis says AI search and summarisation create a governance gap when sensitive data is protected only at the source, not in the generated output.

Why it matters: This matters to IAM, data security, and GRC teams because AI systems can expand access paths faster than policy, classification, and audit controls can follow.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Seclore’s analysis of AI data sovereignty and protected AI outputs

Context

AI search and summarisation platforms change the access model for enterprise data. They do not just retrieve documents, they recontextualise information and can package sensitive material into outputs that are easier to share than the originals. In this article's primary domain, the governance issue is not simply data residency, but whether protection follows the data through discovery, summarisation, and redistribution.

That distinction matters because many organisations still treat classification, access control, and audit as separate layers. Once AI can assemble a new artefact from many protected sources, the control boundary moves to the output itself. Where the article intersects identity security, the same logic applies to AI agents and service accounts that can read, transform, and publish data on behalf of users.

Key questions

Q: How should security teams govern AI-generated summaries that contain sensitive data?

A: Treat AI-generated summaries as new sensitive objects, not as harmless derivatives. Apply the same classification, encryption, access control, and logging rules that protect the source files, then verify that sharing settings and downstream exports preserve those controls across the full lifecycle.

Q: How do data residency choices affect AI identity governance?

A: They change the trust boundary for both the model and the identities that can reach it. If service data is processed in multiple environments, then access policy must follow the residency model, not assume one uniform control plane. Without that mapping, delegated identities can drift into places that were never intended to handle sensitive data.

Q: What do security teams get wrong about AI and data classification?

A: They often treat classification as a labelling exercise instead of an access-control input. If sensitivity labels do not drive retrieval, sharing, and repository policy, AI can still surface protected content. Classification only matters operationally when it changes what the AI layer can see, combine, or return to a requester.

Q: Who is accountable when AI search exposes sensitive enterprise data?

A: Accountability sits with the teams that approved the data connections, retrieval scope, and response handling, not just the users who queried the system. Governance should cover access design, provenance controls, and operational monitoring across identity, search, and AI platform owners.

Technical breakdown

Why AI summaries create a new data control surface

When an AI system summarises multiple protected documents, it can concentrate sensitive fragments into a single output. That output is no longer just a pointer to source data. It becomes a new object with its own access path, sharing risk, and audit requirement. Traditional data controls often stop at the original repository, but AI-generated artefacts can outlive and outspread the source permissions that created them. If the summary inherits none of the source constraints, the organisation has classified the input but left the output unmanaged.

Practical implication: classify and protect generated outputs as first-class data objects, not as harmless by-products.

Data sovereignty versus data residency in AI governance

Data residency answers where information is stored. Data sovereignty asks who can read it, process it, and redistribute it under what legal and contractual conditions. In AI workflows, that distinction becomes operational because the system may ingest regulated content, transform it, and surface it to users who never had direct access to the source files. That makes lineage, entitlement, and export control part of the governance model, not an afterthought. For regulated environments, the issue is whether the control stack can prove effective restrictions after the model has already made the data more usable.

Practical implication: evaluate AI rollouts on read, transform, and share rights, not just storage location.

How AI agents change the identity model around sensitive data

AI agents and connector services operate as non-human identities when they access enterprise content on behalf of people or workflows. That matters because their permissions can be broader than a normal user session and their actions can be harder to reconstruct after the fact. If the agent can query, summarise, and write back data, it needs explicit lifecycle control, scoped access, and logging that ties activity to business purpose. Without that, the organisation creates a powerful new actor with unclear authority over sensitive information.

Practical implication: govern AI agents with identity, privilege, and audit controls that match their operational reach.

Threat narrative

Attacker objective: The attacker objective is to extract or redistribute sensitive enterprise information through AI-generated outputs that appear legitimate and are easier to share than the source material.

1. Entry occurs when an AI platform or connected service is granted broad access to indexed enterprise content without output-level protection.
2. Escalation happens when the system assembles sensitive fragments from many documents into a single summary or generated artefact.
3. Impact follows when that output is shared beyond the original clearance boundary, creating a leak that inherits trust from the source data but not the source controls.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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 output protection is now part of data governance, not a separate add-on. The article correctly points to the failure of treating generated summaries as low-risk artefacts. Once an AI system can compress many sensitive inputs into one shareable output, the governance boundary moves from the source repository to the transformed result. That means classification, encryption, and audit must follow the output as well as the original files. Practitioners should treat this as a data lifecycle control problem, not a document management issue.

Data sovereignty is the right question for AI adoption, because residency alone is too shallow. Residency answers where bits sit, but it does not answer who can process them, who can derive new content from them, or who can export them under a different clearance context. In regulated environments, that gap becomes material the moment an AI assistant can create a new business artefact from protected material. The implication for GRC and security teams is to test entitlement, lineage, and exportability together.

AI agents create a non-human identity governance problem whenever they can read and republish enterprise knowledge. That intersection is easy to miss in data-security discussions, but it is central here. If an agent can access contracts, financial models, or internal briefings, it needs identity-scoped privileges, monitored activity, and a revocation path that works when the business process changes. Otherwise, the organisation is giving machine actors broader information rights than most human users receive.

Context-aware protection is the named control gap this article exposes. The issue is not whether data is classified somewhere in the stack. The issue is whether protection travels with the content after AI changes its form, audience, and risk profile. That is a practical failure mode for DSPM-led programmes that stop at discovery instead of enforcing downstream use controls. Teams should assume that discovery without enforcement is visibility, not governance.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• As AI assistants and connectors behave more like governed machine identities, teams should use NHI Lifecycle Management Guide to align access review, rotation, and offboarding with the same control logic.

What this signals

The immediate programme signal is that AI adoption will force data teams and identity teams into the same control conversation. If a summarisation platform can create a new sensitive artefact, then entitlement review, content protection, and non-human access governance can no longer sit in separate queues. The practical priority is to join DSPM output controls with identity lifecycle controls before AI usage scales further.

Context-aware protection: this is the control model that will separate organisations that merely find sensitive data from those that can safely operationalise it. Visibility alone is not enough when AI can repurpose content at runtime. For identity-heavy environments, the next step is to align AI connector permissions with the same lifecycle discipline used for service accounts and workload identities.

Teams should expect regulators and internal auditors to ask who can derive new content from regulated data, not just where the original data lives. That question will pull AI governance closer to access governance, especially where human users delegate work to AI agents or shared assistants. For a broader control baseline, the NIST Cybersecurity Framework 2.0 remains a useful reference point for mapping governance, protection, and audit responsibilities.

For practitioners

• Protect AI-generated outputs as sensitive records Apply encryption, access controls, and audit logging to summaries, extracts, and derivative files created by AI tools. Do not leave generated artefacts outside the same handling rules as the source documents they were built from.
• Test sovereignty controls beyond storage location Review whether your AI deployment can prove who can read, transform, and export regulated content after it has been summarised or re-shared. Use the phrase read, transform, and export rights in control reviews to force a lifecycle view.
• Scope non-human access to enterprise knowledge Inventory AI connectors, assistant accounts, and service identities that can reach internal repositories. Tie each to a named owner, a business purpose, and a revocation process so access can be removed when the use case ends.

Key takeaways

• AI summaries create new sensitive artefacts that need their own protection, not just source-level classification.
• Data residency answers location, but AI governance depends on proving who can read, transform, and export content.
• Non-human identities inside AI workflows need lifecycle control, because broad connector access can turn summarisation into exposure.

Key terms

• Data Sovereignty: Data sovereignty is the principle that information remains subject to the control, governance, and legal expectations of the organisation or jurisdiction that owns it. In identity programmes, it becomes a control question about who can authorise, revoke, and evidence access as systems cross borders.
• Derived Output: A derived output is a new artefact created from existing content, such as an AI summary, briefing, or extract. It may carry the most sensitive meaning from multiple source files into a single shareable item, which makes output-level protection and audit essential.
• Context-aware protection: Context-aware protection is a data security approach that evaluates the sensitivity of content together with who is sharing it, where it is going, and whether the action fits normal business behaviour. It replaces simple pattern matching with runtime judgement, which is essential for AI-driven workflows.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

Seclore's full post covers the operational detail this post intentionally leaves for the source:

• How ARMOR DSPM classifies content already indexed by an enterprise AI graph without rebuilding discovery workflows.
• How generated summaries inherit classification and protection from the source documents they were created from.
• How encrypted, access-controlled, and audit-logged outputs behave when they move beyond the original workspace.
• How the partnership frames implementation for regulated enterprises using AI search and summarisation at scale.

👉 The full Seclore post covers the Glean integration logic, output protection model, and enterprise AI workflow implications.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners managing delegated access. It helps IAM, security, and compliance teams apply lifecycle discipline to the machine identities that now sit behind AI workflows.