Boring
Context.

Privacy policy.

How Boring Context handles accounts, memories, AI processing and connected sources.

Updated 15 October 2026

1. Who we are and what this policy covers

The individual responsible as data controller for the processing described in this policy is Filip Salomonsson, Boring Context, filip@boringcontext.com. You can also contact us about privacy at hello@boringcontext.com.

This policy covers our website and hosted Boring Context service, including accounts, sign-in, personal and shared project memories, model settings, API keys, connected AI clients and optional data-source integrations. It covers Jira and Confluence, Notion and GitHub, and other sources when an integration is available and you connect it. Connecting a source is optional.

For an independently operated, self-hosted installation, the person or organisation operating that installation is responsible for its own processing. This policy describes the service we operate; it does not determine how a separate installation or an external AI provider handles data.

2. Our role and your organisation's role

We are the controller for operating our own service, managing user accounts, providing support and protecting the service. When the Boring Context team connects and processes content from its own sites and accounts for its own work, Filip Salomonsson is the controller for that processing.

When a separate customer organisation instructs us to process its project content, including its Atlassian content, that organisation is the controller and we act as its processor for that content. That relationship requires a data processing agreement. The organisation determines its purposes, legal basis, authorised users and instructions. We remain the controller for processing whose purposes we determine ourselves, such as our own account administration and support.

3. Data we process

  • Account and authentication data: your Boring Context account identifier, email address, authentication information and sessions. Email sign-up, verification and password recovery are handled through Supabase Auth. If you choose Google sign-in, Google and Supabase process the identity information used for that sign-in, including your email and profile information. Google sign-in does not itself connect Google Drive or Gmail as a content source.
  • Memories and project data: text you submit or import, memory titles and content, categories, project and space identifiers, membership and roles, source links and identifiers, timestamps, versions and deletion history. Content may contain information about colleagues, customers or other people.
  • Model settings and credentials: your chosen model provider, model settings and API keys, including an OpenAI embedding key. Stored model API keys are encrypted. The server decrypts a key when it needs to call the corresponding provider.
  • Connection and import data: the identifiers and names of connected sites, workspaces, accounts or installations, access credentials, selected source objects, synchronisation settings, source modification times and import status. The exact fields depend on the connector; the Atlassian fields are listed below.
  • Operational data: account identifiers, operation and model metadata, timestamps, duration, usage counts and error status used to operate and troubleshoot the service. Authentication abuse prevention also processes network identifiers such as IP addresses, including pseudonymous rate-limit identifiers. Authorised operator reports can associate operational records with the current account email.
  • Communications: your email address and the information you send when contacting us, requesting support or exercising your privacy rights.

We receive data from you, people you collaborate with, your chosen sign-in provider, connected sources and your interactions with the service. An import can contain personal data about people who do not have a Boring Context account.

4. Purposes and legal bases

For processing for which we are the controller, we use data to provide accounts and authentication, store and retrieve the memories you request, make your selected integrations work, provide support, and protect the service from abuse.

We rely on performance of a contract where processing is necessary to provide the service you request as an individual. For secure operation, abuse prevention, troubleshooting, responding to enquiries and necessary collaboration involving other people's data, we rely on legitimate interests in operating a reliable service and helping users maintain relevant project context, subject to their rights and interests. We process data to comply with a legal obligation where an applicable obligation requires it.

Choosing to connect an account authorises the technical connection. It does not automatically establish a lawful basis for every item of personal data in that account. Where your organisation is the controller, it determines the applicable legal basis and instructions. We do not treat OAuth approval as blanket GDPR consent to process other people's information.

5. Optional source integrations

You decide whether to connect a source and which available content to import. Importing content creates or updates memories in the personal space or project you select. Access to those memories follows Boring Context's space membership and role rules. Members with the relevant access can read shared project memories.

Atlassian — Jira and Confluence. We read a Confluence page's title and body text, or a Jira issue's title and description, together with its identifier, link and last modification time. We store the resulting memories and source information. We also store the Atlassian site's identifier and name, and encrypted access and refresh tokens needed to maintain the connection. We do not retrieve Atlassian account profiles, names or email addresses, and we do not import comments or attachments. Names or email addresses can nevertheless occur within the page or issue text you import.

The Atlassian connector reads source content. It does not edit Jira issues or Confluence pages. If automatic synchronisation is enabled, it may register and maintain a Jira webhook so that changes can trigger a synchronisation. This does not give the connector a feature for editing your source content.

The requested Atlassian scopes are read:jira-work, read:page:confluence, read:space:confluence and offline_access. They allow reading accessible Jira work items, Confluence pages and spaces, and maintaining the authorised connection when you are not actively signing in.

Notion. We process the titles and text of the pages you select, workspace and connection information, and source identifiers, links and modification times. Imported pages become memories. Automatic synchronisation is optional.

GitHub. We process information about the selected GitHub App installation and repositories and the selected text sources, such as README and Markdown files, issue descriptions, pull request descriptions and discussion bodies. We store the resulting memories and associated source identifiers, links and modification information.

Other connected sources. Where another connector is available and you enable it, we process the content you select and the connection and source metadata needed for that connector. Google account sign-in and a Google content integration are separate choices. Connecting one source does not automatically connect another.

6. AI processing and embeddings

Source text is sent to the model provider you select when Boring Context's memory-processing functionality creates or updates memories. The request can also include existing relevant memories as context, including shared project memories you are authorised to access. The supported provider choices in the reviewed implementation include Anthropic, OpenAI, Google Gemini and DeepSeek. Source imports use your own configured provider keys.

