# Give ChatGPT and Claude Company Data, With Citations

> How to let ChatGPT and Claude search Gmail, Slack, Drive and Notion through a permission-aware layer that returns the source record behind every answer.

Canonical page: https://www.greatarrow.ai/guides/ai-access-company-data-with-citations · updated 2026-09-15

Connect each source once — Gmail, Slack, Google Drive, Notion — through a layer that both assistants query as an external tool, and have it return the source record alongside every fact. The assistant searches your data at question time rather than being trained on it, and you can open the message or file behind any claim it makes.

## What "with citations" has to mean

An assistant that answers from your company data without showing where the answer came from is worse than one that cannot see your data at all, because the confident wrong answer is indistinguishable from the right one.

A citation here is narrow and specific: the retrieval step returns the source record with each fact — which message, which file, which page — and the assistant renders it as a link you can open. That gives you two things a bare answer cannot. You can check the original wording, and you can see the date, which is usually what separates a fact that is still true from one that expired two quarters ago.

Be clear about what a citation does _not_ do. It does not prove the answer is correct — an assistant can cite a real document and still summarise it badly. It is a check you can run, not a guarantee you can skip.

## How permission-aware retrieval works

Four steps, and the permission question is settled in the first one, not the last.

1. **Connect a source.** You authorize the connection through the provider's own OAuth flow. You are consenting as yourself, so the connection can only ever reach what your account can reach. There is no password to hand over and no shared service account.
2. **Sync into an isolated workspace.** Content is pulled into a workspace scoped to you or your team, encrypted at rest, and indexed for search.
3. **Search at question time.** When an assistant asks a question, the layer searches the workspace and returns matching passages with the record each came from.
4. **Answer with sources.** The assistant answers from those passages and renders the links.

Two properties are worth insisting on. Retrieval is **at question time**, so nothing is baked into a model and correcting a record corrects future answers. And the workspace boundary is enforced **server-side, before the query runs** — in GreatArrow.ai every workspace-scoped request resolves its tenancy in the application and fails closed, a property gated in CI rather than left to per-query discipline.

## Which sources you can connect

GreatArrow.ai supports 40+ connectable source types. The four this guide is about:

| Source       | Auth         | What becomes searchable              | Notes                                                                                                                                    |
| ------------ | ------------ | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Gmail        | Google OAuth | Messages and threads in your mailbox | Scoped to your own account; see [Connect Gmail to Claude](/guides/connect-gmail-to-claude)                                               |
| Slack        | Slack OAuth  | Messages and threads                 | Limited to the channels you allow at authorization; see [Connect Slack to Your AI Assistant](/guides/connect-slack-to-your-ai-assistant) |
| Google Drive | Google OAuth | Documents and their contents         | Includes Docs, Sheets and Slides as separate source types                                                                                |
| Notion       | Notion OAuth | Pages and databases                  | Notion's own consent screen controls which pages are shared                                                                              |

The rest of the catalogue covers mail and calendar (Outlook, Google Calendar), chat (Teams, Discord), storage (OneDrive, SharePoint, Dropbox), work tracking (Jira, Linear, Asana, Confluence), code (GitHub, GitLab), meetings (Zoom, Granola, Fireflies), design (Figma, Canva), CRM and finance (HubSpot, Salesforce, Stripe, QuickBooks), and platform tools (Vercel, Supabase, Sentry). The live list is in the product at [/integrations](/integrations).

A source you have not connected is not searchable. That is the intended default: connecting one source is a complete setup, and most people start with whichever one they waste the most time searching by hand.

## Security, in specifics

Vague assurances are not useful when you are deciding whether to connect a mailbox. The specifics for GreatArrow.ai:

