Who we are
Akili OS is operated by Ecadel Group. When this page says we, that is who it means. When it says you, it means the person using Akili OS, and where you use it for an employer, it also means that organization.
For anything about this page, your data, or a request you want to make, write to privacy@akilios.dev. A person reads it.
What stays on your machine, and what leaves it
This is the part most privacy policies skip, and it is the part that decides whether you can put Akili near a real codebase. So here it is plainly.
Stays on your machine
- Your repository. Every file, tracked or not. Akili reads it from disk, edits it on disk, and builds and tests it on your machine.
- Your git history, including the checkpoint Akili takes before each run so that Keep and Revert are both one click.
- Your environment — variables, credentials, SSH keys, anything else your shell can see. Akili has no reason to read them and no path that sends them.
- Command output, except where the agent deliberately feeds a failing test or a compiler error back to the model in order to fix it. That is a model call, and it is covered below.
Leaves your machine
One thing: model calls. When the agent needs the model to think, it sends
a request to api.akilios.dev containing:
- your prompt;
- the file excerpts the agent selected as relevant — not your whole repository, but real code from it;
- the output of commands it ran, where that output is what it is reasoning about;
- the conversation so far, so the model has context.
We want to be exact about this, because "your files never leave your machine" is a claim people repeat and it is only true in the sense above: your repository is never uploaded, stored or indexed by us — but the code the agent reasons about is in the model request. If that distinction matters for your work, it should decide how you use Akili, and we would rather you knew now than found out later.
What happens to a model call
- It is authenticated against your access token, served, and the response is returned.
- We record how many tokens it used, against your token, for that day. That is a number. It is what your dashboard shows and what your allowance is measured against.
- We do not store the request body or the response body. There is no transcript of your session on our side.
- We do not use any of it to train models.
Operational logs may briefly record that a request happened, its size and whether it succeeded, for the ordinary reasons — keeping the service up and finding out why it broke. They do not contain prompts or code.
What we collect
Your account
Your name, email address, organization name, and the password you set. The password is stored as a scrypt hash with a random salt per password; we cannot read it, recover it or tell you what it is. If you ask us to reset it, we send you a link — we never email a password, and we never set one on your behalf.
Sessions
When you sign in we store a random session identifier, when it was created, when it expires, the IP address it was created from and the browser's user-agent string. That is how "sign out everywhere" can work and how you can see, on your profile, where your account is signed in. A web session lasts thirty days; an administrator's lasts twelve hours.
Usage
For each access token, for each day: a token count. Nothing about what you asked, what files were involved, or what came back. From that we derive everything on your dashboard — today's spend, the fortnight's chart, and how much of your allowance is left.
Billing
Which plan you are on, when it renews, credits granted and spent, and a record of every payment attempt with its amount, currency, outcome and provider reference. We never see your card details. Payment happens on the provider's own pages; what comes back to us is a token we can ask them about, and the answer is "paid" or "not paid".
Support and feedback
If you write to us, we keep the correspondence. If you file a report from inside the product, we keep what you typed plus a short, fixed list of context: the app version, your operating system, which model was active and the last command name. That list is enforced in code — anything else the client sends is dropped before it is stored. A bug reporter that quietly uploaded the surrounding code would break the one promise this product is built on, in the place you would least expect it.
If you apply to the testing programme
What you put on the form: your name, address, organization, role, what you are building, your stack, platform and how often you code. We also record the IP address and browser the application came from, which is used for one thing — noticing when four hundred applications arrive from one script — and is deleted after ninety days.
This website
We count page views, first-party and without cookies. No advertising or measurement pixels, no session recording, and no third-party scripts of any kind — every script and stylesheet on this site is served from this domain. The next section is the whole of it, because a policy that says "we use analytics" and stops has told you nothing.
The web server also keeps ordinary access logs.
How we count visits
We want to know how many people came, which pages they read and where they gave up. We do not want to be able to follow anybody. Those two things are compatible, and this is how.
There is no identifier
No cookie is set for this. Nothing is written to your browser's storage. There is no fingerprint. Instead, when a page is opened, the server computes:
visitor = sha256(today's secret + your IP address + your browser's user-agent string),
truncated — and today's secret is random, held only in memory, and replaced every
night.
Three things follow from that, and they are the whole point:
- Your address is never stored. It exists for the length of one hash and is then gone.
- The hash cannot be reversed into an address — by us or by anyone who took the database — because the secret that made it no longer exists.
- You cannot be followed across days. The same person on Monday and on Tuesday produces two unrelated values. We genuinely cannot tell they are the same person, and we accept the cost of that: we cannot report returning visitors, and we cannot trace one person's week.
What a page view records
| Field | Example |
|---|---|
| Which page | /docs/install — the path only, never the query string |
| Where the link came from | The referring site's hostname, or "direct" |
| Campaign | The utm_campaign or ref value, if the link had one |
| Window width | Bucketed to phone, tablet or desktop |
| Language | The first five characters, e.g. en-GB |
| How long the page stayed open | And how far down it was scrolled |
We also record a handful of named actions so that we can see where a form loses people — for example, that somebody reached step 3 of the application. The step number is recorded. Nothing typed into the form is.
Turning it off
If your browser sends Do Not Track or Global Privacy Control, nothing is recorded at all. Not anonymised — not recorded. The page is served normally and the request is dropped on arrival. Most privacy-minded browsers and extensions send one of these by default, which means our numbers are a floor rather than a census, and we would rather have honest low numbers than complete ones.
Blocking /a.js also works, and nothing on the site depends on it.
How long
Individual page-view rows are deleted after 90 days. What outlives them is a daily count per page — how many views, how many visitors — with nothing per-person in it at all.
What it is never used for
- Advertising, of any kind, ever.
- Building a profile of you, which the design makes impossible rather than merely forbidden.
- Sharing with anybody. It never leaves this server.
- Linking your browsing to your account. Signed in or not, the same anonymous row is written, and nothing joins the two.
We send two kinds. Transactional mail is part of the product working: confirming an address, an invitation, a password reset, a notice that your tokens are running out, a receipt. You cannot switch these off while you have an account, and each one says why it was sent.
Everything else — the weekly digest, release announcements, tips — is optional and switchable from your profile, permanently, immediately. An opt-out that lapses at the next release is not an opt-out.
Mail is sent over an encrypted connection to our mail provider. If a message cannot be sent, it is written to a queue on our server and retried rather than dropped — a verification email that silently vanishes leaves somebody with an account they can never open and no way to find out why.
There are no tracking pixels. We do not know whether you opened anything.
Who else is involved
We keep this list short on purpose. Every name here is somewhere your data could go, so adding one is a decision, not an afterthought.
| Who | What for | What they get |
|---|---|---|
| Our hosting provider | Running the servers | Everything the service stores, at rest on their disks |
| Our mail provider | Delivering email | Your address and the message we send you |
| DPO Pay (3G Direct Pay) | Taking payments | Your name, email, the amount, and the card or mobile money details you give them directly |
| Model infrastructure | Serving model calls | The contents of a model call, for as long as it takes to answer it |
We do not sell your data. We do not share it for advertising. We have never had a reason to hand it to anyone else, and if we are ever legally compelled to, we will tell you unless we are forbidden from doing so.
How long we keep things
| What | Kept | Why |
|---|---|---|
| Your account and organization | Until you delete it | It is your account |
| Daily token counts | Life of the account | Your usage history and your billing record |
| Payments | Life of the account, then as tax law requires | An audit trail for money is not optional |
| Sessions | Until they expire, then swept | A session table that only grows is a liability |
| Sign-in links and invitations | Spent on first use; swept a week after expiry | Single use is what makes them safe |
| Reports you file | Life of the account | It is the product's memory of what was wrong |
| Messages we sent you | 12 months | Answering "did they get the invitation?" |
| Product events | 13 months | Comparing a year to the one before it |
| Application form answers | 12 months after the decision | The next cohort, and knowing who we turned away |
| Application IP and browser | 90 days | Abuse triage, and nothing else reads it |
| Administrator actions | Indefinitely | See below |
The last row is deliberate. Every action one of our administrators takes on an account — granting tokens, suspending access, changing a setting — is written to a log with who did it, when, from where, and the reason they typed. Nothing in our software can edit or delete that log. There is no endpoint for it. A log you can quietly delete from only tells you what somebody was willing to leave behind, and it is the first thing we would read if you ever told us something happened to your account that you did not ask for.
What you can do
These are buttons, not requests. You do not have to email anyone or wait thirty days.
Take everything
From your profile, export a single JSON file containing your account, your organization, your usage history, your reports, your application if you made one, and every message we have sent you.
Delete everything
Also from your profile. It removes your account, your organization, your application, your events, your messages and the text of your reports, and revokes your access token immediately. The page tells you exactly this before you confirm.
Two things survive, and you should know which:
- Administrator action records, keeping the account identifier but not your name or address — for the reason given above.
- Payment records, where the law requires us to keep them.
Correct something
Your name and organization are editable from your profile. For anything else, write to us and we will fix it.
Object, restrict, or complain
If you are in a jurisdiction that gives you rights to object to or restrict processing, you have them, and asking is enough. If you think we have handled your data badly, tell us first — we would rather fix it — and you also have the right to complain to your local data protection authority.
How it is kept safe
Specifics rather than adjectives:
- Passwords are hashed with scrypt at interactive cost, with a random salt each, and compared in constant time.
- Sessions are 32 random bytes, stored server-side and revocable, and every sign-in page refuses to leak whether an address exists by answering identically and doing the same amount of work either way.
- Sign-in and invitation links are single-use and expire. Sending a new one invalidates the last.
- Administrator accounts need a second factor, are re-proved every twelve hours, and cannot grant tokens or suspend anyone without typing a reason that goes into the audit log.
- Rate limits on sign-up, sign-in, resends and applications, counted so that your own mistakes do not lock you out.
- Everything over HTTPS, and the service holds no secrets in its source code.
No system is perfect. If you find something, write to security@akilios.dev — we will answer, we will fix it, and we will credit you if you want us to.
Where it is processed
Our servers are in Europe. Our mail and payment providers operate their own infrastructure, which may be elsewhere. If you are in a region whose law restricts transfers abroad, using Akili OS means your data will be processed outside it, and this paragraph is how we tell you so.
Children
Akili OS is not for anyone under 16. We do not knowingly collect anything from a child; if we learn that we have, we delete it.
Changes to this page
When we change it, the date at the top changes. If a change affects what we collect or who we share it with, we will email you about it rather than hoping you re-read the page.