Privacy Policy

Effective date: 12 October 2026 - Last updated: 20 October 2026

1. Who we are

Korely is operated by Massimiliano Martella, a sole trader established in Italy ("Korely", "we", "us"), Via della Bastia 15, 40033 Casalecchio di Reno (BO), Italy. Privacy contact: privacy@korely.ai.

Korely offers one product, Korely Agents, a memory service for AI agents, in two forms:

Korely Agents Cloud, which we run: the API and the MCP server at api.korely.ai, and the dashboard at agent.korely.ai.
Korely Agents Self-hosted, which a customer installs and runs on its own infrastructure.

This policy covers the website korely.ai, Korely Agents Cloud, and what we receive in connection with Self-hosted (section 14).

2. Our two roles

We are the controller of the data about you as a customer or a visitor: your account and sign-in, your plan and payments, how you use the service, our security logs, the website, and the messages you send us (section 3).
We are a processor for the content your applications send to Korely Agents Cloud ("Customer Content", section 4): memories, the facts derived from them, and the identifiers your application uses for its own users ("end users"). Customer Content can contain personal data of your end users and of other people. For that data the customer is the controller, and we process it only on the customer's instructions, to provide the service, under our Terms of Service and our Data Processing Agreement, which is part of them and is available at privacy@korely.ai.

If you are an end user of one of our customers, the customer decides what its agents store about you and why. Please contact the customer first. If you write to us, we pass your request to the customer and help it answer.

3. Data we collect as controller

3.1 Your account

You sign in to the dashboard at agent.korely.ai with Google, Microsoft, GitHub, or an email address and a password. Sign-in runs through Firebase Authentication, a Google service. We store:

your email address, which must be verified by the sign-in provider (we refuse an unverified address);
the sign-in method you used;
the identifier Firebase gives to your user;
your plan, the date the account was created and, for an account that started without a login, the date you took it over.

One email address holds one account. When you sign in with GitHub, Firebase does not tell us whether your address is verified, so the dashboard sends us, once, the access token GitHub just gave it, and we ask GitHub whether that address is a verified address of your GitHub user. We do not store or log that token.

Accounts created without a login. A call to POST /v1/agents/init (for example from korely init or from an AI coding agent) creates an account and its first API key, with no email address. For such an account we store the optional label the caller sends (for example "claude-code"), and, for three days, the network the request came from (the IP address for IPv4, the /64 block for IPv6), which we use to limit how many accounts without a login one network can create in a day. When you sign in to the dashboard and adopt the key, that account and your login become one account.

3.2 Dashboard sessions

A sign-in opens a dashboard session of 12 hours. For each session we store a one-way hash of the session token, when it starts and ends, and the IP address and browser user agent of the sign-in. The record is deleted after the session ends. Each sign-in is also recorded in the account's audit trail (section 4) with its time and IP address. That record is kept with the audit trail (section 9), not deleted when the session ends.

Apps connected over OAuth. When you connect an app such as ChatGPT, Claude, Claude Code or Cursor over OAuth, we store the app's registration (its name, its return addresses and the other metadata it sends), each connection request until it is answered (the return address and the app's state value), and the authorization code and refresh token only as a one-way hash. The network address of a registration or of a connection request is kept for one hour, to limit how often one network can register apps, and is then deleted. For an app on your own computer, that address is yours. The record of a connection and of its revocation stays in the audit trail.

3.3 Plans and payments

Payments are handled by Polar, which is the reseller and merchant of record of our paid plans. When you start a checkout we send Polar your email address, the identifier of your account and the plan or top-up you chose; Polar processes that data on our behalf. Polar then collects your name, billing address and payment method on its own pages, as an independent controller under its own privacy policy: your card details never reach us. From Polar we receive the state of your subscription and the plan it is for, and, for a top-up, the order identifier and its currency. We also keep the identifier Polar gives your customer record, so that we can find your subscriptions when Polar attaches a checkout to a customer it already has.

3.4 Usage and limits

To apply the limits of your plan and to protect the service from abnormal costs, we keep:

counters of your account's writes and queries for each month, and short-lived counters per minute, hour and day;
for each call to a language model: the time, the processing step, the model, the provider, the region, the number of tokens, and the agent identifier and memory it was for (never the end user);
for each API key: a one-way hash of the key, its last four characters, its name, its scopes, its plan label and its expiry. The full key is shown once, when it is created, and is not stored.

3.5 Security and request logs

The server that runs the service keeps two technical logs of requests:

