Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Confidential Data Can Glean Agents Access?

Glean agents can read whatever the user running them can open across every connected application, because Glean mirrors source permissions rather than narrowing them. The data to check is not the agent's policy but the sharing state of the underlying files, since an agent will surface every overshared record a user can technically reach.

Files from connected applications flow through a central node toward many accessible record cards.

Glean agents can read whatever the user running them can open across every connected application, because Glean mirrors source permissions rather than narrowing them. The data to check is not the agent's policy but the sharing state of the underlying files, since an agent will surface every overshared record a user can technically reach. That framing matters because Glean's documented security principle is a promise about ceilings: the platform never grants broader access than the source system provides (Glean, 2026). A ceiling set at the user's existing permissions is a strong guarantee against escalation and a weak guarantee against exposure, because most organizations do not know how many confidential files their users can already open. An agent that searches a hundred connected systems at once converts latent oversharing into surfaced oversharing, the mechanism that makes an agent's reach across enterprise applications hard to audit after the fact. This page covers what permission mirroring means in practice, which record types become reachable when sharing is loose, how agent access policies and sharing defaults change the picture, what happens when an agent writes rather than reads, how an organization should measure its own exposure, and which claims a buyer should decline to accept.

Key findings

  • Glean's stated principle is that it never grants broader access than the source system provides, which means the agent's reach is exactly the user's reach across every connected application, no narrower and no wider (Glean, 2026).
  • Agent access policies, documented as governing what data agents can read and what actions they can execute at runtime, are the mechanism an administrator uses to narrow that reach below the user's own permissions (Glean, 2026).
  • Unshared agents are visible by default only to admins, agent moderators and the agent creator, and whether an agent's tools execute depends on the credentials configured for them (Glean, 2026).
  • Approval behavior has changed quickly: the MIT AI Agent Index recorded no user approval requirement found in the agent itself, while Glean's January 2026 release notes describe agents pausing so users can review, adjust and approve high-impact write actions (AI Agent Index, 2026; Glean, 2026).
  • Permission-aware retrieval is the control OWASP names first against vector and embedding weaknesses, and it is also the control that does nothing about data a user was never supposed to be able to open (OWASP, 2025).
  • The practical exposure is an oversharing problem surfaced by an agent, the same pattern that makes customer data reachable by agents a permissions question before it is an AI question (How to Secure AI Agents That Access Customer Data).

What does permission mirroring mean for what an agent can read?

Glean's security principles describe permission enforcement as a mirror. The platform indexes content from connected applications and, at query time, returns only what the requesting user could open in the source system; the documentation states that Glean never grants broader access than the source system provides (Glean, 2026). For a human typing a search, that is the expected behavior. For an agent, the same rule has a different texture. An agent does not type one query and read one result. It decomposes a task into many retrievals, pulls from several systems in one run, and reasons over the union.

Consider a single record type: a compensation planning spreadsheet. In the source drive it was shared to an all-staff group two reorganizations ago and nobody revisited the setting. A human searching for a colleague's name would rarely land on it, because people search narrowly and stop at the first useful hit. An agent asked to prepare a briefing on the sales team's structure will retrieve the org chart, the territory plan, the quarterly review notes and, because it is technically readable by the requesting user, the compensation sheet. The mirror held. The exposure happened anyway.

This is the gap between an access ceiling and an access floor. The ceiling, no escalation beyond the user, is documented and is the right ceiling. The floor, what the agent should read for this task, is not something permission mirroring addresses. OWASP's entry on sensitive information disclosure frames the risk as a model surfacing data it was given access to, and permission mirroring is precisely the case where every disclosed item was legitimately accessible (OWASP, 2025). The buyer's question is not whether Glean enforces source permissions, which its documentation says it does, but how many confidential records already sit beneath its users' permissions.

Which confidential records become reachable when source permissions are too broad?

The honest answer is any record type that lives in a connected application and has drifted into broad sharing. Across a hundred or more connectors the categories are predictable. Human resources documents shared to department-wide groups: performance reviews, termination memos, accommodation requests. Finance files in team drives: forecasts, board materials, vendor contracts with pricing. Customer records in ticketing and CRM systems where every support user seeing every ticket was a reasonable default for a ten-person team and is an oversharing policy for a thousand-person one. Engineering repositories with secrets in configuration files. Legal matter folders opened company-wide so invoices could be approved.

None of these is a Glean problem in origin. All of them become a Glean agent problem at retrieval, because synthesis across sources is where individually unremarkable fragments become a disclosure in aggregate. OWASP's vector and embedding entry names permission-aware retrieval as a primary mitigation and, in the same breath, describes the failure where an indexed corpus contains data users should not have had, which retrieval then faithfully returns (OWASP, 2025).

