Where it runs
Filo runs on Google Cloud in the us-central1 region, on Google Kubernetes Engine. Production and staging are separate environments with separate databases, separate credentials and separate domains. Storage for files and logos uses Google Cloud Storage buckets that are private to the environment. Traffic to filoagent.com is encrypted in transit with TLS, and data at rest is encrypted by Google Cloud. The services run as workload identities with the least access each needs, and secrets such as signing keys and provider API keys are held in the cluster's secret store, not in code or images. Deploys go from a reviewed branch through a build pipeline; nothing is built or uploaded from a laptop. Filo's database is MongoDB, which we run ourselves on that cluster, so no database company holds your data. It is backed up daily.
Accounts
Everyone who uses Filo signs in. Passwords are hashed and never stored in the clear. A password sign-up is verified by a code sent to that email before the person can connect anything. Google and Microsoft sign-in are available and are verified by the provider. Each workspace has owners, admins and members, and a disabled or removed person is turned away on their next request, not their next token. The people who can administer the Filo platform itself are listed in code, by email, and nothing in a setting or environment variable adds to that list. Platform administration is limited to the people who run Filo and is used for account support, model settings and cost reports, never to read a customer's chats or files without that customer's consent.
Sign-in tokens are short-lived and refreshed, and signing out ends the session on every device. If you think an account has been compromised, an owner or admin can disable it at once and write to security@filoagent.com.
Your data
Every record, file and chat belongs to one account, and one company's data is never visible to another. Files you drop into Filo go to private storage and can be read only by the person who uploaded them, in that workspace. Tokens for connected systems such as Google, Slack and Fiddle are encrypted with a key kept outside the database. Connections to those systems are made by a person with their own account and can be revoked by that person at any time. The companies that process data on our behalf are listed on our sub-processors page.
Filo keeps a history on every record it changes: the previous value, who changed it, from which chat and which files were in that chat. That history is how an undo works and how you answer a question later about where a number came from. It supports your audit trail; it does not replace your quality system.
When a workspace is closed, its data is exported on request and then deleted from our active systems, with backups rolling over afterward. Our privacy policy gives the timelines.
What Filo can and cannot do
Filo sends email only from your own mailbox, and only after a person in your workspace approves each message. It never emails a supplier on its own. It writes to your systems only as the person who connected them, and never moves a record between systems unless you ask it to. It never releases a lot and never places an order.
Every write Filo makes is recorded with who made it, from which chat and when, and anything Filo added can be undone. Every agent turn is saved step by step, so a restart or deploy never repeats an action that changed your records.
Apps
Apps that Filo builds for your floor run inside a sandboxed frame on a separate origin from the Filo app. An app can call only Filo's own functions, the same ones the agent uses. Apps never see credentials and never reach Google, Fiddle, Slack or any other system directly. Everything an app records links to a real record in your workspace.
AI
Filo uses models from Anthropic, OpenAI, Google (Gemini), DeepSeek and OpenRouter. Which provider is used is set by the platform admin, and your content goes to that provider under its API terms, which do not allow it to be used for training. We log each call's size and cost, not its content.
Account emails, verification codes and notifications go out through Resend from filoagent.com. Emails that Filo drafts for you, such as a request to a supplier, go out from your own mailbox, never from ours.
What we do not have yet
We do not yet have a SOC 2 report. We have not yet had an independent penetration test. We plan both and will put dates here once they are set. We also do not yet offer single sign-on through SAML or a customer-managed encryption key. If any of these is a requirement for you, tell us; it helps us order the work.
The desktop app
The macOS desktop app is signed and notarized with our Apple developer identity, and it updates itself from a feed we publish. Nothing unsigned is ever published. The app talks only to the Filo API for the environment it was built for, and apps built for your floor load only from the content origin that environment expects. A Windows build will follow the same rules once its signing is in place.
Reporting a problem
If you find a security problem in Filo, write to security@filoagent.com. We read every report and reply within two business days. We do not run a bounty program yet, but we credit people who report responsibly if they want to be named. Please do not test against other customers' data or run anything that degrades the service.