- **Encryption at rest.** Stored content and the credentials for connected tools are encrypted with [AES-256-GCM](https://csrc.nist.gov/pubs/sp/800/38/d/final) at the application layer.
- **Tenant isolation.** Every workspace-scoped request resolves its tenancy server-side and fails closed.
- **Access keys.** Each connected client's key is stored as a one-way fingerprint and shown to you exactly once. Any of them can be revoked from your account, effective immediately.
- **Your own key.** Enterprise workspaces can supply their own encryption key on top of the above.
- **Training.** Your content is processed to answer your requests. It is not used to train third-party models, and Great Arrow does not use it for its own model training without separately-given consent.

The full statement is on the [security page](/security). Note what is _not_ claimed there: no compliance certification is asserted on that page, so if a certification is a procurement requirement for you, ask before you assume — do not read this guide as a certification claim.

## A concrete example

A client emails: _"We've decided to go annual — monthly billing won't clear our procurement."_

You ask Claude what the billing terms for that account are. The layer searches your connected Gmail, finds that message, and returns it as a passage with a link to the thread. Claude answers "annual, invoiced" and shows the email it read.

Two months later someone else asks the same question in ChatGPT. Same workspace, same message, same answer — and the same link, so they can see it came from the client rather than from an assumption someone made.

If the client later reverses the decision, the new email is the newer record. You can see both, dated, which is the part a context file you maintain by hand cannot do.

## How this compares to the alternatives

**Native ChatGPT and Claude connectors** are the shortest path if you use one assistant. They are built by the vendor, well integrated, and require no third party. Their limit is exactly their strength: the connection is configured inside one vendor's product, so using a second assistant means configuring the same sources again there, with separate permissions and separate behaviour.

**Enterprise search** (Glean and similar) indexes a whole organisation's tools and is built around company-wide permission mirroring. If you are deploying to hundreds of people and need existing document ACLs reflected exactly, that is the category to look at — it does a job a lightweight layer does not attempt. It also carries the cost and rollout that implies.

**A shared context layer** sits between them. One connection per source, read by every client you use, sized for a person or a team rather than an enterprise directory.

None of these dominates. Use one assistant and only need files? Use its native connector. Rolling out to a large organisation with strict ACL mirroring? Look at enterprise search. Using several assistants and want them to agree? That is the case a shared layer is actually for. The [comparison page](/compare) sets out the trade-offs by capability.

## Who this is for, and who it is not for

**It is for you if** you already answer questions by searching your own email and documents by hand, and you use more than one assistant.

**It is not for you if** you cannot connect the source at all — some regulated environments will not permit third-party OAuth to a mailbox, and no product feature changes that. It is also unnecessary if your data is already in one place with good search and you only use one assistant against it.

## Where to go next

[Share Context Across Claude, ChatGPT and Cursor](/guides/share-context-across-claude-chatgpt-cursor) covers the client side of the same setup. [Stop Re-Explaining Your Company to Every AI Tool](/guides/stop-re-explaining-your-company-to-ai) starts from a manual template if you want to try the free version of this first.

Per-source walkthroughs: [Gmail](/guides/connect-gmail-to-claude), [Slack](/guides/connect-slack-to-your-ai-assistant), [GitHub](/guides/connect-github-so-your-ai-knows-your-repos), and [ChatGPT as a client](/guides/connect-chatgpt-to-your-business-data). Setup starts at [/install](/install); the capability list is on [features](/features) and plans are on [pricing](/pricing).

## Questions

### What does a citation actually mean here?

It means the answer carries a pointer to the record the fact came from — the message, file or page — rather than only the model's assertion. A citation is not proof the answer is right; it is what lets you check. Open the record and you can see the original wording and its date, which is usually enough to tell a current fact from an expired one.

### Do I have to connect everything at once?

No. Each source is connected separately through its own OAuth flow, and a source you have not connected is simply not searchable. Connecting one source is a complete, useful setup — most people start with the one they lose the most time searching by hand.

### How is this different from ChatGPT's or Claude's own connectors?

The native connectors are the better choice when you use one assistant and want the shortest path to your files. A separate layer earns its place when you use more than one assistant, because it holds one connection per source that every client reads, rather than a separate connection configured inside each vendor.

### What happens when I revoke a connection?

Two separate things, and it is worth checking both in any product you evaluate. Revoking the authorization stops future syncing. Removing the already-synced content is a second action. Ask what the deletion window is and whether revoking upstream — in Google or Slack — is honoured, rather than assuming disconnect means delete.

### Can a connected source leak into another customer's workspace?

Ask where the boundary is enforced and whether it fails closed. In GreatArrow.ai every workspace-scoped request resolves its tenancy server-side in the application before it reaches storage, and fails closed — a property gated in CI rather than left to per-query discipline. Ask any vendor the same question.
