Built to be a safer place to run an AI agent than anything online

Centurion is software that runs on a computer you own, in a building you control. We sell the licence; we do not sell, rent or hold the machine. Your documents, your assistant’s memory and your conversation history never leave it — not as a policy we promise to keep, but because the software is not built to send them.

That single fact is the whole security argument, and it is a stronger one than any list of controls. Every published breach of an AI product follows the same shape: a copy of somebody’s work existed on a server they did not own, and that copy was taken. Centurion makes no such copy. There is nothing at our end to steal, to leak, to subpoena or to retain.

So the questions your review will ask have unusually good answers, and a few of them stop applying altogether. Everything below is that — including the parts we do not like answering.

If you only open two answers, open 05 and 06. Those are the ones your reviewer will test.

Nearly every AI tool an IT team is asked to approve works one way: your words leave the building, are processed on a server the vendor runs, and come back. The review for that shape is well established — single sign-on, multi-factor authentication, a data processing agreement, a retention window, the vendor’s certifications. Those questions exist for good reason: somebody else is holding your data.

Centurion is the other shape, and the difference is not a matter of degree. The assistant, its memory and your documents run on a machine in your building. That is not a control bolted onto a hosted product — it removes the thing the rest of the checklist was built to protect.

Which is why some standard questions do not have the answer you expect, and it is worth saying why rather than leaving a blank. There is no login to put MFA in front of, no tenancy to segregate, no vendor-side retention to negotiate. Where a question still applies we answer it directly. Where it does not, we say so, and tell you what takes its place.

Reviewing this beside a SaaS AI tool? The useful question is not "does it tick the same boxes" but "which of these boxes exist at all". Q12 lists what we do not hold — that is deliberate, and it is why you can believe the rest.

Set features aside. Features age badly and a competitor will match them next quarter. On the questions a security reviewer actually has to sign off, a private agent is not a marginal improvement on a public AI tool — it answers a different question, and the answer is stronger on every line.

• • Exposure. A public assistant creates a copy of your work on infrastructure you do not own, and that copy is what gets breached, retained or subpoenaed. Centurion creates no copy. The safest data is data that was never collected, and that is not a promise we make — it is how the system is built.
• • Blast radius. Breach a public AI vendor and you inherit their other customers’ exposure alongside your own. Breach us and you obtain account and billing records; your content was never here to take.
• • Control. You revoke access to a public tool by asking, and wait. You revoke Centurion’s by unplugging the machine — and it keeps working, because it never needed us in the loop to function.
• • Lifespan. A hosted assistant stops the day the vendor decides it does, or the day the vendor stops existing. Centurion runs on hardware you already own, in open formats, with no service of ours to switch off. That is a far weaker dependency than any SaaS contract, and it is the difference between leasing capability and owning it.
• • Accountability. There is nothing to negotiate in a data processing agreement about a copy that does not exist. That is not us dodging the paperwork — it is the paperwork being short because the risk is not there, and a shorter review is a faster approval.
• • Verification. We do not ask you to believe a security page. Every claim here is checkable: read the activation request before it is sent, verify the signature on what you install, watch the outbound traffic yourself. Confidence that cannot be tested is marketing. This can be tested.

Where a public tool genuinely wins, we will say it plainly: nothing to install, nothing to maintain, nothing to look after. That is real, and it is why they are popular. It is also a trade — convenience bought with a copy of your work held by somebody else. For the person who has to defend the decision, that is the wrong trade, and it is the one being made by default across most organisations right now.

Your Soul document, your memory, your projects, your files and your conversation history are stored on your machine. They are not replicated to us, and we have no facility to read them. Not by policy, not by support access, not by an internal tool we promise not to use — there is no channel.

No account of ours is required for the system to operate, so there is no central store of your content to be breached, subpoenaed or leaked. It is worth sitting with how unusual that is. For almost every AI product on the market, the honest answer to "where is my data" is "on our servers, under our terms". Here the answer is a room in your building.

The subpoena point is the one an IT reviewer tests hardest, so it has its own answer: see 16.

We are exact here on purpose, because this is the answer a sceptical reviewer reads twice. The following is the complete list of outbound traffic the software originates, and what each one carries.

