Myrmigo Privacy Policy

What changed on 2 October 2026: we added our page for business owners (sections 1, 4.7 and 9); what our reference data says about businesses, which can include a sole trader’s details, and how long we keep it (sections 4.7, 4.12 and “Retention at a glance”); and GitHub, where we keep our code and reference data, as a recipient (sections 5 and 6). The earlier version took effect on 1 October 2026; we send it to you on request (section 13).

In short

• Myrmigo gives AI agents reference information about travel websites. It does not need to know who you are.
• We never store the goal text your agent sends. Through the service, we do not ask for or store travellers’ names, booking codes, email addresses, phone numbers or card numbers. If you email us, section 4.11 applies.
• When a web address is sent to us, we drop its query string (everything after the “?”) and its fragment (everything after the “#”).
• Before we store any report, we scrub it to remove information about the traveller, and we reject reports that seem to contain card, bank, passport or secret data.
• There are no cookies, trackers, analytics tools or ads. For usage statistics, our server keeps only daily totals that identify no one (section 4.13).
• We do not sell personal data. Nobody can pay for a higher ranking.
• The service runs on Fly.io in Frankfurt, in the EU. Fly.io and Vercel (which hosts our website) are US companies. Your connection may first reach their servers outside the EU, and some of their logs and backups may be kept outside the EU. See section 6 on transfers.

1. Who we are

The controller of your personal data is:

• Christos Christoforidis
• Postal address: Paros 844 01, Greece
• Email: admin@paros-summer.com. Use this address for privacy questions, requests about your rights, support and security reports.

In this policy, “we”, “us” and “Myrmigo” mean Christos Christoforidis. Because we are established in Greece, in the EU, we have no representative under GDPR Art. 27.

We have not appointed a Data Protection Officer, because the GDPR does not require one for Myrmigo (Art. 37(1)): we are not a public authority, our core activities do not involve regular and systematic monitoring of people on a large scale, and we do not process special categories of data, or data about criminal convictions, on a large scale. For any privacy question, write to admin@paros-summer.com.

This policy covers:

• the website myrmigo.com;
• the service at mcp.myrmigo.com. That includes the MCP endpoints /mcp and /agent/mcp, the REST API under /v1/, and the web pages /register, /flag and /owner (in Greek at /el/owner).

Organisations that use Myrmigo through an API key are controllers in their own right for their own users’ data, separate from us. Their own privacy notices apply to that data.

This policy is written in English. We may publish a Greek version later. If we do and the two versions differ, the version that is more favourable to you applies. You can write to us in Greek or English.

2. What Myrmigo is

Myrmigo is a reference service for AI agents. These agents help people with tasks on their own travel bookings, such as:

• changing or cancelling a flight, ferry, hotel stay or vehicle rental;
• checking in or getting a boarding pass;
• adding bags or seats;
• asking for a refund.

An agent asks Myrmigo about a task on a website. Myrmigo tells it:

• the official site and the page to start from;
• the fees and rules that apply, with their dates and sources;
• what the traveller needs to have ready;
• where the traveller has to act in person.

For some sites, Myrmigo also returns step-by-step guides. It does this only where the site’s owner has consented, or where the site’s terms allow it.

What Myrmigo does not do:

• Myrmigo’s servers never visit travel sites for you.
• Myrmigo never makes bookings or payments.
• Myrmigo’s server does not send your requests to any AI model provider.

Your AI agent works in your own session. Your AI assistant, for example Claude or ChatGPT, is run by its own provider under that provider’s privacy policy. You stay in control of signing in, identity documents, payment and final confirmation.

There are two ways to use Myrmigo:

• Reference surface: /mcp, POST /v1/reference and the public GET endpoints. It is anonymous and needs no account.
• Agent surface: /agent/mcp, /v1/route and /v1/runs. It is for organisations that hold an API key from us.

3. What we do not collect

• Your goal text. An agent can send a short description of what the user wants. We use it in memory to answer that one request. We never store it and never log it.
• Travellers’ details. This means names, booking codes, email addresses, phone numbers, card numbers, and passport or ID numbers. Our agent-surface tools tell agents not to send them, and we do not store them.
• Query strings, fragments and login details in web addresses. We drop these as soon as the request arrives. The only thing we read from the query first is a language setting, such as ?lang=el. We use the page path to answer the request, and we never store it. Vercel’s logs for myrmigo.com may record query strings (section 4.9).
• The words of your request. We store only our own task category, such as flight.change, or the word “unknown”.
• IP addresses in the service’s database or application logs. The service at mcp.myrmigo.com never writes them there. To limit abuse, it keeps counts per IP address or network in the server’s memory, under a keyed hash (section 4.5). Most are deleted within about a minute after their minute or UTC day ends; failed sign-in counts for our staff page stay until the server restarts. Our hosting providers keep their own logs: Vercel’s logs for myrmigo.com include IP addresses, and Fly.io’s may too (section 4.9).
• Your browser’s user agent. The service at mcp.myrmigo.com does not read it. Vercel’s logs for myrmigo.com record it (section 4.9).
• Cookies and similar technologies. Neither myrmigo.com nor mcp.myrmigo.com sets cookies or uses local storage. The website runs no scripts. We use no analytics tools and no tracking pixels. For usage statistics, our server keeps only the daily totals in section 4.13, which identify no one. Our fonts are served from our own site, so your browser sends no request to Google. If we ever want to store or read information on your device that is not strictly necessary for a service you asked for, we will ask for your consent first and update this policy before we do.
• Traveller accounts. Travellers do not need an account, and we do not offer one.

4. What we collect, why, and for how long

No law or contract requires you to give us personal data. Your IP address is needed technically for our servers to answer you. An API key is needed only for the agent surface.

When we rely on legitimate interests (GDPR Art. 6(1)(f)), we name the interest, and you can object (see section 8).

How deletion works. Deletion, and the replacement of names with keyed hashes (section 4.8), run automatically when the server starts and then every 6 hours. So data can stay up to 6 hours longer than the periods below. Depending on the record, a period given in days counts either whole days in UTC or full 24-hour days from the time of the event. Section 4.10 explains what happens to deleted data in database files and snapshots. Our mailbox is not cleaned automatically: we delete old emails by hand, in a clean-up we run twice a year (sections 4.6 and 4.11).

4.1 Requests to the service (both surfaces)

• What: the task (free text or a task id), the site or web address, where the trip was booked, the goal, and a guide or task id.
• Why: to work out the task, find the site, pick the language and answer the request.
• What we keep: nothing from the request itself, apart from the daily totals in 4.13. We keep only the items in 4.2, 4.3 and 4.13, and the short-lived counts in memory described in 4.5.
• Legal basis: legitimate interests, namely answering the request the agent made.
• How long: only while the request is handled.

4.2 Coverage gaps (both surfaces, including anonymous use)

When we cannot fully answer a request, we record a coverage gap. The record holds:

• the site, up to 120 characters: our site id; the registered domain only (for example example.com); *. plus the hosting suffix, for a site on a shared hosting domain (for example *.github.io); or “unknown”;
• the task id, or “unknown”;
• how well the request matched a guide;
• which surface was used;
• the language of the request, which we detect automatically;
• the interface language taken from the web address;
• the day;
• a count.

It holds no IP address, no organisation and no words from the request. We never store the page path.

• Why: to decide which sites and tasks to cover next.
• Legal basis: legitimate interests, namely improving coverage.
• How long: 365 days.
• Note: this is normally not personal data. But a domain can sometimes relate to a person, for example a family-name domain.

4.3 Run handles (agent surface only)

On sites with step-by-step guides, we create a short-lived “run handle” when a keyed agent asks about a task. It lets us match a later outcome report to the guide we served. It holds:

• a random run id and the id of the organisation that holds the API key;
• the site, the site that services the booking, the task and the guide version;
• how well the request matched;
• the languages;
• the handle’s state;
• timestamps to the millisecond.

It holds no traveller data and no goal text.

• Legal basis: legitimate interests (GDPR Art. 6(1)(f)), namely linking outcome reports to the guide we served.
• How long: 48 hours.
• Today: step-by-step guides are live only on sites whose owner has given written consent. Our internal test sites are not loaded on the production service.

4.4 Outcome reports and flags

Status today. The service at mcp.myrmigo.com stores no outcome reports and no flags. It refuses them from customer API keys, and anonymous flags are switched off. The code accepts them only from Myrmigo’s internal test accounts, and only about our made-up test sites, never about a real website. We will update this policy before we switch reports or flags on. The rest of this section describes how they work once they are on.

Outcome reports (report_task_outcome or POST /v1/runs):

• Each report holds:
  • the organisation id and the report’s source;
  • the runtime type (local, cloud or unknown, taken from the Myrmigo-Runtime header);
  • the site, task and guide version;
  • the outcome and whether the guide was followed;
  • the failure reason, the failed step and any concern;
  • the day.
• Every field is picked from a fixed list or checked against a format. We do not keep the run id. Kept 30 days.
• Daily totals per guide version: successes, failures and the number of organisations, with no organisation id. Kept 180 days. These are not personal data.
• Concerns raised in a report go to a staff review queue. Kept 90 days.
• Step corrections are only accepted when that feature is switched on. They are scrubbed, seen only by staff and never shown to other users. Kept 90 days. While we accept them, we keep each run’s scrubbed lines in memory to check resends. We clear them after 10 minutes at the earliest: when a later report arrives, or when the server restarts.

Scrubbing. Before we store a report, we scrub it:

• We reject the whole report if it seems to contain a card number, an IBAN, passport data or a secret such as an API key.
• We replace emails, phone numbers, strings shaped like booking codes, dates and amounts with placeholders.
• We drop lines about sensitive topics, such as health, disability, diet, religion, pregnancy, bereavement, legal matters, infants and unaccompanied minors.

Flags (POST /v1/flags, the /flag page, or a report without a run id):

• A flag holds the site, the task (or “any”), the guide version, a concern chosen from a fixed list, the organisation id (or “anon”) and the day. There is no free text.
• Kept 90 days.
• Flags go to staff review. They never change a guide by themselves.

Why: to measure how well guides work and to fix broken or unsafe guides.

What other agents see. Totals made from outcome reports are shown to every agent that gets the guide. Once a guide has at least 10 reports counted, they show its success rate, the confidence range of that rate, the number of reports and the number of organisations (shown as “<3” below three). They also show whether the guide is marked as failing, which happens automatically when 2 or more organisations fail at the same step within 7 days. These totals also affect how guides are ranked (see our Terms of Use, section 3). They never include an organisation id. Other agents never see your reports or which organisation sent them.

Publishing and licensing totals. We may publish or license the daily totals, which contain no personal data. We publish or license daily totals only when they combine reports from at least 3 organisations, so that no single organisation can be picked out. We never publish or license individual reports or flags.

Legal basis: legitimate interests, namely keeping guides accurate and safe. We do not rely on consent today.

4.5 IP addresses and rate limiting

Our host, Fly.io, passes us your IP address.

• Anonymous calls: we use your IP address only while we handle the request, except in the cases below.
• Flags and the site-owner endpoints: to limit abuse, we count your requests in the server’s working memory. The limits are 10 flags a minute and 100 a day, and 30 owner requests a minute and 300 a day. For callers with an API key, the flag limits apply per organisation instead.
• Anonymous questions (finds): to keep the service available for everyone, we count finds per network in the server’s working memory: your IPv4 address, or the first half of your IPv6 address. Finds that arrive from the published network addresses of AI companies’ hosted connectors (for example Claude’s or ChatGPT’s) are counted separately, as that company’s traffic rather than yours. While the server is overloaded, we also count finds per wider network (the first three numbers of an IPv4 address, or the first three of the eight groups of an IPv6 address).
• Flight compensation checks (section 4.14): we count checks per network in memory, to allow 10 checks a minute and 100 a day. For callers with an API key, these limits apply per organisation instead. Checks that arrive from AI companies’ hosted connectors are counted as that company’s traffic, as for finds.
• Our staff sign-in page (mcp.myrmigo.com/admin): to stop password guessing, we count failed sign-in attempts per network in memory (your IPv4 address, or the first half of your IPv6 address). After 5 failures in 15 minutes, that network has to wait.

What happens to these memory entries:

• We never write them to our database or logs.
• We do not keep the IP address or organisation id itself. Each count is kept under a keyed hash (HMAC) of it, made with a random key that exists only in the server’s memory. For the rate limits, that key is replaced at the start of every UTC day.
• A rate-limit count is deleted within about a minute after its minute or its day (UTC) ends.
• The sign-in counts stay until the server restarts, or until 10,000 of them build up and the table is cleaned.
• The operating system may move this memory, including the keys, to the server’s disk (swap).

Legal basis: legitimate interests, namely security and preventing abuse (GDPR Recital 49).

4.6 Organisations and API keys

Organisation record:

• an account id: org- plus 10 random characters, which say nothing about the organisation (staff can set another id by hand, and accounts created before 25 September 2026 may have an id made from the organisation’s name);
• the name, account type and tier;
• an optional affiliation;
• the version of the terms accepted;
• the day created and the day deleted.

API keys:

• A short prefix is stored in clear to identify the key, for example mrm_live_ plus 8 characters.
• The full key is stored only as a keyed hash (HMAC-SHA256 with a secret). Our service never stores or logs the full key.
• We send the full key once, by email, to the person who asked for it, in a message of its own. We delete our copy of that message from our mailbox, including from its Trash, straight after sending it. If a key is lost, we issue a new one.
• We also store the key’s scopes, its creation and revocation days, and any rotation link.

Contact people. Organisations ask for an API key by email to admin@paros-summer.com. We receive the name and work email of the person asking, and of any other contact the organisation names. We keep them only in our mailbox (section 4.11), never in the service’s database, and use them to send the key, service and policy notices, and security alerts. We keep them while the account is open and for 24 months after it closes. We delete them in the clean-up of our mailbox that we run twice a year, so they can stay up to 6 months longer. If your organisation gave us your details, see section 4.12.

Details:

• Why: to provide the agent surface, check keys, and record which terms were accepted.
• Legal basis: where the key holder is an individual, such as a sole trader, our contract with them (GDPR Art. 6(1)(b)). For people who act for an organisation, legitimate interests (Art. 6(1)(f)), namely running the agent surface and managing our relationship with the organisation.
• Do you have to give this? Only if you want the agent surface. The reference surface needs no key.
• How long: while the organisation’s account is open. We delete a revoked key 30 days after it stops working. When a key is rotated, the old key keeps working for 7 more days, so we delete it 37 days after the rotation. When the account closes, we delete the records as described below.
• When an organisation is deleted:
  • We delete its keys, run handles, outcome reports and flags.
  • We replace its name with “(deleted)” and remove the affiliation.
  • We keep a stub record with the account id, account type, tier, terms version and the days created and deleted, and audit log entries that name that id (after 365 days, only as a keyed hash). An id set by hand, or one created before 25 September 2026, can come from the organisation’s name and so reveal it.

4.7 Site owners (Owner Shield)

Domain claims:

• Anyone can start a claim for a domain. We store nothing until the claim is verified: the verification token we send back carries its own expiry (72 hours) and our signature, so we need no record of it.
• To check the claim, we make one DNS lookup for a TXT record at _myrmigo.<domain>. We never fetch the site.
• An unverified claim is not stored. Before our update of 26 September 2026, starting a claim also stored the domain for up to 72 hours and wrote an audit log entry with a keyed hash of the domain and the time. We hold the key, so we could match that hash to a domain we already know. Those entries are kept as long as the audit log (section 4.8).
• A verified claim holds the domain, a keyed hash of the claim token, an owner record named after the domain, the verification method and the day. The audit log names the domain in clear for 365 days, and after that only as a keyed hash (section 4.8). We keep a verified claim until the owner asks us to remove it or we revoke it. We then keep it for 365 days, and then delete it and its owner record. There is no self-service removal yet. Write to us to have it removed.
• Owner tokens are not stored. We derive them when they are needed.
• You can also claim a domain on our page for business owners, https://mcp.myrmigo.com/owner, where the verification token is called a “claim code”. It works as described above. When you type a web address on that page to see what we tell AI agents about it, we use it only to answer that request: we do not store it, log it or count it as a question to Myrmigo.

Opt-outs:

• An opt-out records the site, the task, whether the site owner, our staff or a legal takedown set it, the reason, and when it took effect or was lifted.
• Owners pick the reason from a fixed list. Staff actions, such as a legal takedown, can have a free-text reason.
• We keep opt-outs while they are in effect. After an opt-out is lifted, we keep it for 365 days as evidence that we honoured it, and then delete it. We keep legal takedowns while they are in effect and, after they are lifted, until the limitation period for legal claims about them ends (the general period under Greek law is 20 years: Greek Civil Code Art. 249), as evidence, and then delete them.

Owner consent to step-by-step guides:

• A consent records the site, the tasks, the modes, the name of the person who signed, the agreement reference and the dates.
• It is also recorded in the audit log.
• We keep it for the term of the consent and then until the limitation period for legal claims related to it ends (the general period under Greek law is 20 years: Greek Civil Code Art. 249), as evidence, and then delete it.

Businesses in our reference data:

• Our reference data describes businesses, such as a vehicle rental or a hotel: the business’s name, its official website and pages (for example its booking and contact pages), its official agent channels (such as an MCP server or an API), its office contact and dated facts with their sources. We take these from the business’s own public website, or from its verified site owner. A person on our staff checks them on the business’s own website before we use them.
• Where an individual runs the business, for example a sole trader, some of this can be personal data: the business’s name, and its phone number, WhatsApp number or email address when the business publishes them on its own website or its verified site owner asks us to show them.
• We show this data to anyone who uses Myrmigo, in answers about that business. We keep it, with its earlier versions, in our private code repository at GitHub (section 5).
• Legal basis: legitimate interests (GDPR Art. 6(1)(f)), namely pointing travellers and their AI agents to a business’s own official pages and contacts.
• How long: while we list the business. If the owner asks us to change or remove something, we do it within 30 days. Earlier versions stay in our repository’s history, which only our staff and GitHub, as our provider, can access, unless you ask us to erase them (section 8).
• You can object at any time (section 8), and site owners can opt out (section 9).

Why and legal basis:

• Why: to let owners control how Myrmigo covers their site, including asking us to add it, and to keep evidence of consents and opt-outs.
• Legal basis for claims, opt-outs and takedown records: legitimate interests (GDPR Art. 6(1)(f)), namely honouring objections, accountability, and establishing, exercising or defending legal claims.
• Legal basis for signed consents: legitimate interests (GDPR Art. 6(1)(f)), namely keeping evidence of the site owner’s consent. Where the owner is an individual, our contract with them (Art. 6(1)(b)).
• Where the data comes from: the claimant, public DNS records, and the site owner’s signed agreement (see also section 4.12).

4.8 Audit log

Staff actions taken through our admin tool are recorded, and so are site-owner verifications and new opt-outs. Before our update of 26 September 2026, starting a site-owner claim was recorded too (section 4.7). Each entry holds:

• who acted: the name given to the admin tool (by default the staff member’s computer user name), owner:<domain>, or, in entries from before that update, owner:unverified;
• the action and its target;
• details, which can include free-text reasons and notes, a consent signatory’s name and an agreement reference;
• a timestamp to the millisecond.

The audit log is stored in our database only.

Two other records also hold names. Guide verifications keep the name of the person who verified a guide (a staff user name, or a person at the site owner). Staff changes to a guide keep the staff user name and a free-text reason.

• Why: accountability and security, and re-applying recorded erasures after a restore (see 4.10).
• Legal basis: legitimate interests (GDPR Art. 6(1)(f)), namely accountability and security, and being able to show that we carried out requests about your rights.
• How long: after 365 days, we replace the names of people, domains, organisation ids, file names, and free-text reasons and notes in audit log entries, guide verifications and staff guide changes with a keyed hash. We keep the rest of each entry (the action, site and guide ids, key prefixes, counts and time) for as long as the service runs, for accountability. Because we hold the key, a keyed hash is pseudonymised data, not anonymous data. The reason for a staff change to a guide stays in clear until staff next change that guide, because agents are shown it while the change is in effect.

4.9 Server logs

mcp.myrmigo.com:

• Our application keeps no access log.
• At start-up it logs technical details, such as the environment, how many sites and guides it loaded, and the telemetry setting. If the deletion job fails, it logs the error message. If saving the daily totals (section 4.13) fails, it logs that, with the database’s error code. If saving a coverage gap (section 4.2) fails, it logs the error message, at most once a minute.
• For an unexpected error, it logs the request method, the route pattern (for example /flag/:site/:task, never the address that was typed) and the error message. For an error inside an MCP tool, it logs the tool’s name instead of the route.
• If the server crashes, it logs the error message and the code locations (file and line) of the crash.
• In every error message our own code logs, quoted values, email addresses, domain names and long numbers are blanked out. The web server library’s own error lines (below) are not blanked.
• Our staff dashboard also shows the last 20 of these error lines, which the server keeps in its memory until it restarts.
• When a rate limit turns requests away, it logs how many, at most once a minute, as counts per limit only. When the server becomes overloaded, it logs that with two figures about its own load, and it logs when the load is back to normal.
• If sending a response fails, the web server library logs the error and its stack trace.
• It never logs request bodies, headers or IP addresses.
• The logs are held by Fly.io, which keeps them for about 7 days. Fly.io’s network also adds its own lines about requests that failed. The lines we have seen show the path and the Fly.io location that received the request, but not your IP address. Fly.io does not publish where it stores these logs, or whether and for how long its network keeps its own records of IP addresses. They may be stored or processed outside the EU, including in the United States, under the safeguards in section 6.
• Fly.io staff, and AI tools that Fly.io uses, may read these logs during support and abuse investigations.

myrmigo.com: our host, Vercel, logs requests to the site. Its logs include your IP address, the page and any query string, your browser’s user agent and the Vercel location that served the request. The request logs we can see are kept for 1 day. Vercel also keeps usage data for its own purposes, such as security, under its privacy notice, and publishes no fixed period for it. Vercel’s main processing facilities are in the United States.

• Why: security and delivering the service.
• Legal basis: legitimate interests (GDPR Recital 49).

We also keep a daily internal counter, per report field, of how often the scrubber’s final check rejected a report because it still found something that should have been removed. It never holds the value. It is not personal data and has no end date.

4.10 Backups

Our database is on a Fly.io storage volume in Frankfurt. Fly.io takes an encrypted snapshot of it every day and keeps each snapshot for 5 days, even if the volume is deleted. Fly.io does not publish where it stores snapshots. They may be stored outside the EU, including in the United States, under the safeguards in section 6. If we restore a snapshot, the automatic deletion described in section 4 runs again when the server starts, and we re-apply the erasures recorded in the audit log. The audit log is kept in the same database, so a restored snapshot does not contain erasures made after it was taken. So we also note each erasure we carry out by hand, such as one you asked for, in a separate list kept outside Fly.io, with record ids only. After a restore, we re-apply those erasures from that list before the restored data is used.

Deleting a record removes it from our tables at once. The deleted data can remain in the database files until it is overwritten, and in snapshots taken before the deletion, for up to 5 days.

4.11 If you contact us

If you email admin@paros-summer.com, we use your address and message to reply, and we keep a record.

• Legal basis: legitimate interests (GDPR Art. 6(1)(f)), namely answering you and keeping a record of our exchange. For requests about your rights, our legal obligations under the GDPR (Art. 6(1)(c)).
• How long: 24 months after our last exchange, or longer if needed for a legal claim or a request about your rights. We delete old emails in a clean-up of our mailbox that we run twice a year, so an email can stay up to 6 months longer.
• Email provider: the mailbox for admin@paros-summer.com is hosted by Google Workspace, as our processor (section 5). The address is on the domain of Paros Summer Travellers, a vehicle rental business on Paros that Christos also owns and runs (see our Terms of Use, section 3). Myrmigo has no email address of its own yet. If we add one, for example at myrmigo.com, we will update this policy before we use it.

4.12 Data we get from others

Sometimes we receive personal data about you from someone else:

• an organisation may give us your name and work email as its contact (see 4.6);
• someone may claim a domain that relates to you. We store the domain only once the claim is verified (see 4.7);
• our reference data may describe a business you run, with the contact details it publishes or that its verified site owner asked us to show (see 4.7);
• a site owner’s signed agreement names the person who signed it (see 4.7);
• when we check a claim, we read public DNS records.

The categories of data are those listed in 4.6 and 4.7. Where we have a way to reach you, as with an organisation’s contact person or the person who signed a site owner’s agreement, we tell you directly: within one month of receiving your data, or in our first message to you if that comes sooner. Where we have no way to reach you, for example when a domain we hold relates to you, this policy is how we inform you (GDPR Art. 14(5)(b)).

4.13 Daily usage totals (not personal data)

For each UTC day, we count:

• questions (finds): by surface, by the listed site and task the answer was about (or “unmapped” or “none”), by how well the request matched, by the detected language, by the type of caller (anonymous, or the kind of organisation, never which one), by whether the answer named the site’s official channel and by whether it sent the task to the site’s own staff;
• MCP sessions, and questions to each Myrmigo tool (finds and flight compensation checks), by the kind of AI app. We take it from the name the app sends in clientInfo, when it connects or with each question, and reduce it at once to one entry of a fixed list, such as Claude, ChatGPT, Cursor or “other”. A question that names no app is counted as such, as coming through the REST API, as asked with an API key or, when it arrives from the network addresses an AI company publishes for its hosted connectors (for example Claude’s or ChatGPT’s), as coming through that company’s connectors. Questions made with our own test keys or tools are counted as our own checks. We never store the name itself, its version or the network address;
• questions by which Myrmigo tool answered them (for example the booking change and refund check, the official booking site, the flight compensation check);
• flight compensation checks, by the kind of result: eligible, not eligible, depends, or facts we could not use (section 4.14);
• outcome reports, by their result, and every report sent to us by what we did with it (for example counted, or refused);
• server errors, by the part of the service;
• finds and flight compensation checks turned away by a rate limit, by which limit (never by network or organisation);
• runs of our clean-up job, by whether they worked, and server starts, by whether the server had stopped cleanly before.

These totals hold no IP address, no organisation, no words from the request, no details of a flight and no web address. They are not personal data. Only Myrmigo staff see them.

• Why: to understand how the service is used and to plan coverage.
• Legal basis: these totals are not personal data. To the extent that they were, legitimate interests, namely understanding how the service is used.
• How long: as long as the service runs.

4.14 Flight compensation check

When you or your AI app ask Myrmigo to check EU261/UK261 rights for a flight, we use the flight’s date, airports, airline and what happened (for example “cancelled, told 2 days before”) only to compute the answer. We do not store or log them, and we never ask for names, booking references or contact details. We keep only daily counts of the kinds of results (eligible, not eligible, depends, or facts we could not use), of the kind of AI app that asked, and of checks turned away by a rate limit (section 4.13), and, to limit abuse, short-lived counts per network or organisation in memory (section 4.5). The answer is general information, not legal advice, and Myrmigo never submits a claim.

• Legal basis: legitimate interests, namely answering the request the agent made (as in 4.1).
• How long: only while the request is handled.

Retention at a glance

5. Who receives data

Our providers’ privacy policies:

• Fly.io: https://fly.io/legal/privacy-policy/
• Vercel: https://vercel.com/legal/privacy-notice
• Name.com: https://www.name.com/privacy-policy
• Google: https://policies.google.com/privacy and https://cloud.google.com/terms/data-processing-addendum
• GitHub: https://docs.github.com/site-policy/privacy-policies/github-general-privacy-statement

Only Myrmigo staff can see individual reports, flags and the audit log. Agents see only the totals described in section 4.4. We may disclose data if the law requires it.

We do not share data with advertisers or data brokers. We do not share it with AI model providers ourselves. Fly.io’s internal tools use AI vendors, which may process our server logs during support and abuse investigations (section 4.9). Google Fonts is used only when we build the website, so your browser does not contact Google when you visit.

6. International transfers

We store the service’s database in the EU, in Frankfurt; its daily snapshots may be kept elsewhere (below). Fly.io, Vercel, Name.com, Google and GitHub are US companies or part of US groups.

• Fly.io and Vercel may receive your connection outside the EU, at the location closest to you.
• Vercel’s main processing facilities are in the United States.
• Fly.io does not publish where it keeps app logs and volume snapshots. They may be stored or processed outside the EU, including in the United States; Fly.io’s list of sub-processors names Amazon Web Services (USA) for backup storage.
• Google may store and process the messages in our mailbox outside the EU, including in the United States.
• Fly.io’s DNS service may pass the domain name in a claim to a public resolver outside the EU, such as Google Public DNS.
• Our providers, or their subcontractors, may access some data from outside the EU.

Safeguards. Fly.io, Vercel, Name.com, GitHub and Google LLC (the US company of the Google group) are certified under the EU–US Data Privacy Framework (Commission Implementing Decision (EU) 2023/1795), and we rely on that certification for transfers to them. They are also certified under its UK Extension, on which we rely for personal data from the United Kingdom. You can ask us for a copy of the safeguards.

7. Security

• Connections from your browser or agent to our services use HTTPS. Fly.io ends HTTPS at its edge server closest to you and passes requests to our server over its private network. Vercel ends HTTPS in its region closest to you. Either can be outside the EU (section 5).
• Our service stores API keys only as keyed hashes and checks them in constant time. We email each new key once and delete our copy of that email straight away (section 4.6). We do not store owner tokens.
• We never store goal text, and we drop query strings when a request arrives.
• We scrub reports before storing them, and we reject reports that seem to contain card, bank, passport or secret data.
• Our public web pages run no scripts. Both myrmigo.com and mcp.myrmigo.com send a Content Security Policy that blocks scripts. The only exception is our password-protected staff page, which runs one small script of its own and loads nothing from other sites.
• The service’s database is hosted in the EU. Only staff have access, and staff actions taken through our admin tool are recorded in the audit log.

No system is perfectly secure. Please report security problems to admin@paros-summer.com.

8. Your rights

You have the right to:

• access your personal data;
• correct it;
• have it erased;
• restrict how we use it;
• port it, where that applies.

We do not rely on consent today. If we ever do, you can withdraw your consent at any time.

Your right to object. Where we rely on legitimate interests, you can object at any time, for reasons relating to your particular situation. We will then stop, unless we have compelling legitimate grounds, or need the data for legal claims. Site owners can also opt out of Myrmigo’s coverage of their site (see our Terms of Use).

How to use your rights:

• Email admin@paros-summer.com. We reply within one month. For complex requests, we can extend this by two more months, and we will tell you if we do.
• Using your rights is free of charge.
• We may ask for information that confirms who you are.
• If we cannot act on a request, we will tell you why within one month, and remind you that you can complain to the Hellenic DPA or go to court.
• We do not store identifiers for travellers. So we usually cannot link any record to you (GDPR Art. 11). If you give us extra details, such as your domain or your organisation, we will check.

Complaints. You can complain to the Hellenic Data Protection Authority:

• Address: Kifissias 1-3, 115 23 Athens, Greece
• Website: https://www.dpa.gr
• How to complain: https://www.dpa.gr/en/individuals/complaint-to-the-hellenic-dpa
• Online complaints: https://eservices.dpa.gr
• Email: complaints@dpa.gr

You can also complain to the authority in the EU country where you live, where you work, or where the problem happened. You also have the right to go to court (GDPR Art. 79).

If you are in the United Kingdom, you can also complain to the Information Commissioner’s Office (ICO): https://ico.org.uk/make-a-complaint/.

9. Your controls

• You can use the reference surface without an account. Apart from the short-term rate-limit entries in section 4.5, nothing we keep from it is linked to you.
• You can disconnect or remove Myrmigo in your AI assistant’s settings at any time. After that, nothing more reaches us from your assistant.
• You decide what your assistant sends. Keep names, booking codes and other personal details out of your requests.
• Organisations can ask us to revoke API keys and to close their account (section 4.6).
• Site owners can opt out of coverage of their site (section 4.7).
• Site owners can see what we tell AI agents about their site, claim their domain and opt out on our page for business owners, https://mcp.myrmigo.com/owner.
• You can use your rights in section 8 at any time.

10. Automated decisions

We do not make decisions about people by automated means that have legal or similarly significant effects, and we do not profile anyone. Our rate limits turn some requests away automatically (section 4.5); that is not such a decision, and you can write to us if you think a limit has treated you unfairly.

11. Children

Myrmigo is a tool for people and organisations dealing with travel bookings. It is not aimed at children. We do not knowingly collect personal data about children. Our scrubber drops report lines that mention infants or unaccompanied minors.

12. For AI agents and developers

Reference surface (/mcp, POST /v1/reference, the public GET endpoints):

• We store nothing from your call except anonymous coverage gaps (section 4.2) and daily usage totals (section 4.13). For finds, flags, flight compensation checks and site-owner calls, the rate limiter also holds short-lived counts in memory (section 4.5).
• There are no accounts and no sessions.
• We do not store the name or version your MCP client sends in clientInfo. We only count sessions and questions (finds and flight compensation checks) by kind of app, from a fixed list (for example Claude, ChatGPT, Cursor or “other”), in the daily usage totals (section 4.13).

Agent surface (/agent/mcp, /v1/route, /v1/runs):

• We check your key against its hash.
• On sites with step-by-step guides, we create a 48-hour run handle that holds your organisation id (section 4.3).
• We record coverage gaps and daily usage totals as on the reference surface.
• For flags and flight compensation checks, the rate limiter counts your organisation’s calls in memory (section 4.5).
• We store outcome reports and flags, including the Myrmigo-Runtime value, only when those features are on (section 4.4). Today they are off for customer keys.

Never written to our database or application logs:

• the full API key;
• the goal text;
• raw request bodies and headers (once reports are switched on, outcome reports keep only the Myrmigo-Runtime value, as local, cloud or unknown);
• query strings;
• IP addresses. The rate limiter keeps short-lived counts under a keyed hash in memory (section 4.5).

For unexpected errors, we log the method, the route pattern (never the address that was typed; for an MCP tool, its name) and the error message, with quoted values, email addresses, domain names and long numbers blanked out. If the server crashes, we log the error message, blanked the same way, and the code locations of the crash. If sending a response fails, the web server library logs the error and its stack trace.

Please:

• Keep personal data out of task, goal, where and booked_via.
• Send web addresses without their query string.
• In reports, use {placeholders} rather than real values. Never send card, passport or login data. The scrubber rejects reports that contain them.

13. Changes to this policy

We post every change here with a new effective date and a summary of what changed. We keep every earlier version and send it to you on request. We email API key holders, and site owners who have signed a consent, about significant changes at least 30 days before they take effect. Before we use personal data for a new purpose, we will update this policy first.

14. Contact

Christos Christoforidis · Paros 844 01, Greece · admin@paros-summer.com