Privacy policy

The MAIT Team is the data controller for the processing described here. MAIT's operating entity is being set up. We will name it on this page once it exists.

Contact: privacy@mait.sh

MAIT staff. Where this policy says "staff", it means MAIT contributors and supporters: people the MAIT Team has enabled for specific features, such as the staff portal or account management. Staff act for the MAIT Team when they use those features.

We have not appointed a Data Protection Officer. At our current scale the GDPR does not require one (Art. 37). If that changes, we will appoint one and list them here.

This page lists what we actually store or process today. The separately labelled sign-in connection section describes processing planned for that option when it becomes available; it is not a claim that sign-in connections are currently published.

When you sign in

You sign in with Google, GitHub or Microsoft. Microsoft covers both personal accounts (Outlook, Hotmail, Live) and work or school accounts. We receive and store:

• Email address from your sign-in provider.
• Name. This is your display name and, if the provider sends them, your first and last name. You can change the name we show on your account page.
• Account identifier. This is the ID your sign-in provider uses for you, plus the provider's name. It lets us recognise you next time.
• Email verification. We record whether your provider confirmed that you own the email address, how it confirmed that, and when. For Google and Microsoft we check the provider's signed ID token. For GitHub we ask GitHub's API. The verification method sets a trust level:
  • User level, for example a personal Microsoft account. This is enough for sign-up and for private-beta content.
  • Staff level, for example a Google account, a GitHub account or a Microsoft work account. This is needed for staff access.
• Sign-in activity. This is when you last signed in and how many times, for the account as a whole and for each provider you have linked.

We ask providers for sign-in identity only: your identifier, email address and basic profile name. We do not ask for your documents, contacts, mailbox or calendar.

GitHub requires one extra permission, read access to your organisation membership (read:org). The sign-in component we use needs it to finish a GitHub sign-in. We do not read, use or store your organisation or team data.

When you use your account

• Linked sign-in providers. From your account page you can link more than one provider (Google, GitHub, Microsoft) to the same MAIT account, and unlink them. We store each linked provider's account identifier, email verification and sign-in counts. Linking never creates a second account and never signs you in as someone else.
• Your preferences. These are your diagnostics choice for our websites, your click-tracking choice for mait.sh, your diagnostics choice for our other products, your choice about account emails, whether you want to support or contribute to MAIT, and the roles you picked under "Your work" (for example Developer or Architect). We store each choice with the date and time it last changed.
• Event sign-ups. If you sign in through an event's sign-up link or QR code, for example at a conference where we have a stand, we record the event, the time and the campaign tags (source, medium, campaign, content) from the link you used. We store them with your MAIT account identifier, never with your name or email. If "Share usage and error diagnostics" is off on your account, we record only the event and the time. Declining diagnostics in your browser does not change this. If your email is verified, signing in this way also gives your account the "private beta" category, which unlocks private beta features. This applies to existing accounts too and has no end date, though staff can remove it. We delete the campaign tags after 400 days, or sooner if you object. The staff portal shows only counts per event, tag and period.
• Account categories. We may place your account in a category that unlocks features or content, for example "staff" or "private beta". MAIT staff set these, and signing in through an event's sign-up link also sets "private beta" automatically. You cannot see or change them yourself.
• Pre-registration. A MAIT staff member may pre-register you for the private beta using your email address and name, before you have signed in. When you first sign in with a verified email address, that record becomes your account. If nobody signs in with that address within 30 days, we delete the record automatically.
• Organisations. If an owner or admin of an organisation adds your email address, we keep that address and a pending membership for up to 30 days. If you sign in to MAIT with that address in that time, you join the organisation; otherwise we delete the record automatically. We don't send you an email about it.
• Credentials and features. These are the credentials issued to your account, the features they enable, and their history. They are stored against your MAIT account identifier. Our credentials and features service holds no name or email address.
• Service audit records. These record the operations our services perform on your account, such as "account created", "preferences updated" or "account deleted". Each record holds the event, the internal service that made the request, your MAIT account identifier, your provider account identifier, whether the operation succeeded, a short fixed error message if it failed, and the time. We do not write your email address or name into these records.

When sign-in connections become available