the web server's access log, which records for each request the time, the method, the path, the response status and the network data of the request, including the IP address. End-user identifiers in API paths and the values of query parameters are masked before the line is written;
the API's own log, which records the client IP address, the method, the route requested (without its query string and without the identifiers or other values the path carries), and the response status.

Requests to api.korely.ai and agent.korely.ai reach our server directly: they do not pass through Cloudflare. One exception: when you open the Plan page of the dashboard and your account has no active subscription, the page asks korely.ai/geo/country, served by Cloudflare, for your country, to show prices in your currency. That request carries your IP address and browser user agent; it sets no cookie, and we keep nothing of it.

3.6 The website

korely.ai is hosted on Cloudflare Pages. Cloudflare handles every request to it, with your IP address and browser data. Cloudflare Web Analytics measures visits and page loading times with a script that sets no cookie and stores nothing on your device (section 12).

3.7 Messages

Messages you send to a korely.ai address (privacy@, support@, security@ or any other) pass through Porkbun's email forwarding, which sends them on to the operator's mailbox. We keep your message and our reply as long as needed to deal with it and to keep a record of what was agreed.

Korely-specific

4. Customer Content (we process it for the customer)

Customer Content is what your applications send to Korely Agents Cloud through the REST API (/v1), the SDKs, the CLI or the MCP server, and what the service derives from it:

memories: the text, its metadata and timestamps, and the identifiers you attach: end user, agent, run or session, project;
facts: the statements extracted from memories (who or what, the relation, the value, and the dates they hold from and to), and the facts you write directly;
vectors: numerical representations of memories, facts and queries, used for search;
the aliases of names, the relation vocabulary of your account and its examples;
import jobs (/v1/batch) and their payloads;
webhook endpoints and the deliveries to them. A delivery carries identifiers (memory, fact, end user, agent), not the text of a memory;
an audit trail of what each key and each dashboard user did: the action, the time, the end user, and which memories and facts were read or changed, by identifier and count. The audit trail never holds the text of a memory, a fact or a query, and does not record the IP address of API calls; it records the IP address of each dashboard sign-in.

What goes into a memory is the customer's choice. It can include personal data of end users and of other people. Special categories of personal data (for example health data) are allowed when the customer has a lawful basis for them under Article 9 GDPR and has signed our Data Processing Agreement; for such data we recommend the Europe region.

How Customer Content is processed

Storage. Customer Content is stored in our PostgreSQL database on a server of Hetzner Online GmbH in Helsinki, Finland (European Union), for every plan and every region.
Vectors. Search vectors are computed on that same server by EmbeddingGemma, an open model made by Google LLC that runs inside our service. No third party computes or receives them.
Reading a memory with a language model. When a memory is written, the service uses a language model to extract its facts. The model receives the text of the memory; the identifier your application gives the end user the memory is about; up to the ten previous memories of the same end user, each cut to 300 characters, so that a word like "she" or "the same plan" can be resolved; the earlier facts a new fact is compared with, to decide whether one replaces another; and the phrase of a relation that end user has not used before, with a value, to place it in that end user's vocabulary. There is a vocabulary for each end user of a project, learned from that end user's facts alone; an end user's facts and values never reach another end user's prompts. The example value the model reads next to a relation (one line, at most 160 characters) and whether a relation holds one value at a time come from that end user's own facts. Erasing a memory removes the example values its facts alone gave; erasing an end user removes their whole vocabulary. We recommend opaque end-user identifiers rather than names or email addresses. Searches, context requests and every other read do not call a language model.
Which model, by region. Each project has a region, which the customer chooses in the dashboard or when creating the account. Data is stored in the EU in both; choose the Europe region to keep model processing in the EU too.
- Global (the default): Gemini 3.1 Flash-Lite, from Google, through the Gemini API. Google may process and cache the request in any country where it has facilities, including the United States, under the European Commission's Standard Contractual Clauses and, where available, the EU-US Data Privacy Framework.
- Europe (eu): gpt-oss-120b, an open-weights model run by Scaleway SAS on its servers in Paris, France. The model step stays in the EU.
A change of region applies from the next write; that write may include, as context, earlier memories of the same end user written while the project was in the other region. If the provider of a region is unavailable or paused, the memories of that region wait in the queue: they are never sent to the provider of the other region.
What the model providers keep. Google, under its Gemini API terms, does not use prompts and responses to improve its products, and keeps prompts, context and responses for 55 days to detect and prevent violations of its Prohibited Use Policy; content its systems flag may be reviewed by authorised Google staff. Scaleway applies zero data retention by default: it does not store prompts or responses, except the full content of a request that causes an abnormal error (for example an HTTP 500) or that Scaleway detects as malicious, which it may keep temporarily to investigate (up to two weeks for an error). Scaleway does not use the content to train models, and the makers of the model have no access to it.
No training by us. We do not use Customer Content to train or improve any model, and we do not use it for advertising, for profiling, or for any purpose of our own.
Where it goes on the customer's instruction. Webhooks send events to the addresses the customer registers. An MCP client, or any application holding one of the customer's API keys, reads what that key can read. Those destinations are chosen and controlled by the customer; they are not our sub-processors.
Who at Korely can see it. Only the operator, Massimiliano Martella, has access to the production server, also through automated tools he uses, and only for maintenance, security and support.