Glean's own product page for agent governance states that Glean enforces permissions for every action an agent takes (Glean, 2026). That statement is consistent with the mirror principle and should be read with the same precision: enforcement is of the permissions that exist. An organization whose permissions already fence confidential records tightly will find an agent respects those fences. One that has never run an oversharing review will find the agent is the fastest such review it has ever conducted, with results delivered to whichever employee asked.

How do agent access policies and sharing defaults change what an agent can reach?

Glean documents two administrative layers above the permission mirror. Agent access policies govern what data agents can read and what actions they can execute at runtime (Glean, 2026). Agent sharing controls govern who can see and run a given agent: by default, unshared agents are visible only to admins, agent moderators and the agent creator, and whether an agent's tools execute depends on the credentials configured for them (Glean, 2026).

Dimension Glean, per its documentation What a buyer should verify
Access ceiling Never broader than the source system provides How many confidential records sit under users' existing permissions
Runtime data scope Policies govern what agents can read and which actions they can execute Whether policies apply per agent, per source or per record type, and who can edit them
Agent visibility Unshared agents visible by default to admins, moderators and the creator What visibility becomes when an agent is shared to a group or the company
Tool execution Depends on configured credentials Whose credentials: the runner's, the creator's or a service identity
Write actions Agents pause for review and approval of high-impact write actions Which actions count as high-impact and whether the pause can be turned off
Agent creation Agents are created and managed using natural language Who may create agents and what permissions a new agent inherits

Agent access policies are the lever that can set a floor below the user's ceiling. How granular they are, whether they can exclude a record type such as compensation files from retrieval, and who can change them are not described in the pages reviewed. The credentials point matters as much: if a widely shared agent executes tools under its creator's credentials, the mirror reflects the creator, not the person asking.

What happens when a Glean agent acts rather than reads?

Reading surfaces confidential data to the person running the agent. Acting moves it. Glean's release notes for January 2026 describe agents pausing so users can review, adjust and approve high-impact write actions (Glean, 2026). That is a meaningful control, and it is a recent one. The MIT AI Agent Index entry for Glean Agents, compiled before that release, recorded user approval requirements as none found in the actual agent (AI Agent Index, 2026). The gap between those records is a few months: defaults in this category change faster than procurement cycles, and a security review reflects the product as it was on the review date.

Return to the compensation spreadsheet. An agent that reads it and summarizes it to the requester has disclosed it to one person who could already have opened it. An agent that drafts a message to a channel, files a ticket with the figures attached, or pastes a summary into a shared document has moved confidential data to a destination whose membership nobody checked. Which writes count as high-impact, and whether the pause applies to every connected application, are not described in the pages reviewed. OWASP's excessive agency entry describes this failure mode: an agent with more permissions, functionality or autonomy than the task requires, where the harm comes from the action rather than the retrieval (OWASP, 2025).

Glean's press release on Gartner's 2026 emerging market quadrant for no-code agent builders states that organizations can create, use and manage AI agents using natural language (Glean, 2026). Ease of creation multiplies the surface: every agent a business user builds is a new combination of retrieval scope, tool credentials and sharing audience.

How should an organization measure what its agents can actually reach?

Measure the mirror, not the policy. Pick three employees from different functions, a sales representative, a support agent and a finance analyst, and in a controlled session run an agent with each identity against a task that touches confidential categories: "summarize everything about our top customer," "find the latest planning documents for my department," "what do we know about this employee." Log every source document the agent retrieved, not just what it quoted. Then classify each retrieved record: appropriate for this person's role, technically permitted but inappropriate, or of unknown origin. The second column is the oversharing figure, and it is the only number that answers the title question for a specific organization.

Run the same exercise against the agent's actions. Give the agent a task that ends in a write, such as drafting a status update to a channel, and record what it attempted, whether it paused, what the approval screen showed, and whose credentials the write used. The NIST AI Risk Management Framework's Measure function asks organizations to evaluate AI systems with metrics chosen for their own context rather than borrowed from a vendor, and retrieval logs classified by role appropriateness are that kind of metric (NIST, 2023).

Two practices keep the measurement useful. Repeat it after any connector is added, because each new source brings its own sharing history. And record the test date against the product's release notes, since the approval and policy behavior documented today may not be the behavior documented at the next review.

What does a governed environment change?

In a governed environment, a Glean agent still reaches everything the user running it can open, but the sensitive values in what it surfaces on screen are replaced with tokens before the model reads them, so an overshared record reached through mirrored permissions yields tokens rather than its contents.

The mechanism is a class of control that sits between the rendered screen and the model. Sensitive values on the screen, including the salary figures and contract terms that years of drive sharing have left reachable, are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This separates two questions. Glean's principle that access is never broader than the source provides (Glean, 2026) answers the escalation question; it says nothing about whether existing permissions are correct, and the environment is the control that acts when they are not. On actions, Glean's release notes describe agents pausing for review of high-impact write actions (Glean, 2026), while the list of covered actions is not described; the environment makes the approval list the organization's own and records each decision in its own logs.

