Security
Agents work inside boundaries you set
This page describes the mechanisms, in the same words the product uses: isolated worktrees, review gates, read-only investigations, automatic rollback. It also lists, without hedging, the certifications we do not hold.
Mechanisms
What actually holds the line
Eight things the platform does today. Each one is a control you can inspect, not a property we claim.
An isolated worktree per task
Every task runs on its own branch in its own git worktree. Parallel work cannot collide, and one agent cannot read another's half-finished changes.
Review gates that stop work
Flag any role as requiring review and dependent tasks stop until a human approves. This holds at every autonomy level, including Autonomous.
Read-only investigations
An investigation opens with read-only access. It reads logs and runs your diagnostics command. Write access is a separate grant a person makes.
Automatic rollback
A failed health check triggers the rollback command you wrote, returning the target to the last commit known to be healthy.
Encrypted credential storage
SSH keys and git tokens are stored encrypted and are never returned to the interface or printed into run output once saved.
Per-project deployment targets
A deployment target belongs to one project. A project cannot deploy to a target it does not own, so a client's server stays reachable only from that client's work.
Ownership boundaries
Projects, repositories, teams and targets belong to one account. Owner and admin roles decide who inside it can approve plans, grant access and connect servers.
An audit trail by construction
Every task ends in a structured report — summary, files modified, risks, assumptions, recommendations, blockers — beside the branch, the diff and the run log.
In detail
Three boundaries, drawn precisely
Isolation, review and access. Everything else on this page follows from these three.
Isolation
Work happens on a branch, in a worktree, or it does not happen
There is no path by which an agent edits your working copy. Each task is given a base branch, a new branch and a worktree of its own, and it can only write there.
- One task, one branch — the branch name and the worktree path are recorded on the task, so you can check out exactly what an agent did.
- No shared scratch space — two tasks running at once cannot see each other's files, which also removes a whole class of merge accidents.
- Abandonment is free — an abandoned task is a deleted branch. Nothing has to be unpicked, because nothing was merged.
-
Dependencies wait — a task whose
depends_onlist is unfinished does not start, so partial work is never built on.
T-02 task/t-02-auth-migration → .worktrees/t-02
T-04 task/t-04-sca-challenge → .worktrees/t-04
T-05 task/t-05-challenge-modal → .worktrees/t-05
Review
A gate is a stop, not a notification
Marking a role requires_review halts everything downstream of its work until a person approves. Autonomy level does not override it.
- Plans need approval first — nothing is dispatched from a plan you have not approved, unless you deliberately set the project to skip that step.
- Governance roles can reject — the Architect, Code Reviewer and Security Engineer return work rather than merely commenting on it.
- Agents ask when they are unsure — a specialist that hits genuine ambiguity pauses and puts a question to you instead of guessing.
- Merges are visible — you see the diff, the reviewer's verdict and the security note before anything reaches your default branch.
Access
Production access is granted, never assumed
When a deployment fails its health check, an investigation opens automatically at the lowest access level and stays there unless a human raises it.
- Read-only is the default — the agent reads logs and runs the diagnostics command you defined on the deployment target. That is the whole of its reach.
- Write access is explicit and per-investigation — raising the level is a deliberate act by a person, recorded on the investigation, and it does not persist to the next one.
- The output is a summary, not a change — an investigation ends by writing up what happened and, if you want it, opening a follow-up request containing the fix.
- The fix goes through the front door — that follow-up request is planned, built, reviewed and deployed like any other. Incidents do not create a bypass.
Opened by the failed deployment of REQ-142
Read journalctl -u tilltap-api on prod-web-1
Cause found — SCA_PROVIDER_KEY is not set on the production host
Opened REQ-143 to add the variable to the deploy configuration
Data handling
What we do with your code, stated plainly
Commitments, not aspirations. If one of these stops being true, this page changes before the product does.
- We do not train models on your code. Not on your repositories, your requests, your plans, your reports or your run logs.
- Repositories are cloned to run your work. That is the reason we hold a copy, and it is the only reason.
- Your code lives in your repositories. Agents commit to branches in the remote you connected. We are not the system of record.
- Deploys go to your servers. A deployment target is your SSH host, running your deploy command against your infrastructure.
- You own the credentials. Revoke a git token or an SSH key on your side and our access ends immediately, with no request to us.
- Export whenever you like. Requests, plans, tasks and reports come out in a machine-readable form, before or after you cancel.
- Working copies are disposable. A task's worktree exists for the run and the branch that came out of it, not indefinitely.
- Deletion means deletion. Cancel and we keep the account readable for 30 days, then remove it and its clones.
- Model providers process, they do not keep. Work is sent to model providers under agreements that forbid training on it, and Business customers can supply their own keys instead.
- Support does not browse. Our staff do not read your repositories to answer a support question; access for debugging is requested from you and time-boxed.
Access model
Who and what can reach your systems
Four kinds of person, three kinds of agent access. Nothing else has a route in.
Owner
Admin
Member
Viewer
Agent — repository access
Agent — deployment access
Agent — investigation access
read_only: logs and diagnostics, nothing more. Raising it to write is an explicit human decision, recorded on the investigation and limited to it.Capability substitution
Responsible disclosure
Reporting a vulnerability
We would rather hear it from you than from an attacker. This is our whole process; there is no separate portal and no intermediary.
How to report
Email security@capybari.com. Include:
- what you found, and the URL, endpoint or component it affects
- the steps to reproduce it, in an order that works
- what an attacker could do with it
- how you would like to be credited, or that you would rather not be
Write in English. Attach a proof of concept if you have one. Do not include third-party data, and stop as soon as you have demonstrated the issue.
What we commit to
- Two working days to acknowledge your report with a human reply.
- Ten working days to give you our assessment: whether we have reproduced it, how we rate the severity, and what we intend to do.
- Regular updates while a fix is in progress, without you having to chase.
- Credit in our changelog when the fix ships, if you want it.
- A public note on the changelog for any issue that affected customer data, whether or not it was reported externally.
We do not run a paid bounty programme yet. We say so rather than implying one and haggling afterwards.
Safe harbour
If you make a good-faith effort to follow this policy, we will not pursue or support legal action against you, and we will say so in writing if a third party comes asking. Good faith means:
- you test only against accounts and data you own
- you do not degrade the service for anyone else
- you do not access, alter, copy or retain other customers' data
- you give us reasonable time to fix the issue before you publish
If you are unsure whether a test crosses one of those lines, ask us first. We answer quickly.
In scope
capybari.comand the marketing site- the Capybari application and its API
- authentication, session handling and multi-tenant isolation
- credential storage, deployment execution and investigation access levels
Out of scope
- findings from automated scanners with no demonstrated impact
- missing hardening headers, cookie flags or TLS configuration with no exploitable consequence
- rate limiting, denial of service, volumetric or stress testing
- social engineering, phishing or physical attempts against our staff or suppliers
- vulnerabilities in your own connected repositories, servers or deploy commands — we will still tell you about them, but they are yours to fix
- reports that depend on a compromised device or a prior credential leak
Contacting us securely
Ask on the first email and we will send a PGP key for the follow-up. Please do not post details in a public issue tracker, in Discord or on social media before we have replied.
What we do not have
The gaps, stated before you ask
If any of the following is a hard requirement for you today, we are not your platform yet. Better you know now.
Questions
What people ask before connecting a repository
Do you train models on my code?
No. Your repositories are cloned so agents can run the work you asked for. We do not train models on your code, your requests, your plans, your reports or your run logs.
Work sent to model providers goes under agreements that forbid training on it. On the Business plan you can supply your own model keys and cut us out of that relationship entirely.
What can an agent actually reach?
The repositories connected to the project its task belongs to, on its own branch in its own worktree — and, if you have defined one, the deployment target for that project.
It cannot reach another project's repositories, another customer's anything, or a server you have not connected. The access model above sets out each level.
Can an agent push to my default branch?
Not directly. Work happens on a task branch. Reaching your default branch requires the review gates you configured to pass and a merge step to succeed.
Mark any role as requiring human review and everything downstream stops until a person approves — at every autonomy level, including Autonomous.
How are my SSH keys and git tokens stored?
Encrypted at rest, and never shown again once saved: not in the interface, not in a report, not in live run output.
They are used to clone the repositories you connected and to run the commands you defined on the deployment target you connected. Revoke them on your side at any time and our access ends immediately.
What happens if a deployment goes wrong?
Your health check fails, your rollback command runs against the last commit known to be healthy, and an investigation opens with read-only access.
The investigating agent reads logs and diagnostics, writes up the cause and can open a follow-up request with the fix. That fix is planned, reviewed and deployed like any other work. An incident does not create a shortcut.
Can I use Capybari without giving it a server?
Yes, and plenty of teams do. Without a deployment target the platform plans, builds, reviews and reports — and stops at the merge.
You then ship it however you ship things today. Deployment access is something you add when you want it, not a condition of using the product.
Who at Capybari can see my code?
Our staff do not read customer repositories to answer support questions. Where debugging genuinely needs access, we ask you first and the access is time-boxed.
We are a small company and we will not pretend to controls we have not built: read the gaps above for the assurance work we have not yet done.
Is my data isolated from other customers?
Projects, repositories, teams and deployment targets belong to one account, and every request is checked against that ownership before anything runs.
The infrastructure underneath is shared. We do not offer dedicated tenancy today, and we are not going to describe logical separation as though it were physical separation.
Where is the platform hosted?
On our own infrastructure in the United Kingdom and the European Union. Your code is deployed wherever your servers are — we run the commands, you own the hosts.
We do not offer a choice of region for the platform itself yet. Multi-region deployment targets are on the roadmap for Q4 2026.
How do I report a vulnerability?
Email security@capybari.com. The disclosure policy above covers scope, our response times, safe harbour and what falls outside it.
We acknowledge within two working days and give you an assessment within ten.
Running a security review of us? Send your questions — we answer in writing.
Start at Manual. Grant access as you earn trust.
Connect one repository, leave the project on Manual, and approve every step by hand. Add a deployment target the week you want one, and not before.
No card required · Read-only by default · Revoke our access from your side, any time