Security

folo runs many companies on one service. The rules that keep them apart, and that decide what each person's agent may read, are enforced in the database rather than in a prompt.

Layers of protection

Before any of these checks, folo matches a text or call to one member by phone number, and the setup page by your sign-in. A number folo does not know gets a refusal and reaches no agent.

• Company. The company comes from the member folo matched, never from anything the caller sends, and every table refuses rows of other companies.
• Role and grants. They decide which documents and meetings you can read, before any search ranks them.
• Masking. Protected values such as ID numbers, phone numbers and emails are masked unless you may see them.
• Citations. Every point folo gives you must quote a source it was sent. Anything else is dropped.

How folo is built

• Separate stores per service. Each part of folo owns its own data and logs in to the database with its own role, which can read only what that part needs.
• Text from outside is data. Email and document text is passed to the model as quoted data. The model that writes briefs has no tools, so text in an email cannot make it act.
• Secrets stay in one place. Google connections are held by folo's connection provider, and folo fetches a token just before each use. Model provider keys are held only by folo's model gateway.
• Logs carry ids, not content. Error logs record ids and error types, not message text.
• Limits per company. Each company has daily spending limits, so a runaway loop cannot run up unbounded cost.

What leaves folo

Sending on your behalf

Planned folo is designed to send email, invites and texts for you without asking each time. The exception is a recipient nobody at your company has written to before: then folo holds the whole message for a one-tap approval.

Draft: hosting location, certifications, the list of subprocessors by name, and the security review process are not final.