Where your data sits, and who can reach it.

1. 1. A container of your own
2. 2. Encrypted storage
3. 3. Access you can take back
4. 4. The audit trail
5. 5. Keys that go in and do not come back out
6. 6. What an agent can reach, and what it cannot
7. 7. We do not train on your data
8. 8. Bring your own AI keys
9. 9. Where your data lives
10. 10. Deleting everything, backups included
11. 11. Running Carth on your own infrastructure
12. 12. What we do not have

1. A container of your own

Most software that says it keeps tenants separate means one large database with a company column on every row, and code that promises to always filter by it. One mistake in one query and the promise is gone.

Carth does not work that way. Each company gets its own container: its own running copy of the cockpit, its own agents, its own storage. Nothing about your account exists inside another company's copy, so there is no query that could accidentally reach across. The separation is enforced by the operating system kernel, which is the same mechanism that stops two programs on your laptop from reading each other's memory, rather than by a rule we wrote and have to remember to apply.

The separation is not only inside the machine. Each container sits on its own private network, so your cockpit has no name and no route for anybody else's: there is nothing for it to address. The one thing that crosses from us to a hosted cockpit is a liveness check, which sends no credential of any kind and reads nothing back beyond the fact that you answered. Nothing about your work is ever the payload of a message between two installations.

A practical consequence worth knowing: because your cockpit is its own thing, we can move it, host it somewhere else, or hand it to you entirely, without untangling it from anybody else's data.

And one honest limit, because you would otherwise assume more than we mean. All of the above describes a hosted cockpit, which is what every customer runs. A developer can also install Carth on a laptop and run more than one project side by side there; that arrangement is a convenience for one person's own work, not a wall between two companies, and we do not sell it as one.

2. Encrypted storage

Your container's volume is encrypted at rest, and traffic between your browser and the cockpit is encrypted in transit with TLS. That covers the code the agents work on, the files they produce, the evidence attached to reviews, and the notes the system keeps about your business.

Backups are encrypted with the same protection as the live volume. They are held for a limited window and then expire on their own.

3. Access you can take back

People are added to your cockpit one at a time, by your own admin, with a role attached. Each person's access can be revoked immediately and independently, and revoking it ends their current session rather than waiting for it to expire on its own.

There is no shared company password to hand around and no generic login. Seats are people. If somebody leaves, you remove them and reassign their seat, and everything they approved stays in the record under their name.

4. The audit trail

Every decision that matters is recorded with who made it and when: approvals, rejections, deploys, budget changes, users added and removed, keys rotated. The record is written as the action happens and is not editable from the interface, by you or by us.

This exists so that you can answer a question you will eventually be asked, by a board member, an auditor or a customer: who authorised this, and what did they see when they did.

It keeps a rolling history rather than growing forever, so the oldest entries eventually age out. If your obligations need a longer window than the default, tell us and we will set it for your container.

5. Keys that go in and do not come back out

Carth needs credentials to be useful: access to a code repository, a database, a model provider. Those are stored write only. You can set a key and you can replace it, but no screen in the product will show it back to you, and no user of any role can read it out. That means a compromised login does not become a compromised set of credentials for every system you connected.

They are also encrypted where they sit, under a key that belongs to your container and is never written into the storage that key protects. A copy of the volume, on its own, opens nothing.

Where a service supports it, we ask for the narrowest credential that will do the job rather than a full access token.

6. What an agent can reach, and what it cannot

The word people mean when they ask about isolation is usually not the container at all. It is the agent: a program that reads your code and writes changes to it, running without anyone watching the screen. So it is worth saying exactly what one of them is holding.

An agent is started with a named list of the tools it is allowed to use, chosen by the kind of work it was asked to do. The list is fixed in the software rather than in a settings file, and it cannot be widened by a project setting, a configuration file left in a repository, or an instruction written into the work itself. A tool that is not on the list is not refused late: it was never offered. Reading work gets reading tools. Building work gets an isolated copy of the repository and the right to write inside that copy. Committing, pushing, deploying, publishing and altering a database are on none of the lists, because those are the moments that belong to a person.

What an agent cannot reach matters more than what it can. Your credentials store and the settings that point at it are not merely forbidden to it, they are absent from the environment it starts in, and an agent cannot even be pointed at that part of the disk: the attempt fails before the agent is created rather than being caught afterwards. Another company's material is not reachable for the reasons in section 1. Your live branch is not reachable because the work happens in a separate copy, and if that copy cannot be made the task fails and says so rather than falling back to your real one.

Now the limit, which you should hear from us rather than find out. An agent can talk to the internet. It has to: the model it thinks with lives there, and a good share of honest work is reading a supplier's documentation. Carth does not today restrict which addresses an agent may call. That is why everything above is about what never reaches an agent's hands in the first place, rather than about supervising where it speaks. If your policy requires outbound filtering, raise it in your application and we will give you a straight answer about what is possible today rather than a reassuring one.

7. We do not train on your data

Your code, your documents, your figures and everything your agents produce are yours. We do not use them to train models, we do not use them to improve a shared product, and we do not feed one company's material into another company's work. We do not sell data, and there is nothing in Carth that would make that possible without us obviously breaking this page.

Running a mission does send the relevant material to an AI model provider, because that is how the work gets done. We use providers on terms that exclude training on the content sent through the interface. If you would rather that relationship be yours rather than ours, see the next section.

8. Bring your own AI keys

You can run Carth against your own account with an AI provider. Your material then travels under your own contract with that provider, your own data retention settings and your own invoice. We never see the key after you set it, and we never see the bill.

This is included on the Enterprise plan and available on request for other plans.

9. Where your data lives

You choose where your container is hosted when your account is created. We offer hosting in the European Union and in Canada. Your choice covers the live system and its backups.

Tell us in your application which one you need, or ask us and we will suggest one based on where your company and your customers are.

10. Deleting everything, backups included

You can ask us to delete your data at any time, and you do not have to be leaving to ask. Deletion covers the live volume, the workspaces the agents used and the backups, and we confirm in writing when it is done rather than leaving you to assume it.

Backups are the honest complication in every deletion promise: a copy taken before your request has to expire on its own schedule, and until it does, it exists. We tell you the exact window rather than pretending it is instant.

Records we are required to keep for accounting, such as invoices, survive deletion. They contain billing details, not your working content.

11. Running Carth on your own infrastructure

Some companies cannot let their material leave their own walls, whatever the hosting arrangement. The Enterprise plan is for them: the whole cockpit runs as a container on infrastructure you control, with your own model provider keys.

In that arrangement we are not holding your data at all. We provide the software, the setup and the support, and you keep everything. Onboarding is included, because a deployment like this should not be a download and a wish of good luck.

12. What we do not have

Carthagent is an early stage company, and this page would be worth nothing if it were not honest about the gaps.

• We do not hold a SOC 2 report, an ISO 27001 certificate, or any other third party security certification. We are not going to display a badge we did not earn.
• We do not publish an uptime guarantee on the standard plans. A specific commitment can be agreed in writing on the Enterprise plan.
• We have not been through an external penetration test yet. When we have, this page will say so and will say who did it.
• We are a small team. That is why access is by application and why we onboard a limited number of companies at a time.

What we do offer is a straight answer to any security question you send us, and a security questionnaire completed by a person rather than deflected. The legal commitments behind this page are in the terms of service, the privacy policy and the data processing agreement.