Elaichi vs Glean: search index or control plane

What is the real choice in Elaichi vs Glean?

Elaichi vs Glean is not two products competing for one slot. Glean builds a permission-aware index over your company's content so people can find things. Elaichi is a governed MCP control plane: one address that AI clients sign into. A model can then run tools in the apps your team already uses, as the person asking.

The decision usually surfaces the same way. Someone in IT has budget for one AI project this quarter. Engineering wants Jira and Sentry inside Cursor. Legal wants to know where the audit trail lives. Support wants to stop pasting ticket text into a chat window. Those are not the same request, and the architecture that answers one of them does not automatically answer the others.

MCP, the Model Context Protocol, is the open standard that lets an AI client call tools on a server. Its authorization model is built on OAuth 2.1 with mandatory PKCE (RFC 7636), and it supports dynamic client registration (RFC 7591). That is why any OAuth-capable client can connect to a conforming server without a vendor-specific SDK. An endpoint is the single network address a client connects to. Both terms show up below.

The figures in this table are vendor-reported, including Elaichi's own. The 650+ figure is a build-time label, counted from a committed connector snapshot and rounded down, so it is not a live count. Check the connectors catalog directly if you're quoting a number to your own leadership. Do the same with Glean's live connectors page before citing either count as current.

Indexed search versus a governed control plane

The two architectures answer different questions. Glean's enterprise search page calls Glean Search "AI-powered workplace search". It says results are real-time and permissions-aware, so everyone sees only what they should (glean.com, checked October 2026). Elaichi moves nothing. A request arrives at the endpoint. Elaichi checks who is asking and what they may reach, then calls the app and returns the result.

That difference has a real cost, not just a benefit. A control plane makes a live round-trip to the connected app on every call. Elaichi's response time is therefore bounded by the slowest app in the chain: Jira's API, Stripe's API, whatever is being called. An outage in that app is an outage in that tool for Elaichi's users too. Trading speed for freshness is the right trade for state questions. It is the wrong trade for content questions. That is the actual reason the two architectures exist side by side, rather than one replacing the other.

A search product answers questions about content, over an estate of documents nobody can navigate by hand.

A control plane answers questions about state, and takes actions. Elaichi serves MCP at one endpoint, POST https://api.elaichi.ai/mcp, the same address for every organization. Which organization, which person and which tools a client reaches comes from the OAuth grant behind its token, not from the URL. A grant is the permission a person gives one AI client when they sign in on Elaichi's consent screen.

So "which leases end next month" is a state question that an app answers from its own records. "What did we decide about the renewal process" is a content question that a search product answers better.

Which AI clients can your people use?

Glean's Agents page describes its agentic engine. It says agents reason through tasks, plan next steps and take action using enterprise context (glean.com, checked October 2026). Elaichi's model is that people stay in the client they already have open, and that client signs into one address.

Claude, ChatGPT, Cursor and Microsoft Copilot all sign into the same Elaichi endpoint over OAuth. There is no per-client address and no per-team address. An admin adds one URL in Claude's Organization settings, one in ChatGPT's workspace settings and one in a Cursor workspace config. Microsoft Copilot reaches the same address through a Copilot Studio agent, which adds the endpoint as a tool with OAuth set to Dynamic discovery. Microsoft Copilot is not a verified client, because Copilot Studio's shared redirect host is deliberately left out of Elaichi's verified list.

Each person then connects their own client once and approves their own grant. Every call made with that grant's tokens acts as the person who approved it, in the organization they picked. Their Elaichi permissions are looked up on each request rather than frozen into the token.

The practical effect shows up with developers. A backend engineer debugging a production error in Cursor does not want a second tab. Asking a search agent and copying the answer back is extra work. Elaichi's catalog reaches Sentry, Linear, Jira and Datadog through the same address Cursor already signs into. Whether that matters to you depends entirely on how your engineers work. For some teams it is the whole argument; for others it is a convenience.

Elaichi keeps no list of approved MCP clients. Any client that supports OAuth dynamic client registration, PKCE with S256 and a browser sign-in can connect. What differs between clients is only where their own settings take the URL. Connect Elaichi to Cursor for a whole team covers the per-developer question in detail.

How does each one govern access?

Glean enforces permissions on its own search platform. Its agent governance page says Glean enforces permissions for every action an agent takes. The same page says admins can define how broadly agents can be shared (glean.com, checked October 2026). Its connectors page describes human-in-the-loop controls that require approval before execution (glean.com, checked October 2026).

Elaichi governs in three layers that are deliberately kept apart.

Permissions say what a role lets a member do. Elaichi's permission catalog has 58 permissions, and a member holds exactly one role. Six system roles form a strict subset chain: Guest, Member, Team Admin, People Admin, Org Admin, Org Owner. Two more sit off the chain for narrow access, and both are free seats: Billing Admin and Auditor. Auditor holds 12 view permissions and nothing that changes anything.

Sharing says who may use a given connection, toolbox or template. A connection is one row the organization reuses through sharing grants, at view, use or edit level, rather than each team re-authenticating.

