Security at Fyle
How Fyle protects your files and accounts: what is in place today, what the system is designed to do as the file service is built, and how to report a vulnerability. Fyle is in development, so we mark every measure with its status rather than claim more than exists.
Last updated
Status at a glance
| Measure | Status |
|---|---|
| TLS on every connection | In place |
| Breach-checked passwords, two-factor authentication, rate limits | In place |
| Organisation security policies (session length, idle timeout, require 2FA, desktop re-authentication) | In place |
| Device sign-in with browser approval; 15-minute signed API tokens | In place |
| Direct-to-storage transfers with short-lived signed requests | By design (file service in development) |
| Immutable versions; conflicting writes become branches | By design (file service in development) |
| Scoped, short-lived agent credentials | By design |
| Full audit log and SIEM export (Enterprise) | Planned |
| SSO (SAML/OIDC) and SCIM (Enterprise) | Planned |
| Cyber Essentials Plus, then ISO 27001 or SOC 2 | Planned; no certification held yet |
How your files move
Fyle separates coordination from file bytes. Our servers decide who may read or write what; the bytes themselves travel directly between your device and object storage.
- To upload or download, a client asks the Fyle API, which checks your permissions and returns a signed request that works for one object, one operation and a short time. File bytes don't pass through Fyle's application servers.
- Signed requests are treated as credentials: they are never logged.
- Storage keys are opaque identifiers, never your file names, and committed versions are never overwritten. A save based on an out-of-date copy becomes a branch for review instead of replacing someone's work.
- Storage credentials stay on our servers and are never shipped in the desktop apps or CLI.
Encryption
- In transit
- TLS on every connection between devices, Fyle and storage.
- At rest
- File content in Fyle-managed storage is held in Cloudflare R2, which encrypts all objects at rest (AES-256, per Cloudflare's documentation). Our database provider, Neon, encrypts data at rest. With your own bucket, encryption follows your provider's settings.
- Secrets
- Two-factor secrets are stored encrypted. Passwords are stored only as salted hashes. Session tokens are kept in HttpOnly cookies and never handed to page scripts.
Accounts and sign-in
- Passwords follow NIST SP 800-63B: 12 to 128 characters, a strength check, and no password that has appeared in a known breach. The breach check uses the Pwned Passwords range API: only the first 5 characters of the password's SHA-1 hash are sent, never the password.
- Two-factor authentication with an authenticator app, plus 10 single-use backup codes. After 10 wrong codes the account's two-factor step locks for 15 minutes. You can trust a browser for 30 days.
- Magic sign-in links are refused for accounts with two-factor enabled, so they can't bypass it.
- Sign-in, sign-up and other auth endpoints are rate limited by client IP.
- Desktop apps and the CLI sign in with a device code you approve in your browser (OAuth 2.0 Device Authorization Grant, RFC 8628). Approval requires a browser session that meets your organisation's policy.
- The Fyle API accepts only short-lived (15 minute) signed tokens, and for writes and storage access it re-checks that the session hasn't been revoked.
Organisation controls
- Roles (owner, admin, billing, member, viewer) decide what each person can do; every action is re-checked on the server.
- Admins can set the maximum session age (1 to 90 days), an idle timeout, how often desktop devices must re-authenticate, and require two-factor authentication for every member.
- Members can see their signed-in devices and sign any of them out.
- Every committed version records who made it: the person, the device and, for agents, the agent session.
AI agents
- Agents are treated as untrusted clients. They use the same permission checks as people; the MCP server has no privileged route.
- Agents run in their own session. Their changes are recorded separately and land by policy; by default, changes to files people own become a branch for review.
- Agent credentials are scoped to a workspace, paths and mode (read, branch-only or direct) and expire quickly. An agent never receives a person's own session.
- Text inside files is treated as data, never as instructions to Fyle's own features.
- Fyle works without any AI feature: if search or agent services are down, the drive still works.
Infrastructure and data location
The website and web app run on Cloudflare. The database is Neon PostgreSQL in London (AWS eu-west-2). File content is stored in Cloudflare R2. The Fyle API will run on Hetzner in Germany or Finland. The full list, with what each provider handles, is on our subprocessors page. Residency options, including UK-only, are on the trust page.
Certifications
Fyle does not hold a security certification yet. Our plan is Cyber Essentials Plus first, then ISO 27001 or SOC 2 as Enterprise customers need them. We will list each one here only once it is awarded.
Reporting a vulnerability
Email security@fyle.sh with a description, steps to reproduce and the impact you expect. Our contact details are also published in security.txt (RFC 9116).
- We will acknowledge your report within [3] working days and keep you updated until it is fixed.
- Test only against your own accounts and data. Don't access, change or delete other people's data, degrade the service, or use social engineering or physical attacks.
- Give us reasonable time to fix the issue before you disclose it publicly.
- If you act in good faith and follow these rules, we will not take legal action against you for your research, and we will credit you if you want.