Memory text and search inputs are also sent to OpenAI to create numerical representations used for similarity search. The embedding model is text-embedding-3-large. Choosing a different provider for memory creation does not replace OpenAI for embeddings. Embeddings are stored with the service's memory data and must be treated as data derived from the underlying text.

When an authorised AI client requests context from Boring Context, relevant memories are returned to that client. The external client and its provider then handle the returned content under their applicable terms and settings.

DeepSeek: if you choose DeepSeek, text and relevant context sent to that provider may be processed and stored in China. Keeping the Boring Context database in Sweden does not keep those model requests in Sweden or the EU/EEA.

Provider retention and any use of submitted content depend on the provider, API product, contract and account settings. OpenAI's published API documentation states that API data is not used for training by default and that default abuse-monitoring retention for embeddings is up to 30 days, with exceptions and eligible alternative controls. We do not promise that all providers have the same policy or that your provider account has zero retention. Deleting a memory in Boring Context does not itself delete a provider's separate retained records. See OpenAI's data controls: https://developers.openai.com/api/docs/guides/your-data.

AI-generated memories can be inaccurate. You can review and correct the memories for which you have editing permissions. The memory functionality organises and retrieves information; it is not a service for making legally significant decisions about individuals.

7. Recipients, storage and international processing

Supabase provides our database and authentication. Our configured primary database location is Stockholm, Sweden. Supabase explains that its core database and backups remain in the selected region, while some support, service metadata and other provider operations can involve processing outside that region.

Vercel provides application and website hosting. Zoho supports our email delivery and communications. Google processes the sign-in information when you select Google sign-in. Source platforms process the API requests needed for their connectors. The model providers described above receive the content needed for the features you use. Authorised team members receive shared content through your project's access rules. We may disclose information where required by law or necessary to respond to a lawful request.

Some of these operations may involve processing outside the EU/EEA, including the United States, and DeepSeek may process and store submitted content in China. The selected Supabase database region is not an EU-only guarantee for the entire service. Using your own API key or choosing a provider does not, by itself, establish a GDPR international-transfer safeguard.

Provider-specific international-transfer arrangements and the applicable safeguards are being verified before this policy can be approved for launch. We have not represented that Standard Contractual Clauses, an adequacy decision or another mechanism covers every provider or transfer. Contact hello@boringcontext.com for the status of that verification.

8. Retention and deletion

  • Active memories: memories remain until a person with the relevant permissions deletes them. Disconnecting a source does not automatically delete its imported memories.
  • Deleted memories: deleted text and its history remain available for restoration in the Deleted area for 30 days. After that period, the scheduled purge removes the expired history from the active database. This period does not describe a provider's independent records or backup rotation.
  • Source connections: access and refresh tokens are removed when the connection is disconnected. You choose whether to keep or delete the memories imported from that source. Deletion follows the memory rules above and the permissions you hold.
  • Accounts: account deletion is currently handled manually. Email hello@boringcontext.com to request it. Shared projects may first need another administrator or an agreed handling of their content so that they are not left without an administrator. This administrative process does not remove your statutory rights.
  • Model API keys: you can remove stored keys through model settings. The reviewed database design also removes the account's stored model keys when the account is deleted.
  • Operational records: the reviewed application retention rules purge detailed usage events after 90 days and daily summaries after 12 months. Those rules do not establish the retention of a hosting provider's own logs.
  • Support and privacy correspondence: we retain information for as long as needed to deal with the request and any necessary follow-up, legal obligation or related claim.

The configured backup retention and the period before deleted information leaves backups have not yet been verified. The 30-day restoration window must not be read as a promise that every backup or external provider copy is erased within 30 days.

Deleting a memory or disconnecting Atlassian does not delete or change the original content in Jira or Confluence. The same separation applies to source content in other connected platforms. Copies already received by an external AI client are handled by that client and its provider.

9. Security

Stored integration access and refresh tokens and user model API keys are encrypted. The reviewed implementation uses AES-256-GCM with server-managed keys, and credentials are decrypted on the server for the requests that need them. Credentials are not returned as memory content or included in normal application response bodies.

Authentication, server checks and database access rules restrict access to accounts and spaces. Membership and roles determine access to shared project memories. Encryption of connection credentials must not be interpreted as a claim that every stored memory is encrypted in the same way.

10. Cookies and website use

The signed-in service uses cookies required for authentication, sessions and security. Google sign-in uses the authentication flow provided by Google and Supabase. The reviewed public landing page does not implement an advertising or analytics tracker in its own source code. Its hosting provider still processes the network requests needed to serve the website. External services and linked websites have their own privacy and cookie practices.

11. Your rights and how to contact us

Subject to the conditions in applicable data protection law, you can request access to your personal data, correction, erasure, restriction and portability. You can object to processing based on legitimate interests. If a specific operation is based on consent, you can withdraw it without affecting the lawfulness of earlier processing.

Send requests to hello@boringcontext.com. We may ask for the information necessary to verify your identity or authority. Where a customer organisation is the controller, we will direct the request to it and assist in accordance with its instructions and applicable law. For requests we handle as controller, we normally respond within one month; a lawful extension may apply, in which case we explain it.

You can complain to the Swedish Authority for Privacy Protection (IMY), https://www.imy.se/, or another competent supervisory authority. You do not have to contact us first.

12. Changes to this policy

The current policy is always available on this page, linked from the footer of every page on our website. We update the date when the policy changes and provide appropriate notice of material changes. If we introduce a new processing purpose, we provide the required information before that processing begins.