Restrictions say which connectors and tools a role or a member may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. Allow rules and block rules merge within a layer, and a block always beats an allow. A member is governed by their role rules and their own personal rules at once. A personal rule can only narrow what the role allows.

This is more moving parts than a single inherited-permission model. That is a real cost, not rigor for its own sake. An admin asking why one person can or cannot call one tool has to check three things: role rules, personal rules and sharing grants. There is no single row in a single table to read. The payoff is that a role stays broad while one person's access stays narrow, with no new role invented for them. It is also harder to audit by eye than a flatter model. Teams that skip the three-layer model before writing rules are the ones who get surprised.

One trap to know before you write your first rule. An allow rule that names nothing blocks every connector and tool for its target. The rule turns the allowlist on just by existing. MCP tool allowlist vs blocklist works through when each shape fits.

When a rule blocks a tool, the refusal says the tool is restricted for their role or their account. The caller can then file an access request. An admin who approves it creates an access grant that lifts the block for that one person. It writes no restriction rule and changes nobody else's access.

Restriction changes are not instant. A role, team-membership, restriction or access-grant change reaches every surface about two minutes. What is faster is revocation: removing or suspending a member revokes every live grant in the same transaction as the membership change.

What does the connector catalog actually contain?

Elaichi's catalog holds two kinds of connector, and keeping them apart matters when you are reviewing who is responsible for what.

Most of the catalog is connectors Elaichi authors and runs itself. The rest are native MCP connectors. The vendor builds and runs its own MCP server, and Elaichi handles sign-in, access and audit in front of it. The console labels them with a Native MCP badge reading "The vendor's own MCP server. Elaichi handles sign-in, access and audit."

Elaichi does not curate a native connector's tools. The tools a member can call are the ones the vendor's server lists to that member's own connection. Each organization governs them itself, with restrictions, toolboxes and turning a tool off. Reports about those tools go to the vendor's support contact. This also means tool quality and uptime for a native connector depend on the vendor's own MCP server, not on Elaichi's infrastructure. An outage or a breaking change on the vendor's side is not something Elaichi's team can patch. The remedy is to route around it by disabling the connector.

A team on Gold can also bring its own remote MCP server in as a connector. That needs the connector:create permission, which only Org Owner and Org Admin hold among system roles. A server the team already runs comes in that way. Calls through that connector get the same restrictions, scopes and audit rows as anything else.

The catalog carries 650+ connectors in all. Glean's connectors page states 275+ out-of-the-box connectors, while its enterprise search page says 100+ (glean.com, checked October 2026). Quote whichever number you read together with the page it came from. The discrepancy between Glean's own two pages is a reminder. Verify any connector count against the live page, not a comparison post, this one included.

Locking an argument instead of trusting the prompt

Sharing one connection with a team raises the obvious question: what stops the model calling the right tool with the wrong argument? Elaichi's answer is frozen parameters on a toolbox entry.

Someone who can use a connection pins it into a toolbox entry and locks specific arguments on that tool, a folder id for example. The AI client cannot change a frozen value when it calls the tool. Frozen values are merged over the caller's arguments at execution, so passing a frozen key in the call does nothing. The server-side merge, not client cooperation, is what enforces it. The model can see that a key is frozen, and often the value too. Elaichi prefixes the tool's description with a note such as "(frozen: folder_id=HR)." The protection is that the value cannot be changed, not that it is hidden.

A freeze holds only on calls that run through the entry carrying it. Anyone who can use the same connection directly has the unfrozen tool in their All tools toolbox. So the way to hold a team to a locked argument is to keep the connection unshared and share the toolbox instead. Lock AI agent tool arguments works through a case where the argument is a payee.

Credentials stay out of the client throughout. A separate credential service holds every connected account's secrets, encrypted at rest with AES-256-GCM. Elaichi fetches them into memory only for the call that needs them. The AI client holds an Elaichi token and never the underlying API key or OAuth secret.

What gets written down afterward?

Every connected-tool call that reaches execution writes an audit row. In Elaichi, one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Argument values are not recorded, with one exception: the path argument that names the object is kept as the target id.

Two honest limits. A call refused before execution writes no row at all. That covers a tool a restriction withholds and a call missing an OAuth scope, because the refusal happens before any executor runs. And Elaichi keeps 90 days of audit history by default. A team that needs longer forwards it to its own log service, which comes with the Black plan. Datadog is the destination that delivers.

Every member can read the audit log at some scope. With the audit:view permission, which Org Owner, Org Admin and Auditor hold, they read every event in the organization. Without it, they read their own events plus events on connections they own or can edit. What an AI agent audit log must capture lists the fields worth insisting on, whichever product you buy.

Glean's own Remote MCP Server is tenant-specific and permission-aware, and each person uses their own Glean access. Administrators can disable MCP or hide the end-user Configurator (developers.glean.com, checked October 2026). Compare its audit surfaces on Glean's own pages rather than taking either vendor's summary of the other.