5. Why we use personal data, and on which legal basis

Under Article 6 GDPR we rely on these legal bases:

Create and run your account, sign you in, keep your session (3.1, 3.2): performance of a contract (6(1)(b)).
Provide the memory service and apply the limits of your plan (3.4, section 4): contract; for Customer Content, the customer's instructions as controller (Article 28).
Take payments, keep your plan in step with Polar, keep business records (3.3): contract; legal obligation (6(1)(c)) for accounting and tax records.
Limit accounts created without a login and protect the service from abuse (3.1, 3.5): legitimate interest (6(1)(f)) in keeping the service available and its costs bounded.
Protect the service from abnormal model costs, with an emergency stop (3.4): legitimate interest.
Security, troubleshooting, and proof that an erasure took place (3.5, section 10): legitimate interest; accountability (Articles 5(2) and 17).
Deliver the website and measure its audience without cookies (3.6): legitimate interest.
Answer your messages (3.7): contract or legitimate interest.

We do not sell personal data and we do not use it for advertising. The service sends you no email of its own: sign-in emails (address verification, password reset) come from Firebase, and receipts and invoices from Polar.

6. Automated processing

Fact extraction, the comparison of facts and the search are automated. Korely takes no decision about you that produces legal or similarly significant effects (Article 22 GDPR). What a customer's agent does with the facts it reads is decided by the customer. Facts extracted by a language model can be wrong or incomplete: the customer can read, correct and delete them through the API and the dashboard.

7. Who receives personal data

Sub-processors: the providers that help us run the service, listed with what they receive, where, and under which terms at korely.ai/subprocessors.html, which is part of this policy. In short: Hetzner (hosting, Finland), Google (Gemini API for Global projects; Firebase Authentication), Scaleway (language model for Europe projects, France), Cloudflare (website, DNS, encrypted backups), Polar (payments), Resend (alert emails to our operator only), Porkbun (forwarding of email sent to korely.ai addresses), Loops (contacts of people who joined our waitlist).
Polar, for what it collects at checkout, as an independent controller (3.3).
Sign-in providers: when you choose to sign in with Google, Microsoft or GitHub, that provider confirms your identity under its own terms and privacy policy, as an independent controller.
Authorities, when the law requires it, and a buyer of the business, under this policy.

8. Transfers outside the European Economic Area

Some providers are established in, or process data in, the United States: Google (the Gemini API for projects in the Global region, and Firebase Authentication, which processes data only in the United States), Polar, Resend, Porkbun and Loops. These transfers rely on the European Commission's Standard Contractual Clauses and, where available, on the EU-US Data Privacy Framework.

Customer Content is stored in the EU in every case. A project in the Europe region keeps the language-model step in the EU as well; sign-in and payments still involve the US providers above.

9. How long we keep data