• Inference — your prompts go to whichever model provider is configured. With a cloud provider (DeepSeek by default, and the Brain also supports OpenAI, Anthropic, xAI, Google, MiniMax, OpenRouter and Nous Research) your prompt text leaves the machine and is handled under that provider’s terms. With a local model via Ollama, nothing leaves at all. This is the one line where the answer depends on your configuration, and the one you should interrogate hardest.
• Licence check — see 06. Three requests to our licence server: activation, a check-in at most every 30 days while the licence is live, and a re-issue if hardware fails. None carries content.
• Update check and download — the installer and its manifest come from a public release bucket. No configuration or usage data is transmitted.
• The phone Remote — when used away from your network, it connects through a relay we operate. The relay carries the session; it is not a store of your content. Use it on your LAN only and the relay is never involved.
• Support, if you open a ticket — you send what you choose to send. Nothing is collected automatically.

No telemetry. The software ships no analytics SDK and we operate no telemetry endpoint — verified 22 Sep 2026 by reading the outbound endpoints and the dependency set, not by asking the developers. Usage statistics do exist, but they are computed and stored locally on your machine for your own /insights view, and are never transmitted to us.

This is the only automated contact with our servers, and it is smaller than most vendors’ telemetry. Rather than describe it in the abstract, here it is field by field, read out of the source. There are exactly three requests: activation, a recurring check-in, and a re-issue after hardware failure.

The check-in exists for billing integrity, not for observation. It is how an expired licence learns it has a grace period, how a renewal takes effect, and how a licence that has been revoked finds out. That purpose needs a heartbeat, and a heartbeat is a fact your reviewer should see rather than discover.

