folk exists to keep track of the people you know
folk lives in small teams that sell, recruit or raise money. People you have met get filed there, often imported from LinkedIn in two clicks, with a quick note on who they are and what they want.
That note is the heart of the matter. A shared address book always ends up holding judgements about people, a line about a negotiation that went badly, a remark nobody would write in an official system. Those people never asked to be in there, and the question becomes who will be able to read them through an AI.
The connector names what it reads, and contact details are not on the list
From a person record, the connector keeps five things. The full name, the name of the linked company, the job title, the description note, and the names of the groups the record sits in. From a company record, it keeps the name, the description and the groups.
The arrays of email addresses and phone numbers that folk returns with every record are never read. Postal addresses and the fields your team added itself are not read either. The connector does not strip them out after receiving them, it never goes looking for them.
The difference with the HubSpot connector is real, and it deserves naming. There, a contact's business details do come in, because a sales CRM is used to reach people. An address book is used for the same thing, and the choice made here is the opposite, because an AI does not need to know how to reach someone in order to answer a question about context.
When a field meant to hold text holds something else, it is left aside rather than copied across wholesale. A record of an unexpected shape therefore comes in with less information, and never with more.
The record without the contact details
On an address book, the boundary is drawn field by field. Here are the fields that are read, as they are written in the connector.
The connection-strength score is tempting to use as an access right, since it says who on your team knows a contact best. Knowing someone does not entitle you to decide who else knows them, so that score is never consulted.
The group is the only audience signal folk gives
folk sets no read permission on a record. There is no owner in the CRM sense, and the field naming whoever created the record never decides anything. The connection-strength score folk works out between your team and a contact is not an access right either, and it is not read.
The only signal available is the group. An administrator maps your folk groups to your departments, and that mapping is what files each record. A record in the Clients group reaches the department you associated with that group, and nobody else reads it. The mechanism is the same across all your sources.
As long as that mapping does not exist, no record is readable. That is the state on first connection, and it is deliberate. Four further situations leave a record waiting for an administrator's decision.
- The record belongs to no group at all
- None of its groups appears in the mapping
- Its groups point to more than one department, so its audience is ambiguous
- The department named does not genuinely exist in your organisation
What teams ask before connecting their address book
Four questions come up every time, and all four are about what the AI will not have.
Will an AI be able to list my contacts with their email addresses?
No, because those addresses were never written into your Kastel. The connector reads neither the email array nor the phone array of a record. A connected AI can know who a person is and what they do; it does not pick up the means to contact them along the way.
Is the note I wrote about a contact read?
Yes, a record's description comes in with it, because it is often the only useful thing written there. That is worth knowing before connecting an address book you have kept for three years. The note stays readable by the single department the record's group points to.
What happens to a record I delete in folk?
It is marked in your Kastel as gone at the source, and its content stays there, readable by the same people as before, until an administrator decides to erase it. That behaviour is the same for every Kastel connector. If the record comes back, the mark is lifted on the following pass.
Can an AI change my address book?
No. The connector holds no write operation at all, and it talks to a single server, the one behind folk's interface. When a page of results points somewhere else, it is not followed, which closes the quietest door through which a read could wander off.
What this connector does not do
It does not inherit permissions folk does not expose. folk tells nobody who is entitled to read a record, so everything rests on a group-to-department mapping an administrator writes by hand. An address book where groups serve as personal filing rather than as organisation will produce a lot of records on hold, and that filing is real work.
The description note is free text and it comes in as written. If your team records judgements about people there, they arrive with the record. The connector does not sort the delicate from the harmless inside that field, and claiming otherwise would be false.
folk does not issue read-only API keys. The key you create can technically write to your address book, and what guarantees read-only is that no write operation exists in the connector. We would rather write that distinction down than let you assume the publisher settled it.
folk exposes no workspace identifier, so connecting verifies that the key works without being able to verify that it opens the right address book. And since folk cannot say what has changed since last time, every pass rereads the records in full. A contact added this morning shows up on the following pass rather than the second it is created.
See what the free core holds before paying for anything.
The core of Kastel is free forever in self-host, with every connector and no size limit. The pricing page says where the paid plans start, and a team of five will quickly see it has no need to go there.
See pricing