Account data (3.1): while the account exists; deleted when it closes (section 10).
Network of an account created without a login (3.1): three days.
Dashboard sessions (3.2): until the session ends (12 hours), then deleted within about an hour.
Per-minute, hour and day counters (3.4): about two hours after their minute or hour ends; a day counter about two hours after the end of its UTC day.
Monthly usage counters: 13 months, the current month and the twelve before it.
Records of language-model calls: 400 days. They never name the end user. When an account closes they lose the agent and the memory, keep only the day, and stay until the 400 days run out, as the record of what the service spent.
Audit trail, including the IP address of each dashboard sign-in: 400 days, or until the account closes.
Records of forgetting and erasing (the audit identifier, the end-user identifier, replaced by a keyed pseudonym once that end user is erased, the kind of operation, the counts and the date): until the account closes.
Apps connected over OAuth (3.2): the network address, one hour; connection requests and authorization codes, one day after they are used or expire; a refresh token, at most 90 days, deleted one day after it is used or expires; an app's registration, one day after its access is revoked or after it stops renewing its access.
Finished webhook deliveries: 30 days.
Finished import jobs, with their payloads: 7 days.
Payment events received from Polar: 90 days.
Customer Content: until the customer erases it or closes the account (see below).
Erasure record (section 10): 10 years, then deleted.
Business and accounting records: 10 years (article 2220 of the Italian Civil Code).
Backups: encrypted copies of the database are made every night and kept for 35 days; for the first 30 days nobody, us included, can delete them. Data erased from the live database leaves the backups within 35 days.
Sign-in data at Firebase: until the account closes; Firebase keeps logged IP addresses for a few weeks, and removes a deleted user from its live and backup systems within 180 days.
Web server access logs: rotated at 10 MB; at most five old files, each kept at most seven days.
API log: at most five files of 20 MB, replaced when the service is updated; how many days that covers depends on traffic.

Korely-specific

Forgetting and erasing Customer Content

