Security
Where your code runs
Runner and MCP: jobs run in your GitHub Actions, your container or your IDE, not in our cloud. We receive the diagnosis, the reply draft and the reports; diagnoses quote short code excerpts unless .loopback.yml sets share: references-only.
Managed: one container per job, with CPU, memory and time limits, network access only to GitHub, the model gateway and package registries, and the clone deleted at the end of the job.
Whatever the mode, the demo ticket that follows the connection of a repository runs once in the Managed sandbox, at our expense, and its clone is deleted at the end of the job. On public repositories, external pull requests are analysed in the sandbox too, so code from forks never runs where your secrets are.
The only state kept between Managed jobs is the code index of the repository: encrypted in storage, and deleted when you disconnect the repository or after 30 days unused.
Secrets
- Keys and tokens are encrypted at rest with envelope encryption: AES-256-GCM for each record, the data key encrypted by a key management service.
- They are in clear only in memory while used. The interface shows only the last 4 characters, and logs and prompts are masked.
- Runners sign in with GitHub OIDC or with a token valid for one workspace; job tokens cover one job and expire after 60 minutes.
Isolation
- Row-level security in Postgres for every organization: a request reads and writes only the rows of its own organization.
- References between records always include the organization, so a record cannot point at another organization’s data, even by mistake.
- Nothing is shared between organizations except the anonymous, published patterns of the shared memory, and only with consent.
What the agent can do
- It works only on loopback/ branches. With Managed and the runner it holds no push credential: the push happens afterwards, only to that branch, with a short-lived token. In MCP mode your agent pushes with your own git credentials, and Loopback opens pull requests only from loopback/ branches.
- Merges, tags and releases need a person’s approval of the exact commit SHA, recorded in the audit log.
- Tickets, logs, issues and widget reports are untrusted data: instructions inside them are never followed, and the agent’s tools are limited.
- A fix that fails verification or tests never becomes a pull request.
Privacy of your users
- The widget masks passwords, emails, card fields and marked elements in the browser, before anything is sent.
- Screenshots only after the user confirms them, technical details only with their consent, passive error collection only after your app grants consent.
- User ids leave the browser only as a salted hash.
What is kept, and for how long
| Data | Kept |
|---|---|
| Error events | 30 days |
| Screenshots and technical details of widget reports | 30 days after the ticket is closed |
| User emails shared through the widget for fix notices | 30 days after they were last shared; longer only while an open ticket still has to notify the user |
| Prompts and outputs of jobs, already masked | 30 days by default, configurable |
| Clones of your repository | Deleted at the end of each job |
| Code index (Managed) | Until disconnection, or 30 days unused |
No training on your code
Your code is not used to train models. Loopback uses the zero-retention options of the model providers where they exist.
Audit log
Approvals, merges, tags, emails sent, configuration changes, consent changes and access to secrets are recorded with who did it and when.
Contracts
The data processing agreement lists the real sub-processors. On Enterprise the whole platform runs in your network.
Report a vulnerability
Write to security@loopback.dev with the steps to reproduce. Give us time to fix it before you disclose it; we credit researchers who ask to be credited.
security@loopback.dev