WonderForce vs Glean: two permission models for AI answers.

What Glean documents about permissions. *

On where the permission comes from, Glean’s core security principles state: “Glean mirrors the access controls of every connected source system. When a connector crawls content, it also ingests the permission model from that source (ACLs, group memberships, role assignments). At query time, Glean evaluates the signed-in user’s identity against those mirrored permissions before returning any results.”

The same page states that this applies to generated answers, not only to search results: “AI answers and citations: Glean generates responses only from content the querying user is authorized to access. Citations link to source documents that the user already has permission to open.” It states the converse case directly: “If a user can’t open a document in the source system, that document can’t be used as context, returned as a search result, or surfaced as a citation. Glean never grants broader access than the source system provides.”

Enforcement is claimed on the protocol surface too: “MCP servers: Results returned through the Model Context Protocol respect the authenticated user’s permissions.” And Glean’s end-user documentation describes the per-reader consequence plainly: “Glean respects the permissions set in your company’s connectors. If you have permission to view a document in Google Drive or a thread in a public Slack channel, it can appear in your results. If your coworker has different permissions, they might see different results.”

The agent-identity property, stated plainly.

One line in that document deserves to be called out rather than buried, because it is a strong property and not every design has it: “Agents and actions: Agents execute with the identity and permissions of the signed-in user who triggered the run, regardless of who created or published the agent.” An agent that inherits its author’s reach is a real hazard in this category. Glean documents that theirs does not. That is worth saying on a page that is otherwise about where we differ.

What Glean documents about unattended runs.

For work that happens without someone typing a question, Glean documents scheduled triggers: “Scheduled triggers allow users to automate and standardize business processes by enabling agents to perform actions in the background. Each user of an agent can specify when they want that agent to run, such as daily or weekly.” Their security guidance for that mode states: “Scheduled triggers agents run on a schedule without user manually initiating or approving each execution.”

Glean also names the control model for unattended runs itself: “Since schedule triggers fire and execute the agent end-to-end with no per-run confirmation, security control shifts left to governance: who may create and publish agents, how inputs are constrained, and which tools can run without user confirmation.” And it documents a fail-to-notify behaviour rather than a silent skip: “If a background run reaches a tool that still requires user confirmation, Glean emails the subscriber instead of silently skipping that step.”

A second runtime control plane is documented as well. Glean labels the page “Beta: This feature is in beta and may change.”, so read the rest with that caveat attached: “Agent access policies allow security administrators to control what data agents can read and what actions they can execute at runtime.” Glean is explicit that this sits alongside, rather than instead of, source permissions: “Agent access policies do not replace existing source permissions or Role-Based Access Control (RBAC). Instead, they establish a secondary control plane that evaluates live runtime behavior including the active tool, the invoking user, the agent in scope, input arguments, and returned payloads.”

Where the two designs diverge: the unit of permission, and who the reader is.

The unit, and where the permission comes from.

Glean’s documented unit is the source document, and its permission is inherited from the system of record. The connector “also ingests the permission model from that source,” and the signed-in user is evaluated against that mirror when the query runs. That is a clean design with a real advantage: the source system stays the single authority on access, and the search layer never becomes a second place where access is decided.

WonderForce takes the smaller unit. A fact — a decision, a date, a commitment, a number — is derived from the messages, documents and meetings it came from, and carries an audience computed from who actually had access to those sources. That audience is enforced at serve time, on every delivery. An answer assembled from several facts reaches only the people cleared for all of them: the intersection of the inputs, not the union. Every claim served carries the supporting email, document or meeting with it.

Different unit, different origin, and neither is a hole in the other. Where an answer rests on a single document, the two designs land on the same set of readers. The difference shows up when an answer combines sources whose audiences differ, because the combined answer is governed by no single source’s permission.

Who the reader is when nobody asked.

Evaluating the signed-in user at query time is a complete answer whenever there is a signed-in user asking. For work that runs unattended, Glean documents a mechanism a person sets up: “Each user of an agent can specify when they want that agent to run, such as daily or weekly,” and Glean describes the control for that mode as governance over who may create and publish agents and which tools may run without confirmation. That is the mechanism their documentation describes, in their words.

WonderForce starts from the other end of that problem. Nobody configures an agent. Each person receives a brief built from that person’s own evidence and pushed to them — a playbook for the day, a brief before a meeting — and the audience carried by each fact is what decides whether that fact belongs in one person’s brief, or in one delivered to a channel several people read. When there is no query, there is no signed-in asker to evaluate, so the permission has to travel with the content itself. That is the reason for the smaller unit, and it is the reason enforcement sits at delivery rather than at retrieval.

Agents connected to WonderForce over MCP read from the same brain under the same rules. Each agent reads exactly what its principal may read and never more, so connecting one widens no one’s access.

The two models, question by question.

Every cell in the Glean column is a verbatim quote from the linked page

What to check for yourself, with any vendor.

These questions are not about one product. Ask them of anything that answers from your company’s data, and ask for the documentation page rather than the sales answer.

• What unit carries the permission — the document, or the claim?A permission attached to a container governs the container. Ask what governs a sentence assembled from three containers.
• Where does that permission come from, and how current is it?A mirrored access-control list is only as accurate as its last refresh. Ask how permission changes propagate, and how fast.
• When is it evaluated — at index time, at query time, or at the moment an answer is delivered?Each is a defensible choice, and each fails differently. The one that matters for your risk is the one that covers the surfaces you plan to use.
• What governs an answer that combines sources with different audiences?Ask for the rule in writing. Union, intersection, or the permission of the place the answer lands are three very different products.
• Who is the reader when nobody asked?For anything scheduled, pushed, or posted into a shared space, ask whose permissions decide what appears — and whether the feature is generally available or in beta.

Questions people ask when comparing these two.