Erasing deletes the data. DELETE /v1/users/{end_user_id}/memories erases every memory and fact of one end user in the key's project, including replaced facts and import items still in the queue. DELETE /v1/agents/{agent_id} erases everything written under one agent identifier. Deleting a project with erasure erases everything the project held, and counts as erasing each of its end users: what stays of them is what stays of an erased end user, below. Closing the account erases everything. DELETE /v1/memories/{id}?erase=true erases one memory, its text, vector and the facts only it stated, including a memory forgotten earlier. Each erasure returns an audit identifier, and its record keeps counts, never the content. Erasing a project returns one, for the project, and files a record under the pseudonym of each of its end users.
What stays of an erased end user. In the erasure record and in the audit trail, a keyed pseudonym in place of their identifier (an HMAC computed with a key derived from our service secret), which lets the customer prove the erasure by looking it up with the identifier; in webhook deliveries, the same pseudonym once they are finished (a delivery still pending at the erasure goes out with the identifier the customer's endpoint knows, and takes the pseudonym when it is delivered, given up or dropped), until they expire. The records of language-model calls never name an end user, so nothing of them stays there. The pseudonym is still personal data, in pseudonymised form: it is not anonymous.
Forgetting does not delete the data. DELETE /v1/memories/{id} and forgetting or correcting one fact take the memory or the fact out of every default read, and the facts that only that memory stated stop being current. The rows stay in the database as history (replaced facts remain readable with include_invalidated=true) until an erasure (DELETE /v1/memories/{id}?erase=true for that memory alone) or the closure of the account removes them. To answer an end user's request to be erased, use an erasure.

10. Closing your account

You close your account from the dashboard (the Account page, "Close the account", confirming with your email address) or, for an account created without a login, with DELETE /v1/account?confirm=true. The closure takes effect at once:

your Firebase user is deleted;
every row of the account is deleted from the live database: memories, facts, vectors, API keys, projects, sessions, webhooks, the audit trail, usage counters and top-ups;
your customer record at Polar is deleted with its personal data anonymised, which also ends any subscription immediately, with no refund of the current period, without prejudice to the statutory rights of consumers. One exception: if Polar attached your checkout to a customer record it already had under another identifier (for example from an earlier purchase with the same email address), we do not delete that record, because it may not belong to this account alone; we end this account's subscriptions, and our operator is alerted to review the record by hand.

If deleting the Firebase user or the Polar customer fails, our operator receives an alert and completes it by hand. What stays after the closure: the erasure record (the account's random identifier, a keyed hash (HMAC-SHA256, under a secret key we hold) of its email address and of its Firebase user identifier, the number of rows deleted per table, the date, and whether the dashboard or the API closed it), which we keep for 10 years to prove the erasure and to refuse a sign-in token issued before the closure; the anonymised records of language-model calls; the backups, for up to 35 days; Firebase's copies, removed within 180 days; the request logs, as in section 9; and Polar's own records as the seller. The hashes in the erasure record are pseudonymous personal data, not anonymous data; records made before 17 October 2026 hold an unkeyed SHA-256 hash instead.

11. Your rights

Under the GDPR you can ask us for access to your personal data, its correction, its erasure, the restriction of its processing, and a copy in a portable format; you can object to processing based on our legitimate interests; and where we rely on your consent you can withdraw it at any time. Write to privacy@korely.ai. We answer within one month (Article 12(3) GDPR) and may ask you to confirm your identity. You can also close your account yourself at any time (section 10), and read Customer Content through the API, page by page through its list routes (for example GET /v1/memories and GET /v1/facts), and in the dashboard. There is no single export file.

Requests about Customer Content are handled by the customer, who is its controller: we pass them on and help the customer answer.

You can lodge a complaint with a supervisory authority. In Italy it is the Garante per la protezione dei dati personali (garanteprivacy.it); in the United Kingdom, the Information Commissioner's Office (ico.org.uk). We would appreciate the chance to answer your concern first.

Data Protection Officer. Korely has not designated a Data Protection Officer under Article 37 GDPR: the criteria are not met at its current scale. privacy@korely.ai is the contact for every privacy matter.

12. Cookies and similar technologies

korely.ai. Our pages set no cookies. Cloudflare, which hosts the site, may set a strictly necessary security cookie on some requests. Cloudflare Web Analytics loads a script from static.cloudflareinsights.com that sets no cookie, uses no local storage, and reports page views and loading times in aggregate. The documentation pages remember, in your browser's local storage, the code language tab and the light or dark theme you pick. One blog article loads a library for mathematical notation (KaTeX) from the jsDelivr CDN, which receives your IP address when you open that article.
agent.korely.ai (the dashboard). No cookies and no analytics. The dashboard keeps in your browser's local storage the session token, the email address and identifier of your account, the project you have open, your theme, and whether you skipped the setup screen. Signing out removes the session. Firebase keeps nothing in your browser after you sign in. Signing in with Google, Microsoft or GitHub opens a window served by Google Firebase and by the provider you chose, under their own policies.
Checkout takes place on Polar's own domain, under Polar's policies.

What we store on your device is strictly necessary to provide the service you ask for, or a preference you set, so we ask no consent and show no banner. The Cookie Policy gives the details.

13. Age

Korely Agents is a service for developers and businesses. You must be at least 18 years old to use it. We do not knowingly collect personal data of children.

Korely-specific

14. Korely Agents Self-hosted

We do not host, receive or see the data of a Self-hosted installation. The software sends nothing to Korely: no telemetry, no licence check, no usage report. An installation sends text only to the language-model provider its operator chooses, with the operator's own key; with local embeddings, the default, its search vectors are computed on its own machine. Its dashboard contains links to pages of korely.ai, which your browser opens only if you click them.

We process personal data for Self-hosted only when you contact us, buy it or ask for support: names and business contact details, contract and invoicing data. If you give us access to an installation or send us data for support, the separate written agreement for Self-hosted governs that processing.

15. Security

Every connection is encrypted with TLS.
The database and the API are not reachable from the internet except through our web server.
API keys and session tokens are stored only as one-way hashes.
Each account's data is separated from every other account's, and each key reads only its own project.
The database and its backups are encrypted at rest. The database is on an encrypted volume (LUKS2, AES-XTS with a 512-bit key) at Hetzner in Helsinki. The nightly backups are encrypted with age on our server before they leave it, with a key that is not kept on the server, and stored in a Cloudflare R2 bucket under the EU jurisdiction.

No method of transmission or storage is completely secure. If a personal data breach occurs, we notify the supervisory authority and the people concerned as the law requires, and we notify customers about breaches affecting Customer Content under our Data Processing Agreement.

16. Other jurisdictions

United States. In the last 12 months we have collected these categories of personal information: identifiers (email address, account identifier, IP address); commercial information (plans and payments); internet activity (use of the service and the website). We do not sell or share personal information for cross-context behavioural advertising. We do not respond to "Do Not Track" signals, because we do not track visitors across sites. Residents of states with privacy laws can exercise their rights to know, correct and delete at privacy@korely.ai, and we will not discriminate against anyone for doing so.

Elsewhere. If you live in a jurisdiction not named here, write to privacy@korely.ai: we answer every lawful request to the GDPR standard, within one month or any shorter local deadline.

17. Changes to this policy

We publish every change on this page with a new date. Before a significant change takes effect we announce it on this website and by email to the accounts that have an email address, at least 30 days in advance for business customers.

Contact Us

For any questions or concerns regarding your privacy, you may contact us using the following details:

Korely Privacy Team
Email: privacy@korely.ai
Data Controller: Massimiliano Martella (sole trader)
Address: Via della Bastia 15, 40033 Casalecchio di Reno (BO), Italy

This Privacy Policy was generated using GetTerms.io as a base template and customised with Korely-specific clauses (highlighted in indigo) for accurate disclosure of our memory service, AI processing and data handling.

← Back to Korely