In a company's Drive, nobody knows who has access to what any more
In the Drive of a forty-person company, the HR folder lives three clicks from the marketing folder. Some files were shared by link to move fast in 2023, and the link is still going round. Others belong to somebody who has left.
That is the normal state of affairs, not negligence. And it is exactly why you should ask an AI vendor what it does with the permissions already in place, before you ask what it can read.
How a file's sharing decides its reading
Every row can be checked in your own Drive, by opening the sharing panel of the file concerned.
| How the file is shared in Drive | Who can read it through a connected AI |
|---|---|
| Shared with people in a single department | People in that department |
| Shared with people across several departments | Nobody, until an administrator decides where it belongs |
| Shared with the whole company domain | Nobody, until an administrator decides |
| Shared with anyone who has the link | Nobody, until an administrator decides |
| Shared with an address your organisation does not know | Nobody, until an administrator decides |
Four rows out of five end up on hold, and that is the intended behaviour. The rule fits in one sentence: when a file's sharing does not clearly point at one department, your Kastel refuses to choose on your behalf.
A public link makes a file less readable, not more
That is the row of the table everyone stumbles on, and it is deliberate. A file shared with anyone who has the link has no identifiable grantee. There is therefore no department to file it under, and an AI working for the sales team will not see it.
The opposite reasoning would be tempting, since that file is the most open one in your Drive. We refuse it: a file anyone on the internet can open is a file whose internal audience nobody decided, and making it readable everywhere would turn an oversight into a permission.
An administrator can of course file it, and that decision is recorded. This is the difference between a sharing setting and governed context, and it plays out precisely in cases like this one.
The files whose text can be read, and the others
The Drive connector has a wide surface and a narrow depth: many files seen, few contents kept.
The connector reaches nothing the connected account cannot reach. If a person does not see a file in their Drive, no AI will see it through them.
Your documents are read as text
A native Google document is not an ordinary file; it has no downloadable content in the usual sense. Your Kastel therefore asks for an export of its text, and it is that text which is taken in.
Anything carrying no text stays out, without exception. Images, video and binary files are not read. A scanned PDF goes through character recognition, because a signed and scanned quote is context just as much as a typed one.
What this connector does not do
It does not read an endless document. Google caps the text export of a document at ten megabytes, and a document whose text exceeds that cap is not taken in at all. It is not taken in halfway, which would be worse, and the fact that it was skipped is written to your log. A very large report is therefore handled by splitting it up.
It cannot translate a domain into a department. A file shared with your whole domain waits for an administrator, even when your domain maps exactly onto your company. That is a default caution rather than a permanent limit.
Reading is the only verb. Kastel creates, edits, moves and deletes no file in your Drive, and the permission requested from Google allows reading only. A deleted file, or one you stop sharing, is marked as gone at the source on the following pass; its content stays in your Kastel until an administrator erases it.
Connect your Drive and look at what stays on hold.
Kastel's core is free to self-host, with every connector. The connection guide shows how to connect a Google account, and the first thing you will see is the list of files your Kastel refuses to file on its own.
Read the connection guide
