Security

Your repositories and worktrees stay on infrastructure you operate. We do not host a copy of your source files, and we do not proxy your model traffic. Your chosen harness sends what each task needs directly to its model provider, under your agreement with that provider.

In the installed product, execution is local and the knowledge plane is local by default: the knowledge your agents build up lives in Postgres on your own machine and we hold no copy of it. When toryo itself crashes, and when an agent harness it started crashes or refuses to start, it sends us a report of that failure: its own stack, the error message with secrets redacted and paths collapsed, and which command failed. The report has no field for your environment, your keys, or the bodies of what toryo sent and received. Its one free text is the message, which is whatever the failing code put in it, so it can quote a fragment of what toryo was processing. That is what the redaction, the path collapse and a 500-character cap are for. You can turn that off, and the privacy notice lists exactly what one contains.

Team and Enterprise include a shared knowledge plane, so a team’s agents learn from one another. A team starts with its knowledge on its members’ machines. If the team’s owner turns on hosting, the shared knowledge moves to a service we run. Enterprise teams can run that service themselves instead. The section below says what it holds and what we never hold.

Your repository lives on your machine. toryo drives your coding agent against the repository already sitting on your disk. There is no cloud sandbox, no build container of ours, and no upload step. An agent working on your repository is a process on your laptop.

The knowledge your agents accumulate, the memory, the library, and the code index, is Postgres running locally by default: either in Docker or as an embedded pglite runtime. That database is yours.

A team that turns on hosting keeps its shared knowledge with us instead. That includes a code index built from your files, which carries their comment text. The section on hosted knowledge below says exactly what it holds.

Straight from your machine to the provider, under your own credentials. We do not supply model access, mark it up, or sit in the path, so nothing about your prompts or your agents’ output passes through us.

Two small jobs inside toryo use a model rather than an agent. One turns text into vectors for search. The other judges whether a memory is worth keeping. By default both run locally against Ollama on your own machine. On a hosted team, each member’s machine computes the vectors and sends them with what it writes. No model runs on our hosted service, and it refuses to run one.

Not your code, not your prompts, not your agents’ output, and not your knowledge. Knowledge kept on your machine is never with us to train on. A hosted team’s knowledge is with us only so we can serve it back to that team. No model runs on the hosted service, and we do not train one on what it holds.

The website also holds signup records and, when enabled, optional audience measurement of public page displays, including daily visitor hashes and visit records. The privacy notice describes the measurement fields, retention and browser opt-out.

Licensing records: your email address, the seat and plan it belongs to, and an identifier for each machine you activate on with its first and last check-in. The privacy notice lists this in full.

Machine identifiers exist so one seat covers all of your machines rather than being consumed by the first. They are not device fingerprints.

We also hold a crash report each time toryo itself fails, or an agent harness it started crashes or refuses to start, unless you have turned that off. It carries toryo’s own stack, a scrubbed message, and which command failed; the privacy notice lists the whole of it.

The license service never sees Claude credentials. There is no field for them and no code path that would accept one: your subscription and your keys exist only on your own machine.

Every mutating admin action on that store appends an audit row, and the data sits on a provider that encrypts at rest with continuous point-in-time backup.

For a team that hosts its knowledge with us, we also hold that team’s shared knowledge, described below. To run the service we look at counts per team, such as how many items are stored and how many requests arrive, not at what the items say.

Hosting is off until the team’s owner turns it on, and members cannot override that choice. Teams that do not turn it on keep the local plane, which is not a deprecated path and will not become one. When a team turns hosting on, its knowledge lives on our hosted service by default. An Enterprise team can run the service itself instead. A self-run service is the same software, shipped as compiled programs, and it sends us no error reports.

What it holds. Memories and library documents, each with the vectors your members’ machines computed. Project definitions: a name, a git remote, and settings such as verification commands and sensitive paths. And the code index. The code index is file paths, a hash of each file, exported names, the import graph, and comment text: the comment at the top of each file and the doc comment on each exported name, up to 8 KB per file. It holds no function bodies and no code that is not exported. Library documents hold whatever your team puts in them, so treat the library like a shared wiki.

What we never hold. Your repositories. Your session transcripts: the judge that reads them runs on your machine. Your personal knowledge, the kind that spans all of your projects. And the record of your runs and jobs.

How teams are kept apart. Row-level security is forced on the knowledge tables. The service connects as a restricted database role, and every transaction is bound to one team, so a bug in our code cannot return another team’s rows. Only seats of your team are admitted, checked against a signed license. A removed member loses access within a day.

The store is encrypted at rest and backed up continuously with point-in-time restore.

What we see. Counts per team, not what the items say. When our servers hit an error, they send a report to Sentry. It carries a scrubbed message, the stack, which service failed, and the request method and path. It never carries the query, the headers or the body. The message can quote a fragment of what the server was processing. Your crash-report setting does not cover our servers.

Removing a team’s data is deliberately two steps that cannot be confused for each other. Cutting access is reversible and touches no data. Destroying the data is separate, irreversible, and gated behind an explicit confirmation, so “revoke this now” can never quietly become “delete this forever”.

Activation checks in once and receives an Ed25519-signed proof your install caches. Everything after that is evaluated from the cache, so your day-to-day work never depends on our service being reachable, and a failed check-in on a paid license never blocks you.

The practical consequence is that toryo keeps working on a plane, behind a corporate proxy, or if we have an outage.

macOS builds are signed and notarized, so they open without a Gatekeeper warning. Every release publishes a SHA256SUMS file, and the downloads page shows each artifact’s hash so you can verify it before installing.

A great deal, by design: it writes code, runs commands, and opens pull requests. That is the product. It is worth being clear-eyed that this is a tool with real reach into your development environment.

The controls are yours. Sequences stop at approval gates you answer, work happens in isolated git worktrees rather than your working tree, and changes arrive as pull requests you review before merging. When a run needs a decision it messages you and waits, rather than guessing and carrying on.

It also reaches outward when a task needs it. A worker can be given a headless browser so it can read pages a plain fetch cannot, and the research sequence turns that on by default. That browser is a self-contained instance toryo spawns for the run, separate from the one you use.

The general rule is worth stating plainly, because it is the answer to most questions of this shape: toryo can do what your agent is configured to do, and nothing more. It drives the agent you already installed, with the credentials, permissions, MCP servers and tool access you already granted it. It does not widen that surface, and it has no privileged path of its own. If you would not want an agent session doing something, do not configure your agent to be able to, and toryo will not be able to either.

No SOC 2, no ISO 27001, and no HIPAA attestation. We are early, and we would rather say so than imply a compliance posture we have not earned.

If your procurement process needs one of those, tell us what and by when, and we will give you a straight answer about whether we can get there rather than a reassuring one.

Email support@toryo.ai with anything you find. We would rather hear about it early and awkwardly than late.