If you allow an approved app to use a feature, we keep connection metadata against your MAIT account identifier: the app's registration identifier and display name, its return-address hostname, the feature, connection times, status and a fixed reason when access is revoked. This list helps you understand shared feature access and recover a connection. It does not create a separate access token for every app.

Connection metadata uses a 400-day retention window after the latest connection or revocation, followed by automatic cleanup. We request removal of these connection records through the credentials and features service when you delete your account. If that service is unavailable, these records can remain; there is no automatic retry. The deletion limitations and confirmation steps below also apply. Request audit records remain subject to the seven-day period below. Connection events and metric labels omit authorization codes and access tokens. Browser diagnostics apply the recognition-limited filters described below. Sign-in connections are not yet published; this section describes the processing that must be disclosed when they are enabled.

When you use the command-line tools

• Update checks, downloads and credential renewal. The MAIT tools (the CLI, the aidcx launcher and related tools) check for updates and renew your credential in the background while they run other commands. Each check sends the operation, the product, the version you run, your MAIT account identifier and a hashed identifier for your machine. That identifier is a one-way hash of your computer's hostname. We treat it as personal data. Almost every command does this. The exception is aidcx doctor, which runs locally and sends nothing. These checks are strictly necessary to deliver the releases and the features your credential enables, so you cannot turn them off. They contain no name or email address.
• Account activation. The first time you activate the tools, they print a web address that contains the same machine identifier. Opening it sends the identifier to this website, where it can appear in our access logs.
• Faster package installs. If you use our optional package acceleration, we record usage statistics in aggregate: which tool, which version, which platform, and whether it was found. These statistics are not linked to you or your machine. If a request is refused because your credential does not enable that feature, we log the refusal against your MAIT account identifier so we can look into access problems. Successful requests are not logged against you.

Diagnostics in your browser (only if you accept)

The first time you visit mait.sh, staff.mait.sh or xCAIO, a bar at the bottom of the page asks you to Accept diagnostics or Decline diagnostics. One answer covers all three sites in that browser: we keep it in a cookie on the mait.sh domain for 180 days, and then ask again. Until you accept, our diagnostics agent does not load. It makes no network request and stores nothing else in your browser. If you decline, it stays off.

If you accept, our diagnostics agent (Grafana Faro) runs in your browser. It sends data only to a collector on our own servers:

• the pages you open, with their full addresses
• on mait.sh, a coarse category for the referring page when diagnostics start: internal, recognised search engine, recognised social site, other, or direct-or-unavailable. We send no referring address, domain or query with this category. An empty browser referrer can mean a direct visit or that the browser withheld it
• page-load and responsiveness timings
• JavaScript errors, with their stack traces
• console messages at information, warning and error level
• the addresses and timings of requests the page makes to our own servers
• security-policy violation reports from your browser
• your browser, operating system, user-agent string, browser language and window size
• a random session identifier that lasts for one browser tab, for up to 4 hours or until you have been inactive for 15 minutes

The referring-page category describes this document when you accept diagnostics, which may be partway through a journey. It stays the same during navigation within that document, including a diagnostics session rotation, and is recomputed on a new document load. It does not prove the original source of your visit. It adds no browser-storage entry.

The agent does not record what you type or enter into forms. It takes no screenshots and does not replay your session. Before diagnostics are buffered for sending, the agent removes recognised sign-in codes and tokens from web addresses, recognised token-shaped values from text, and values in explicitly sensitive fields. These checks reduce accidental disclosure; they do not recognise every possible secret in arbitrary error or console text. This is one reason we keep this data for only 7 days. We do not sample it down: while diagnostics are on, every event is sent.

Click tracking. If you have accepted diagnostics, we also record when you click one of the sign-in buttons (Google, GitHub or Microsoft) or the Sign up button on an event page on mait.sh. We record nothing else about your clicks. You can turn click tracking off on its own on the cookie policy page, and diagnostics stay on. Click tracking never runs if you have declined diagnostics.

On event pages, the page addresses that diagnostics send include the link's campaign tags. We also record that you viewed the event page and, after you sign in, that private beta access was given, each with the event and the tags. If click tracking is on, we also record that you pressed "Sign up". Like all diagnostics, these are kept for 7 days.