• • Activation — POST /license/activate. Seven fields, five distinct values: the activation code you were issued, sent twice (code and activation_code); one device fingerprint, sent twice (hardware_id and machine_fingerprint — see 07); an install identifier generated on your machine; the API key, if your configuration has one; the licence tier. It runs at activation, and again only if a machine needs re-issuing after hardware failure.
• • Check-in — POST /license/checkin. Eight fields: your licence identifier, the install identifier, the device fingerprint, the licence tier, the last licence state held locally, the Centurion version, an operating-system string of the form “Linux 7.2.11” (system and kernel release only), and a random nonce generated fresh for that request. Nothing else is added.
• • Re-issue — POST /license/reissue. Six fields: the licence identifier, the token identifier, the old device fingerprint, the new one, a reason string, and proof of purchase if you supplied it. It runs only when a machine has failed and you ask us to move the licence — never on its own, and never on a schedule.
• • How often — at most once every 30 days by default, and only while the licence is in a live state (trial, active, expired or in grace). Our server can ask for the next check earlier, and that instruction is what the machine honours. A machine with no licence, or a locked one, sends nothing.
• • The user agent — the one thing your network monitoring will see that is not a payload field: requests identify themselves as CenturionBrain/<version> (+https://www.1human1ai.com), because a default Python user agent is blocked by the CDN. No hostname, no username, no domain account, no machine name.

No files. No prompts. No conversation content. No directory listing. No installed-software inventory. No hostname — and that omission is deliberate, see 07. If you would rather verify this than read it, enable outbound logging for a month and compare the tally against this answer, field by field. Being caught out is more useful to us than being believed.

A licence has to be bound to something, or one licence serves a thousand machines. We bind it to a hash derived from the following, and nothing else:

• • an OS-level machine identifier (the platform UUID on macOS, /etc/machine-id on Linux, the MachineGuid on Windows)
• • the board or SMBIOS serial, where the hardware exposes one
• • the operating system family
• • the install identifier

The hostname is deliberately excluded, because it is trivially changed and would therefore have made the fingerprint unreliable — a decision recorded in the source. The values are combined into a single hash; the raw identifiers are not transmitted as a machine inventory.

Releases are published to a public bucket with a published SHA-256 checksum for every artefact. You can verify the checksum before you run anything, and we would rather you did.

Security patches ship as part of the licence. There is no separate support tier to buy in order to stay patched, and no upgrade gate that withholds a fix — a commercial incentive to leave you vulnerable is one we have removed rather than promised against.

• • Every installer publishes its SHA-256. Verify it.
• • Every Linux installer carries an OpenPGP signature on the RPM. Import the key once and Fedora verifies the publisher and the payload before installing.
• • Patches are not gated behind a support tier.
• • Release notes name what changed, including security-relevant changes.

Signed as of 23 September 2026: our RPMs carry an OpenPGP signature from Centurion AI. The public key ships with the release (`centurion-release-pubkey.asc`) and its fingerprint is 25CB 4090 1F83 44D3 704F 9A4A C9E7 4757 8FA4 1F8F. Import it once — `sudo rpm --import centurion-release-pubkey.asc` — and the “unknown publisher” warning stops appearing. You are still verifying by checksum as well; the signature is added to that, not a replacement for it.

Centurion is a one-person, one-machine system. There are no user accounts, no seats, no roles to assign, no admin console for a compromised credential to unlock, and no web portal to sign in to. The machine has no inbound connection, so there is no remote login for a second factor to protect.

That makes MFA — the correct question for a SaaS product — the wrong control for this one, and it deserves a precise answer rather than "not applicable". What actually guards the machine is stronger than a token in one respect that matters: a token protects a door, and this system has no door.

• • Nothing to reach. Inbound traffic is dropped by a dedicated firewall zone: no open ports, no allowed services, ssh and mDNS disabled. There is no service to authenticate to.
• • The disk is encrypted with LUKS, unlocked by the machine’s own TPM. A drive removed from the unit is unreadable, and the machine still restarts unattended after a power cut.
• • One local account, protected by the machine passphrase, inside a building you already control. At one user, physical custody carries more weight than any token ever will.
• • Our side, since it is a fair question: staff access to licence administration requires TOTP authenticator codes. That is our exposure, not yours — but yes, we use it.

Where a second factor genuinely belongs: the phone interface. Used from a mobile, the assistant runs through a messaging platform on an account in your name — that account should carry its own two-step verification and the phone a passcode. A stolen, unlocked phone is the realistic path into this system. Add a second user, or expose the machine beyond your LAN, and MFA comes into scope immediately — and at that point we would tell you to require it.

Small vendors get asked this, and most answer it badly — which is why the answer is worth having in writing.

You own the computer. The software is installed on it and runs locally. If this company disappeared tomorrow: the machine keeps working, your data keeps working, and your files stay readable, on hardware that is already yours and already in your building.

• • Your hardware is yours outright. Nothing is leased, nothing is reclaimed, nothing is bricked by a licence server going quiet.
• • Your data is on your disk, in open formats, not in a service we can switch off.
• • The agent runs locally; you would lose updates and support, not access. That is a weaker dependency than any hosted product, where the same event means the tool stops that day and your data goes with it.

What we will not claim: that nothing breaks. A cloud-model configuration would stop, because that dependency is the model provider’s, not ours. An on-board model removes that dependency, at the cost of a smaller model — we would rather say that plainly than let it be discovered.

The machine and its contents are outside this list entirely. What follows is the complete set of third parties involved in operating our business, and what each one sees.

• • Vercel — website and API hosting
• • Supabase — account, licence and subscription records
• • Stripe — payment processing; card data never reaches us
• • Resend — transactional email
• • GoHighLevel — enquiries and CRM
• • Cloudflare — CDN and edge protection
• • Your chosen model provider — prompt text only, if you run a cloud model. Not involved at all when an on-board model is installed.

Account, billing and support data traverse these parties. Your Centurion content does not — it never reaches any of them, because it is not collected from your machine in the first place. Count the list against any public AI assistant’s subprocessor page and the difference is not subtle.

Do not skip this answer. It is the reason to believe the other fifteen, and it is the one a small vendor usually leaves out.

We hold no SOC 2 report. We hold no ISO 27001 certification. We have not published a third-party penetration test. We are a small company with a small team, and no audit has been commissioned by anyone yet.

• • Request SOC 2 or ISO 27001 and the answer today is: we do not have one.
• • Request a pen test report and the answer is: none published.
• • If your policy requires either before you can approve, that is a real blocker, and you should say so rather than let us imply otherwise.

Here is the part that matters, and it is not a consolation. A SOC 2 report attests to the controls around a service that holds your data. There is no such service here — no tenancy, no vendor-side store, no shared environment to audit on your behalf. That does not make us certified; it makes the certificate a different instrument. What we can evidence instead: the source-level facts throughout this page, a published checksum and OpenPGP signature for everything you install, and the actual activation request your machine will send, handed to you to read before it goes out.

This is not a feature comparison. Features age badly and you can read them anywhere. This is the one question that decides whether an IT department can approve a tool that reads your documents: who else can see what it processes, and who can switch it off.

Where a vendor has answered that question themselves, we quote them rather than characterise them. Every quotation below was re-read on the vendor’s own site on 22 September 2026, and the source is named for each. If any of them changes their terms, this page is out of date and we want to know.

• Cloud assistants — Anthropic, in its own privacy policy: “We may use your Inputs and Outputs to train and improve Anthropic AI models, unless you opt out through your account settings. Even if you opt-out, we will use Inputs and Outputs for model improvement when: (i) your conversations are flagged for safety review…” Your data sits on their infrastructure, under their terms, and their reviewers can read it.
• Google Gemini, on screen automation, in its own support documentation: “Gemini takes screenshots, which can include any info visible in the app. Screenshots are reviewed by trained reviewers and used to improve Google services if Keep Activity is on. Don’t enter login or payment information into Gemini chats.” That is Google telling you plainly not to put sensitive information in front of it.
• Grok Bot — xAI’s own product page: “Every Grok Bot shares one persistent cloud computer. Your Bots share that machine (files, browser, logins)… Isolation is per user, not per Grok Bot.” Isolation by user rather than by bot, on a machine that is theirs and not yours.
• ClawBox — a legitimate comparison, and they ship real hardware you do own. That is the right instinct. The honest difference is what runs on it: you own the box, and somebody else’s project owns what runs inside it — software you did not select, cannot audit, and cannot hold to a standard.
• OpenClaw, Hermes Agent, Ollama — these are allies of this position, not targets. Open-source and self-hosted, they are far closer to what we do than to the cloud, and we would rather be honest about that than score a cheap point. The real difference is build-it-yourself against an accountable vendor: you can install one yourself for nothing, and then you own the maintenance, the upgrades, the security patches and the consequences, with nobody to warrant the result.
• Apple — the strongest of the cloud-side positions, and the benchmark rather than a target. Apple Intelligence runs on-device with Private Cloud Compute, and Apple’s own material states the data is not stored or made accessible to Apple. That is genuinely good, and it is still only half the answer: the second half is that you did not choose it, cannot hold it to a standard you set, and cannot switch it off.
• Centurion — your content is stored on your machine and is never collected from it. The licence check transmits a device fingerprint and no content, and every field it sends is named in answer 06. There is no analytics SDK and no telemetry endpoint. With an on-board model installed, the model provider is removed from the chain as well, so inference is local and nothing leaves the building at all.

We have deliberately not scored ourselves perfectly everywhere. We hold no SOC 2 and no ISO 27001, and our RPMs were signed on 23 September 2026 — see answers 08 and 12. A comparison that ranks its author first on every line is a comparison you should not believe, and you would be right not to.

If you or your team find something, we want it — and we would rather hear it early from you than late from a journalist. Write to the security address below with enough detail to reproduce it, and you will get a human reply rather than a ticket number.

We will tell you when it is fixed, and — where it affected you — what it meant.

We do not operate a paid bounty programme. We do credit reports publicly when the reporter wants that.

If you are the person who has to approve this, send us your data-protection questionnaire, your security review template, or your vendor onboarding pack. Any format.

A commercial answer to a security question is worth nothing to you, because you are the one who has to sign it. We would rather send the unimpressive true answer than the impressive one you cannot rely on — and we have found that the true answers here are the impressive ones.

Say what you need, and we will tell you plainly whether we can meet it. If we cannot, you have saved yourself a procurement cycle.

This is the question that separates a privacy policy from an architecture, and it turns on one fact: a legal demand is served on whoever holds the record. It cannot reach a copy that was never made.

So the answer has two halves, and the first one is not flattering. We can be compelled to produce what we hold about you — the name on the licence, the billing record, the email address, the device fingerprint and the licence history named in 06. We cannot be compelled to produce what you wrote, because it is not here. There is no server of ours holding a single document, prompt or conversation from your machine.

• • What a demand would reach — licence and billing records. We would produce the narrowest set the order requires rather than a dataset, and where we are permitted to tell you, we would.
• • What it cannot reach — your documents, your assistant’s memory, your projects, your conversation history. They sit on your disk and nobody at this company can read them, so there is nothing for us to be ordered to produce.
• • The comparison, in a vendor’s own published numbers — OpenAI counts these demands and publishes the tally. July–December 2025: 224 non-content requests (subpoenas for name, email, payment and transaction history), with data disclosed in 146 of them; 75 content requests (warrants for prompt text and files), with data disclosed in 62. The same two categories were 29 and 8 in the first half of 2024, 57 and 13 in the second, and 119 and 26 in the first half of 2025 — a doubling roughly every six months. Those figures exist because there is a central store to demand. For the machine in your building the equivalent number is zero, and it is zero because the record does not exist.
• • Where this weakens, stated plainly — if you run a cloud model, your prompt text is held by that provider under their terms, and a demand served on them is a demand on your content. We cannot answer for their counts or their disclosure decisions. An on-board model removes that party from the chain, and it is the configuration to choose if this question reaches your board.

No vendor can promise to resist a lawful order and we will not pretend to. What we can point at is how little there would be to collect. If you are reviewing an AI vendor, ask them for their count of content demands — then ask what the equivalent number is for the record that never left your building.