Appearance
Access model
Liddr's access model rests on one deliberate principle: the organization knowledge graph has no per-user access control. Every member of a workspace can retrieve anything in the shared graph through Know.
That single fact shapes every decision about what Liddr will and won't ingest. This page explains the principle, the confidentiality boundary it forces between ingest and MCP, and which classes of data fall on each side.
The shared-graph principle
When Liddr ingests a source, it writes the result into a shared knowledge graph that lives inside your organization's own isolated workspace. Know retrieves from that graph to answer questions.
There is no row-level or per-user ACL on the graph. It is, by design, a shared organizational memory: structure, business rules, and team knowledge that everyone in the workspace is meant to be able to find.
The corollary is strict:
If something is ingested into the graph, treat it as readable by every member of the workspace.
So the question "should Liddr ingest this source?" reduces to: is this data safe for everyone in the workspace to read? If the answer is no — because it's personal, record-level, or otherwise sensitive — it must not be ingested. That is the confidentiality boundary.
Ingestion is a publish-to-everyone action
Connecting an ingest connector publishes that source's content into a graph with no per-user filtering. Only connect sources whose content is appropriate for the whole workspace.
The two paths: ingest vs. MCP
Liddr reaches data two different ways, and the access model is the reason there are two.
| Ingest connectors | MCP connectors | |
|---|---|---|
| Where data goes | Into the shared knowledge graph | Nowhere — fetched live, never stored |
| Whose credentials | Org-level (shared connector credential) | The individual user's own credentials |
| Who can see results | Everyone in the workspace | Only the user who connected it |
| Freshness | A snapshot from the last ingest run | Live at query time |
| Configured | Org-wide, by an admin | Per user |
| Suitable for | Org-shared, non-sensitive data | Personal, record-level, sensitive data |
Ingest is for the shared substrate — org structure, project tracking, business rules, team docs and knowledge. It's pulled once and made searchable for everyone.
MCP (Model Context Protocol) is how Know reaches personal and sensitive data without ever writing it into the graph. An MCP connector is configured per user and runs under that user's own credentials, so a user only ever sees what they're individually permitted to see at the source. Results are fetched at query time and used to answer — they're not ingested, and answers that used a personal connector are flagged as such so personally-fetched results stay isolated from the shared graph.
The same system can appear on both sides
A source like Notion, Linear, Sentry, or GitHub can be both an ingest connector (org-shared content, for everyone) and an MCP preset (live, personal access for one user). They're complementary: ingest covers what the whole org should share; MCP covers what only you should see.
Data classes: what goes where
The table below is the operational form of the principle. Org-shared, non-sensitive structure and knowledge is ingested. Personal, record-level, or sensitive data is reached only per-user through MCP.
| Data class | Examples | Path | Why |
|---|---|---|---|
| Org structure & business rules | Org chart, ownership, conventions, policies | Ingest | Meant to be shared; safe for everyone to read |
| Project & dev tracking | Jira, Linear, GitHub/GitLab issues & code structure, Azure DevOps | Ingest | Shared engineering context |
| Ops & reliability | PagerDuty, Opsgenie, Sentry | Ingest | Shared operational knowledge |
| Docs & team knowledge | Notion, GitBook, Guru, Confluence, Coda, Contentful, Miro | Ingest | Shared knowledge base |
| Data-platform structure | Databricks (structure, not row data) | Ingest | Shared schema/structure, not sensitive rows |
| Personal mailboxes & files | Gmail, Drive, Outlook, OneDrive, Box, Dropbox, SharePoint | MCP only | Per-user; no shared ACL to honor in the graph |
| Communications | Slack, Teams, Google Chat, Zoom | MCP only | Personal/scoped; runs as the individual |
| CRM & customer records | HubSpot, Affinity, Gong | MCP only | Record-level; not safe to publish to everyone |
| Support tickets | Zendesk, Freshdesk, Freshservice, Intercom, Front | MCP only | Record-level customer data |
| HR | Workday, BambooHR, 15Five, Greenhouse | MCP only | Personal/sensitive |
| Row stores & sensitive ops | Airtable, Smartsheet, Quip, DocuSign | MCP only | Record-level/personal content |
Why CRM, support, and HR are deliberately not ingested
These are exactly the sources teams are most tempted to ingest — and exactly the ones that must not be. They carry record-level and personal data that should not become readable by every member of the workspace. Because the graph has no per-user ACL, the only safe way to reach them is per-user, live, under the asking user's own credentials — i.e. MCP.
Some enterprise sources are exceptions you control
A small number of enterprise systems (for example Workday or NetSuite structure) may be configured as ingest in specific deployments. Treat any such decision the same way: only ingest what is appropriate for the whole workspace to read.
Putting it together
The whole model is one chain of reasoning:
- The shared graph has no per-user ACL.
- Therefore anything ingested is readable by everyone.
- Therefore Liddr only ingests org-shared, non-sensitive structure and knowledge.
- Personal, record-level, and sensitive data is reached only through MCP, per user, live, under that user's own credentials.
This is a confidentiality boundary by construction, not a setting you have to remember to turn on.