When you are signed in:

• On mait.sh, staff.mait.sh and xCAIO, diagnostics are linked to your MAIT account identifier. This is a random identifier that is not derived from your name or email, and we never send it together with them. We never attach the identifier your sign-in provider uses for you.
• Your account page has an extra switch, "Share usage and error diagnostics", that turns diagnostics off for your account on mait.sh, staff.mait.sh and xCAIO, even in a browser where you accepted. A second switch does the same for click tracking on mait.sh. They can only narrow what you accepted. They can never switch diagnostics on without your acceptance in that browser.

When you are signed out, diagnostics are not linked to any account.

You can change your choice at any time on the cookie policy page, which staff.mait.sh and xCAIO also link to as "Privacy choices". Turning off stops diagnostics immediately on the current mait.sh page, including pending startup. If you turn them back on after they have stopped on this page, reload to restart them. The shared choice applies to future page loads on staff.mait.sh and xCAIO; it does not stop their already-open pages.

Connection data

• IP address. Like any website, our servers see your IP address while you are connected. Two request logs record it: the sign-in component in front of the site, and our edge proxy's access log. We also use it briefly in memory to rate-limit requests. We do not store it in your account or in diagnostics data, Both logs are deleted after 7 days.
• Country. On mait.sh, beta.mait.sh and edge.mait.sh, a page request's IP address is turned into a country on our own servers. We use a country database we download and keep locally (IP Geolocation by DB-IP). Your IP address is not sent to DB-IP or to anyone else for this. The result we store is a two-letter country code, or "unknown" when there is no country. It is a count of page requests, together with which of those three sites you opened and a short page category such as the home page or the sign-in page. That count does not include your IP address, your account, your session or your browser. We do not derive a city, a region or a precise position. These counts are kept for up to 7 days. This does not run in your browser and does not depend on the diagnostics choice.

When you email us

If you write to privacy@mait.sh or support@mait.sh, we receive your email address and whatever you put in the message. We use your message only to answer you and to deal with your request.

All our contact mailboxes, including privacy@mait.sh and support@mait.sh, are hosted on our own mail server in the EU (Hetzner). No third-party mail provider receives what you send there. For privacy requests, write to privacy@mait.sh. We delete mail automatically: see "How long we keep your data".

What we do not collect

• We run no advertising and no third-party analytics, and we use no session replay. There is no Google Analytics, no tag manager and no advertising pixel. The one thing we track beyond diagnostics is which event you signed up through (see "Event sign-ups").
• We do not sell or rent personal data. We do not build profiles of you. The only automatic decision about you is giving private beta access to people who sign up through an event page.
• We do not record sessions or replay your screen. We do not try to recognise you on other websites.
• Our pages load no fonts, scripts or images from third-party servers.

staff.mait.sh and xCAIO do not run their own sign-in. When you sign in to one of them, it sends you to mait.sh. mait.sh confirms who you are and sends back a signed, single-use message that is valid for 60 seconds. It holds your account identifier, name, email address, sign-in provider and email-verification status. The receiving site then keeps its own sign-in cookie for up to 7 days.

Your first sign-in to xCAIO creates a MAIT account if you do not have one. You go through the same first-sign-in preferences as on mait.sh.

staff.mait.sh is for MAIT staff only. Staff access needs a staff-level verified email address, either a @mait.sh address or an account MAIT staff have marked as staff. Depending on the features the MAIT Team has enabled for them, staff can see account details in the staff portal to run the service: names, email addresses, categories, credentials, features and organisations.

This page is meant to be checked, not only read. Here is what we verified is not true about our tools:

• No hardware fingerprinting. The only device identifier the tools use is the hashed hostname described above. They read no processor, disk or motherboard serial number, no network hardware address, and no separately generated identity file.
• No tracking through version strings. The identification string our tools send states only the tool name and version.
• The public install script sends nothing. Running our one-line installer from dist.mait.sh downloads the installer and sends no identifier.
• "doctor" does not upload. Our diagnostic commands print their findings to your screen. They do not save or upload a report.
• Your credential is tied to your account, not your machine. It carries no machine identifier.
• No crash reporting or analytics is built into the tools.
• Your code and prompts stay yours. The command-line tools never send your source code, files or AI-assistant prompts to us or to any AI provider.
• Our developer tools connect only where you direct them. The browser-automation, container and infrastructure tools connect only to destinations you configure.
• Browser-automation data stays on your machine by default. Cookies, page state, screenshots and recordings captured while our tools drive a browser are written to your machine and cleaned up when the session ends. An advanced networked mode can expose that data over the network if you choose to set it up.