The control does not fix the sharing state of the underlying files, change Glean's permission model or agent access policies, or alter the model; it changes which values are on the rendered screen when the model reads it.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Where permission mirroring sets the agent's reach equal to the user's, RedactSure's design sets what the model sees independent of either. Work runs inside a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so a compensation figure, an account number or an employee identifier appears to the model as a consistent token such as ACCT_001 or PATIENT_001 for the whole run, whatever the source system's sharing state. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, a model RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would show, for a chosen agent and a chosen task, which confidential values the model would have read under permission mirroring and which it saw as tokens instead, with the AI Control Record as the evidence. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Glean's published documentation and product pages: the security principles page on permission enforcement, the administration pages on agent access policies and agent access management, the agent governance product page, the January 2026 release notes and the June 2026 press release on Gartner's emerging market quadrant for no-code agent builders. It draws on the MIT AI Agent Index entry for Glean Agents (research dataset), on OWASP's Top 10 for LLM Applications entries on sensitive information disclosure, vector and embedding weaknesses and excessive agency (industry standards), and on the NIST AI Risk Management Framework (official guidance). All sources were read as of October 16, 2026.

No hands-on testing of Glean or any other named product was performed. Where this page says a capability is not described in the pages reviewed, it means exactly that: the specific documentation pages listed below do not describe it, which is not a statement that the capability is absent. Vendor features change, as the gap between the Agent Index record and the later release notes shows, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The compensation spreadsheet, org chart, ticket and repository examples describe record types, not any organization; no customer or prospect is described.

Whether a given Glean deployment, its connector set, its agent access policies and its sharing configuration meet an organization's confidentiality obligations is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Glean's documentation answers the escalation question clearly and the confidentiality question only by reference. The platform never grants broader access than the source system provides, agent access policies can narrow what agents read and do, and since January 2026 agents pause for approval of high-impact write actions. What an agent can therefore access is the full set of records its user can technically open across every connected application, which in most organizations includes confidential files that drifted into broad sharing long before any agent existed. Permission mirroring surfaces that drift at the speed of retrieval. A render-layer design of the kind RedactSure describes changes what the model sees rather than what the user can reach. The test is to name one agent and one task, run it under a real employee's identity, and classify every document it retrieved by whether that person should have seen it.

Frequently asked questions

Does Glean let an agent see data the user could not open themselves?

Not according to its documentation. Glean's security principles state that the platform never grants broader access than the source system provides, and its agent governance page states that permissions are enforced for every action an agent takes. The agent's ceiling is the user's ceiling. The practical question is what sits beneath it: files, tickets and records technically open to the user because of sharing decisions nobody has reviewed. Those are reachable, and an agent is more likely than a human to find them.

What are Glean agent access policies and what do they control?

Glean's administration documentation describes agent access policies as governing what data agents can read and what actions they can execute at runtime. They are the layer that can set an agent's scope narrower than the user's own permissions. How granular the policies are, whether they can exclude a specific record type from retrieval, and which roles can change them are not described in the pages reviewed, so a buyer should ask for each in writing and test the configuration on real connectors.

Who can see and run an agent someone builds in Glean?

By default, Glean's documentation states that unshared agents are visible only to admins, agent moderators and the agent creator. Once shared, an agent's audience expands to whatever group it is shared with. Tool execution depends on the credentials configured for the agent, which matters because an agent shared widely but executing under its creator's credentials would act with the creator's reach rather than the runner's. Review the audience and the credential source together.

Do Glean agents ask for approval before taking actions?

Since the January 2026 release, Glean's release notes describe agents pausing so users can review, adjust and approve high-impact write actions. The MIT AI Agent Index entry compiled before that release recorded no user approval requirement found in the agent itself. Which actions qualify as high-impact, whether the pause can be disabled, and how automatically triggered runs behave are not described in the pages reviewed. A buyer should test an action that writes to a shared destination and record what the agent does.

Is oversharing in connected apps really a Glean issue?

In origin, no; in effect, yes. The sharing state of a drive, a ticketing system or a repository is set in that system, and Glean's permission-aware retrieval reflects it faithfully. The difference an agent makes is scale and synthesis: it searches many systems in one run and assembles fragments into a summary, so records that were individually unnoticed become a disclosure in aggregate. OWASP's vector and embedding guidance names permission-aware retrieval as a mitigation while describing this residual exposure.

How can an organization find out what its own Glean agents can reach?

Run an agent under real employee identities from several functions against tasks that touch confidential categories, log every document retrieved rather than only what was quoted, and classify each by whether that person's role should have seen it. Repeat after each new connector and record the test date against the release notes. A governed environment that tokenizes identifiers at the render layer, as RedactSure's design does, adds a second kind of evidence: a record of what the model saw as tokens.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.