How your work is kept safe.

Your own sealed container

Each company gets its own container: its own running copy of the cockpit, its own agents, its own encrypted storage, its own keys and users. Nothing about your account exists inside anyone else's copy, so there is no query that could reach across. The separation is enforced by the operating system itself, the same mechanism that keeps two programs on your laptop out of each other's memory, not by a rule we wrote and have to remember to apply.

Each container also sits on its own private network. Your cockpit has no name and no route for anybody else's, so there is nothing to address in the first place. The one thing that crosses between a hosted cockpit and us is a liveness check, which sends no credential and reads nothing back but the fact that you answered.

One limit, stated plainly because you would otherwise assume otherwise: running several cockpits on a single laptop, which is how a developer tries the product, is a convenience and not a wall. The hosted shape is the isolated one, and it is the one every customer runs.

One opening, and a person in it

The crew can plan, build and review as fast as it likes, but the actions that matter are structurally out of its reach. Agents cannot commit, push, merge, deploy or spend beyond the caps: those commands are refused at the tool level, and each one exists only as an explicit human press. Code work happens in isolated copies, so your live product is never in the same room as an agent. Even if an agent were tricked by malicious text into trying something, the attempt is blocked before the command runs and recorded on the mission's trail with the time, so you see that it was tried and that it failed.

Three promises hold that opening shut, and they are guarantees rather than habits:

• Whoever approved has a name. Every approval records which of three things happened: a person, a schedule that ran a routine unattended, or a work type that never had a gate. Only a person reads as approval. Nothing in the record implies somebody said yes when nobody did.
• A concern has to be seen. When the reviewer raises a concern about a change, the actions that would carry it forward are refused until whoever holds the ship gate has read the reviewer's words and acknowledged them, and that acknowledgement is kept with their name and the time. A later, different concern has to be read again. Stopping, pausing and discarding are never blocked, and acknowledging is not agreeing: the work can still go straight back. This blocks shipping without seeing, not shipping.
• Isolation is not best effort. Code work happens in an isolated copy of your repository. If that copy cannot be created, the task fails and tells you so, and no agent is started. It is never downgraded into working on your live checkout, because the point of a guarantee is that it holds on the bad day.

Promoting anything to production also asks you to type a confirmation, from every route that can promote. It is small friction, deliberately placed at the one irreversible moment, and there is no quieter door.

Everything that ran is written down

Carth keeps an activity log, under Missions in the "Activity log" view. Every agent run lands there with what it produced, and deploys and dev verifies land in the same record. It is written as the work happens, it survives clearing the missions, and it is not editable from the interface, by you or by us. It exists so you can answer the questions a board member or an auditor will eventually ask: what ran, what did it produce, and what reached production. Blocked attempts and gate decisions also leave their marks on each mission's own trail, alongside the evidence the approver saw. The log keeps a rolling history rather than growing without end, and the oldest entries eventually age out; if you need a longer retention than the default, say so and we will set it.

Keys go in and never come back out

The credentials you give Carth, repository access, database access, AI provider keys, are stored write only. You can set one and you can replace one, but no screen will show it back, and no user of any role can read it out. They are encrypted where they sit, under a key held by your container and never written into the storage that key protects, so a copy of the storage on its own opens nothing.

An agent starts with the model provider key its engine needs to speak to the model, and nothing else of yours: not the key to the store, not your repository token, not your database or backup credentials. Text is scrubbed of keys, tokens, connection strings and email addresses before it is written to the mission and agent logs, on the way in rather than the way out.

What an agent can reach, and what it cannot

An agent is not a magic process with the run of the machine. It is started with a named list of the tools it may use, decided by the kind of work it was asked to do and fixed in the software rather than in a settings file, so a tool that is not on the list is not refused at the last moment, it is never offered. Reading work gets reading tools. Building work gets an isolated copy of the repository and the ability to write inside it. Committing, pushing, deploying, publishing and touching a database schema are on none of the lists, because those are the moments a person owns.

What it cannot reach is the part worth stating clearly: your credentials store, the settings that hold it, anything belonging to another company, your live branch, and production. Those are not policies an agent is asked to respect. They are absent from the world it wakes up in.

And the limit, because you should hear it from us rather than discover it: an agent can talk to the internet. It has to, since the model itself lives there and a good deal of real work is reading documentation. Carth does not today restrict which addresses an agent may call. The wall is around what an agent is holding, not around where it can speak, which is why the paragraph above is about what never enters its hands in the first place. If your policy needs outbound filtering, tell us in your application and we will tell you honestly what we can do about it today.

Your data stays yours

We do not train models on your code, your documents or your figures, we do not feed one company's material into another's work, and we do not sell data. Running a mission does send the relevant material to an AI model provider, because that is how the work gets done, and we use providers on terms that exclude training on it. If you would rather that relationship be your own contract, you can run on your own provider keys. Questions against your business numbers run on a local copy of your database through an access that is physically read only, so not even a badly behaved query could change anything.

Access you can take back

Seats are people, each with their own sign-in link and their own role, and there is no shared password. Revoking someone ends their session immediately, and what they approved stays in the record under their name. The details are in getting access.

What we do not have

Carthagent is an early stage company, and this page would be worth less if it hid the gaps: we do not yet hold a third party security certification, publish an uptime guarantee on standard plans, or have an external penetration test to point at. The full, current list is kept honestly on the trust page, along with data residency choices, deletion and backups, and the Enterprise arrangement where the whole cockpit runs inside your own infrastructure. The legal commitments live in the terms of service, the privacy policy and the data processing agreement.