• We cannot see your session. The two ends of a connection are end-to-end encrypted with keys generated only on the two machines. Our relay forwards the encrypted traffic and cannot decrypt it.
• We keep a short connection audit record, never your session. While a session is active, our relay holds your MAIT account identifier and a temporary session identifier in memory to connect the two ends, and discards both when the session ends. The relay also writes a service audit record with your MAIT account identifier, the connection event, its outcome and how long it lasted. It never contains the temporary session identifier or anything from the session itself, and it is deleted after 7 days (see How long we keep your data below).
• If you record a session, you are responsible for who else is in it. Recordings are written only to your own machine and never sent to us. If they capture other people, getting their consent is your responsibility.

Account emails. Your account page has a setting called "Email me about my account and features". It is on by default. We do not send any account email yet, so the setting only records what you want once we start. Every email we send will include a one-click unsubscribe link.

Emails you send us are stored on our own mail server on the Hetzner infrastructure above, and stay there.

Diagnostics and logs stay with us. We run the diagnostics collector and the storage for diagnostics and logs (Grafana Loki, Tempo and Prometheus) ourselves on the Hetzner servers above. None of it goes to Grafana Labs or any other third party. The country database is a file we download. The lookup runs on our servers, and your IP address is not sent to the database publisher.

No one else receives your data.

When you sign in, your provider necessarily learns that you signed in to MAIT. Each provider acts as an independent controller for its own sign-in data. A sign-in does not need a separate data processing agreement with us.

• Your name and email address are encrypted in our customer database with AES-256-GCM. Each record has its own key. That key is wrapped by a separate key that is supplied to the service at runtime and never stored in the database. Each encrypted record is bound to its account identifier, so it cannot be moved to another account. This also applies to pre-registered records.
• Your email is also stored as a keyed hash (a "blind index"). This lets us look up your account by email without keeping a readable copy for that purpose.
• Some data is not encrypted. Provider account identifiers, email-verification status, sign-in counts and times, preferences, categories and service audit records are stored unencrypted. Access controls protect them.
• Our services need client certificates to talk to each other. The service that holds your personal data is not public. Every request must present a certificate issued by our own certificate authority, with permission for the operation. Network rules also limit which services can reach it.
• Sign-in cookies are protected. The sign-in session from Google, GitHub or Microsoft is stored encrypted. Our own session cookies are signed so they cannot be altered. See the cookie policy for exactly what each one holds.
• Servers are in the EU. Everything runs on Hetzner in Falkenstein, Germany, with some infrastructure storage in Helsinki, Finland.

None of the following is sent to us.

• Your credential. This is a file with your account identifier and the features it enables, readable only by you. Renewing it leaves the previous copy on disk. We do not clean these up automatically yet.
• Sign-in credentials for optional third-party integrations. If you connect a tool to an external service, its access token, and sometimes a saved browser sign-in, is stored locally, readable only by you, until you disconnect.
• An activity log. Our development-container tool keeps a local, append-only record of the commands it runs for you. It has no automatic size limit or expiry yet.
• Other AI tools' sign-in state. If you turn on that feature, the development-container tool makes the configuration and sign-in folders of AI coding assistants already on your machine available inside the container. It shares only those folders.
• Uninstalling does not notify us. Uninstalling removes the software from your machine. Your credential and the records above stay until they expire or you delete your account.

On mait.sh, explicitly accepting diagnostics sends only the word accepted to our own server, without sign-in cookies, account or session identifiers, or the referring page address. We count received observations, including repeats, rather than people. We send no acceptance observation while you are undecided or after you decline; declined choices are unmeasured. Reading a saved choice or reloading does not add an observation. Separately, we count successful acknowledged writes of the signed-in diagnostics opt-out preference, including repeated writes. Neither aggregate contains account or session identifiers. A count of one or a few events is published as recorded and can still be linked to outside knowledge; we do not hide counts below a threshold. Normal server request logs may still contain the IP address of a request, as described above.