Your compliance review may hinge on a specific certification, such as SOC 2 Type II or ISO 27001. Confirm current status directly on each vendor's trust or security page. For Elaichi, that is the Trust Center. Certification status changes faster than any comparison post, this one included, and neither vendor's marketing copy is the place to verify it.

Where Glean is the better fit

There is a clear case where Elaichi is the wrong purchase and Glean is the right one.

If the problem you are solving is that nobody can find anything, buy a search product. A company with documents scattered across Google Drive, Confluence, Slack threads and three generations of wiki has a retrieval problem, not an access problem. Glean's enterprise search page describes exactly that job: AI-powered workplace search whose results are real-time and permissions-aware (glean.com, checked October 2026).

Elaichi has knowledge bases on the Black plan. Their search is full-text keyword search, with no embeddings and no semantic ranking. It ranks titles above alternative terms above body text, matches word forms and prefixes, and falls back to near spellings when little matches. A query that uses different wording than the source document can miss a relevant page that a vector-based search would catch. That is useful for a team's own written guidance. It is not an enterprise search index over your whole document estate, and a post that implied otherwise would be selling you something.

Elaichi's own limits deserve stating plainly, separate from "wrong tool for the job": its knowledge base search is lexical, not semantic, as above. Its default audit retention is 90 days, and anything longer requires the Black-plan log-forwarding add-on. Microsoft Copilot sits outside its verified client list for a Copilot Studio reason described earlier, not a hedge. None of these make Elaichi the wrong purchase for an access-and-action problem. They are real constraints to check against your own requirements.

There is a second case where you do not need Elaichi. If one app's own MCP server covers what your team asks, and that team lives in one client, run the vendor's server directly. When you don't need an MCP gateway yet walks through that threshold properly.

When a company runs both

The hybrid shape is common enough to name. Glean handles "where is the thing we wrote," and Elaichi handles "do the thing, as me, in the app."

A plausible split at a 400-person company: Glean indexes Drive, Confluence and Slack so anyone can find a policy or a past decision. Elaichi sits in front of Salesforce, Zendesk, Stripe and Jira. A support lead in Claude reads a customer's tickets on her own Zendesk sign-in. A finance analyst in ChatGPT reads Stripe charges but cannot reach the refund tool, because a block rule on his role names it. An engineer in Cursor reads Jira and PagerDuty without leaving the editor, with the destructive tools blocked for her role.

The two do not conflict, because they do not touch the same data path. Glean's results are served through its own search surface. Elaichi holds no copy at all: each call fetches the credential for that connection, calls the app, and returns the result.

What you should not do is buy both to solve one problem. If the real complaint is "our AI cannot find the handbook," a control plane will not fix it. If the real complaint is "our AI cannot update the ticket," a search product will not fix it either. Write down which sentence your team keeps saying, and buy against that sentence.

What happens when somebody leaves

Offboarding is where an access story is tested, so ask it of both products.

In Elaichi, a SCIM deprovision suspends the member rather than removing them. Suspension revokes their API tokens and their MCP OAuth grants. The endpoint re-reads the grant on every request, so their AI clients fail on the next call. Reactivating the member does not bring the grants back; they have to consent again.

Removing a member outright is a separate action in Settings, People, and it is held to the member's whole estate. A preflight returns the connections they own, plus their toolboxes, templates and custom connectors. It also returns the toolbox entries elsewhere in the organization that rely on them. The removal is refused until each shared toolbox, shared template, custom connector and blocking private connection has a decision. A shared connection left in place keeps working for the team. It still acts in the third-party app as the account that connected it. Deprovision that account separately, in the app or through your identity provider.

One removal ends a person's reach through Elaichi. It does not remove their accounts in the connected apps. Offboarding AI access, contractors included covers the full sequence.

How to decide in a week

Five questions, answered with your own systems rather than a vendor's deck.

1. Is the request retrieval or action? Collect ten things people actually asked an assistant to do last month. Count how many need a document found, and how many need an app queried or changed.
2. Where do your people work? Say your engineers live in Cursor and your support team lives in Claude. A tool with its own interface then adds a tab switch to every task. If everyone is comfortable in one portal, that cost is zero.
3. Who must be able to prove what happened? Ask your compliance reviewer what a satisfactory record looks like. Check that against the audit fields each product writes, the retention window, and what is left out: refused calls and argument values.
4. What is the offboarding story? In Elaichi, removing or suspending a member revokes their MCP grants and their clients fail on the next call. Ask the same question of anything else you are evaluating, specifically what happens to in-flight tokens and shared resources.
5. What compliance certifications does each vendor hold today? Ask for the current SOC 2 report or ISO 27001 certificate directly, not a mention of either in a sales deck or comparison post.

Connect your first work app walks through the action side with a real app rather than a diagram. The connectors catalog shows what is already there. For how the three governance layers fit together before you write a rule, roles, restrictions and ACLs is the one to read first. If the shortlist is still open, Glean alternatives that act in your apps compares the wider field.