> For the complete documentation index, see [llms.txt](https://help.felt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.felt.com/administration/security-and-privacy.md). # Security and privacy Learn how Felt protects your data with encryption and access controls. Read about AI data privacy, data storage, and SOC 2 Type 2 compliance. Every plan includes encryption in transit and at rest, strict employee access controls, and independently audited security practices. Felt has a SOC 2 Type 2 report. ## Felt AI and your data Felt AI runs on frontier models through Amazon Bedrock. Data processed by Felt AI is never used to train models, and none of it becomes public. Felt AI can reach only the data you have access to. See [AI assistant](/felt-ai/ai-assistant.md). ## Where your data is stored and who can see it Felt stores data in the United States by default, and an admin can choose another region for the workspace. See [Regional hosting](/administration/regional-hosting.md). You keep ownership of the data you upload, as section 10 of the [Terms of service](/legal/terms-of-service.md) says. * People see your content only through maps, projects, and data sources they have access to. See [Permissions](/administration/permissions.md). * Felt keeps excerpts of uploaded data, such as 100-row samples and image thumbnails. People who can open a map that shows the data can see them. * Uploaded files and images are stored at addresses that can't be guessed. * Felt employees access customer data only for documented reasons, such as support, and for a limited time. They use individual accounts and multi-factor authentication, and their access is logged for audits. For each user, Felt stores an email address, a name, and a profile picture. For people who log in with a password, Felt also stores the password, encrypted. People who log in only with Google or SSO have no Felt password. For how Felt uses personal data, see the [Privacy policy](/legal/privacy-policy.md). ## Login and account security You can log in with your email address and a password, with Google, or with SAML-based Single Sign-On (SSO) if your workspace sets it up. See [SSO](/administration/sso.md). Felt doesn't offer its own two-factor authentication. When you log in with SSO or Google, that provider handles two-factor authentication. See [Account and login](/getting-started/account-and-login.md). Felt encrypts user credentials at rest and never stores your password in plain text. API tokens for the REST API are stored encrypted, shown in plain text only when you create them, and never logged. You can delete a token at any time. See [REST API](/developers/rest-api.md). ## Infrastructure and encryption Felt runs on public clouds, including Amazon Web Services (AWS), and doesn't operate its own servers. Felt employees have no physical access to the data centers. * All Felt web traffic uses HTTPS with TLS encryption, and Cloudflare protects it against distributed denial-of-service (DDoS) attacks. * Uploads are stored in versioned Amazon S3 buckets with server-side encryption and no public access. Application data is encrypted at rest. * Compute runs in private networks with no SSH access, and AWS compute instances are temporary. Felt monitors access to its services and checks the logs automatically every day. * An independent third party tests Felt's production service for security weaknesses every year. * Felt monitors uptime around the clock. ## Backups and disaster recovery Felt keeps every upload in versioned Amazon S3 buckets, so it can recover the original data after a disaster. It backs up application data daily. Felt runs business continuity and disaster recovery exercises every year. ### Service level agreement {% hint style="success" %} Available on the Enterprise plan. [Talk to sales](https://felt.com/sales) {% endhint %} Felt offers a service level agreement (SLA). For its terms, [talk to sales](https://felt.com/sales). ## Company security practices Every Felt employee uses their own account and multi-factor authentication to reach Felt's systems. Employee computers are managed centrally, with full-disk encryption, automatic updates, antivirus software, and a screen lock. Every new hire has a background check, and every employee completes security training each year. Every code change is tested, including static analysis for vulnerabilities, and approved by another person before it reaches production. Felt keeps documented security policies, including incident response, and reviews them every year. [Felt's security page](https://felt.com/security) lists them. Felt aims to tell customers about any data breach by email as soon as possible. Felt's email uses Domain-based Message Authentication, Reporting, and Conformance (DMARC), which makes it much harder for anyone to send email pretending to be Felt. Felt checks its DMARC settings automatically every day. ## Compliance and certifications Every plan includes Felt's SOC 2 Type 2 controls and GDPR compliance. Felt also has a Data Protection Addendum (DPA) that covers the needs of organizations such as schools, including the Family Educational Rights and Privacy Act (FERPA) and the Children's Online Privacy Protection Rule (COPPA). To request the SOC 2 Type 2 report or the DPA, email . ## Report a security issue Security researchers can report issues to , with a working proof of concept. Felt doesn't run a bug bounty program. For privacy questions, email . --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.felt.com/administration/security-and-privacy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.