Under the GDPR you have the right to:

• Access (Art. 15). Your account page shows your name, email address, linked providers and preferences. For everything else (sign-in counts, credentials and features, audit records, categories), email us. There is no self-service export yet.
• Rectification (Art. 16). You can edit your name on your account page. Your email comes from your sign-in provider: update it there and sign in again. Email us if that does not fix it.
• Erasure (Art. 17). Use "Delete my account and data" on this page while signed in, or email us. See below for exactly what that removes.
• Restriction (Art. 18). Email us. We handle this by hand.
• Data portability (Art. 20). Email us. We will send your data in a structured, machine-readable format.
• Object (Art. 21). Email us to object to processing based on legitimate interest. You can object to account emails at any time with the account-page switch. Update checks and credential renewal are strictly necessary for the tools, so they cannot be turned off.
• Withdraw consent. You can withdraw your diagnostics consent at any time on the cookie policy page, or with the diagnostics switch on your account page. Withdrawing does not affect processing that happened before.

Using "Delete my account and data":

• Removes immediately: your encrypted name and email, the email lookup hash, every linked provider with its verification and sign-in counts, your preferences, your categories, your event sign-up records and your consent record. After this, a lookup by account identifier, email or provider finds nothing.
• Also removes: your customer record in our credentials and features service, with your credentials, the features they enable, certificates, activation codes and renewal history. This is part of the same deletion. We first revoke every certificate issued to your account, so the MAIT tools on your machines stop working with it at their next credential check, and then we delete the record. If that service is unavailable, the deletion does not go through: you see an error and your account stays, and you can try again later or email us. If the failure happens after the certificates were revoked, they stay revoked.
• Kept, then deleted after 7 days: service audit records, including one that records the deletion, and the audit records of the credentials and features service. These hold identifiers but no name or email address. Ask us if you want them removed sooner.
• Not reached by deletion: the update-check service's own records of your downloads and update checks. These are deleted after 7 days, or sooner if you ask. Uninstalling the tools does not notify us.
• Cookies on staff.mait.sh and xCAIO expire on their own within 7 days, or when you sign out there.
• Cannot be undone. Signing in again afterwards creates a new, empty account.

Email us if you want written confirmation that a deletion is complete.

• Email privacy@mait.sh.
• Use "Delete my account and data" on this page while signed in.
• Change your choices on the cookie policy page, or on your account page under "Share usage and error diagnostics", "Let us see which buttons and links you click" and "Email me about my account and features".

You can complain to the supervisory authority in the EU or EEA country where you live or work, or where you think your rights were infringed (Art. 77).

Signing in with Google, GitHub or Microsoft involves a transfer to the United States. All three take part in the EU-US Data Privacy Framework, which the European Commission recognises as giving adequate protection. Downloading a MAIT container image from GitHub's container registry (ghcr.io) also sends that request to GitHub in the United States.

Everything else happens in the EU on Hetzner infrastructure in Germany and Finland: storage, encryption, credentials and features, diagnostics, logs and our mailboxes.

We use cookies and browser storage that are strictly necessary to sign you in and to remember your choices, including one cookie on the mait.sh domain that holds your diagnostics choice for mait.sh, staff.mait.sh and xCAIO. Two more browser-storage entries exist only while diagnostics are running, after you accept them. We set no advertising or third-party tracking cookies. The cookie policy has the full list.

We will post any update on this page and change the date below.

For the existing Google, Microsoft and GitHub sign-in links, consented behavior capture also records a bounded provider navigation intent when you activate the link in the same tab. It uses the existing diagnostics transport and records only the provider category and event time with the existing diagnostics context. It does not record the destination address or query, create another browser-storage record, or prove that a provider received a request, authentication succeeded or an account was created. Diagnostics or behavior decline stops these intent observations on the current Portal page; ordinary diagnostics continue when only behavior is declined.

November 8, 2026