Security practices

Last updated: August 2026

Libra runs your code and reads your production systems, so the useful version of this page is specific rather than reassuring. What follows is what Libra can reach, what it stores, for how long, and who else is involved.

If your review needs something that is not here, email security@exla.ai and a person who works on the system will answer it.

Hosting and architecture

Cloud service

Libra's cloud service runs on established cloud infrastructure providers, on encrypted storage, in US regions. The web application, the API, and the sandbox fleet are separate systems with separate credentials, so a compromise of one surface does not hand over the others.

Sandbox isolation

Every pull request run happens inside its own ephemeral, isolated sandbox that is created for the run and destroyed when it finishes. Nothing carries over between runs, and nothing about one customer's run is reachable from another's. Sandboxes report results over authenticated, signed callbacks, so a run's results cannot be forged by anything that merely knows the endpoint.

Access to your systems

Repository access goes through the Libra app on your source-control provider, using short-lived installation tokens scoped to the repositories you choose; revoking the installation revokes access immediately. Cloud-account access, where you enable it, is through a read-only role you create in your own account, gated on an identifier unique to you, with short-lived sessions. There is no write path into your infrastructure, and sandbox environment discovery is scoped to staging resources so production secrets stay out of reach.

Self-hosted deployment

Enterprise customers can run Libra inside their own cloud environment. In that shape, source code, telemetry, secrets, and sandbox runs never leave your environment, and inference can point at your own model endpoint or a self-hosted model. Tell us the constraints you are working under and we will scope the deployment with you.

Model inference

Libra uses established AI model providers for inference, choosing per task rather than committing to a single vendor. What is sent is the material needed for the task at hand: a diff, a trace, a log excerpt. Enterprise customers can pin inference to a single provider, supply their own keys and endpoint so requests never touch ours, or self-host models entirely.

Storage of customer code

Your source code is cloned into the sandbox for the duration of a run and destroyed with it. Libra does not maintain a long-lived copy or index of your repository. What persists is the record of the run: which commit was tested, which checks executed, and what they returned. Revoking the app installation ends all code access immediately.

Storage of customer data

Logs, traces, and the error fixtures used for replay are held on encrypted storage in Libra's infrastructure and pruned on a short rolling window by default. Sandbox run records and replay attempts are kept for thirty days, which is what makes repeat-pull-request analysis possible. Secrets you provide for sandbox runs are encrypted at rest, decrypted only at dispatch, passed into the sandbox for that run only, and never persisted outside it.

Data usage and AI training

Your code and telemetry are not used to train models. There is no training program to opt out of. Libra's own quality work runs on Libra's own systems, which we watch with the same product. In self-hosted deployments, no customer data is collected by us at all.

Confidentiality and security controls

Access to systems holding customer data is limited to the engineers who need it to operate the service. Operating Libra sometimes requires access to a customer's account, for example to diagnose a problem you have reported; that access is used for support and operations, not for reading customer data, and everyone here is bound by confidentiality obligations. Credentials to customer systems are short-lived by construction, so standing access does not accumulate.

Return and deletion of customer data

You can revoke Libra's access at any time by removing the app installation and deleting the cloud role, which stops all collection immediately. Telemetry ages out on its rolling window and run records after thirty days. To have retained records deleted rather than aged out, email security@exla.ai and we will delete them from production systems and confirm when it is done.

Monitoring and validation

Security assessment

The service undergoes internal security review as part of normal engineering work, and every change to the sandbox and its customer-facing claims goes through automated verification before it ships. Reports of vulnerabilities are handled directly by the engineers who work on the affected system.

Reporting a vulnerability

Email security@exla.ai with enough detail to reproduce the issue. We will acknowledge it and keep you updated until it is closed. Please do not test against another customer's data or a system you do not control.

Personnel

Everyone with access to customer data is bound by confidentiality obligations, and access follows least privilege: the systems that hold customer data are reachable only by the engineers who operate them.