YATFA
Trust center
What our agents can reach, where your code goes, and what is recorded — with each claim checked against the running system, not against how it was designed.
Last reviewed: Content owner: YATFA engineering [email protected]
Compliance status
Status only. No target dates are published, because none have been agreed.
| Framework | Status |
|---|---|
| SOC 2 Type II | We have not undergone a SOC 2 audit. |
| ISO 27001 | We have not been certified. |
| ISO 42001 | We have not been certified. |
We hold no third-party attestation today. What follows is the architecture a SOC 2 audit would examine: scoped access, container isolation, role-enforced permissions, tenant separation at the query layer, and a complete action log. We would rather show you the controls now than ask you to wait for a certificate.
Data flow
Where work and code actually move. Numbered so it can be checked rather than skimmed.
-
Execution starts on hardware you provide. You start the runner yourself — for example
npx yatfa workeron a machine you control, or agents managed on your machines by Warden. YATFA does not host agent execution. -
Your repository is cloned into the agent’s container. The working copy lives on your hardware, inside that container. We do not clone or mirror your repository server-side. What the service itself records is repository metadata and pull-request detail — commit messages, and the list of changed files with their line counts — read through the GitHub App.
-
Code context is transmitted to the model provider. Model inference runs through YATFA’s gateway: the prompts sent from the container include code from your repository, and they reach the model provider. For customer workloads we route to providers operating in the United States or the European Union whose terms restrict training on customer data (privacy notice). You can instead configure inference on your own provider account, per project.
-
Completions return along the same path. The model’s response returns through the gateway to the agent’s container, which applies it to the working copy.
-
What persists, where. The service stores the work record — tickets, knowledge articles, memories, action logs, and metrics. Your repository stays in your GitHub account; working copies stay on your hardware.
-
What is written back to GitHub. Branches, commits, pull requests, and comments — through the GitHub App installation you granted, and nothing beyond it.
Access model
Repository access is granted through a GitHub App installation, per repository. You approve it on GitHub and you can revoke it in one click from your GitHub settings; you never paste a repository credential into the product.
These are the repository permissions the App requests, exactly as GitHub shows them at install time:
| Permission | Access |
|---|---|
| Actions | Read-only |
| Code quality | Read-only |
| Commit statuses | Read-only |
| Contents | Read and write |
| Deployments | Read-only |
| Discussions | Read-only |
| Issues | Read-only |
| Merge queues | Read-only |
| Metadata | Read-only |
| Projects | Read-only |
| Pull requests | Read and write |
No account-level or organisation-level permissions are requested.
The App cannot reach anything you did not select: not other repositories in your organisations, not your infrastructure or cloud accounts, not your CI secrets.
Agent isolation
-
One container per agent. Each agent works in its own container, on your hardware, with its own filesystem. Agents do not share a filesystem with each other.
-
Its assigned repositories, and nothing else. A container sees the repositories assigned to the project it works on. It has no route to anything else.
-
Nothing durable inside. The working copy and everything built in a container exist only inside it. The work record — tickets, reviews, memory — lives on the server, so a container can be destroyed and replaced at any time, and starts again from a fresh clone of your repository. Destroying it destroys the working copy and nothing else.
Permission model
Permissions are enforced server-side, on two independent planes. The first plane is the tool surface: each role is offered only the tools its job needs. The second plane is the workflow itself: every state change is checked against the role of the caller, every time, by the server — not by the agent’s own judgement.
A worker instructed to approve its own work is refused at the transition layer even though it never touched a forbidden tool. Prompt injection buys nothing it did not already have.
Merging is gated by approval. Approval is a human action by default: workers and reviewers can never be given it, and a researcher can, but only behind a per-project toggle that ships off.
Tenant isolation
Every read and every search is scoped to the project making it — tickets, proposals, knowledge articles, memories, repositories, and logs alike. An agent working one codebase cannot read or search another project’s data; there is no cross-project surface for it to reach.
Data retention
We store these categories of project data: tickets and their history, knowledge articles, memories, agent action logs, and usage metrics. The retention schedule per category is being finalised and will be stated here once decided.
Subprocessors
A current list of subprocessors and our data processing agreement are available on request, at [email protected].
Audit and logging
Every agent action is recorded: each tool call and its outcome, key usage, every status change, and every review verdict, with timestamps. Members of a project can read its log, per project, from the web UI and the API.
Documents
A data processing agreement and a written security overview are available on request. Neither is downloadable today; both will be published on this page when they exist.
Contact
Questions about anything on this page: [email protected]. For pricing and commercial questions: [email protected].
Related
- Technical & Security Overview — how the system works, at a glance.
- Privacy policy — what we collect and how we process it.