Trust
How inline handles your code
What inline reads, what it keeps, who else processes it, and the controls around all of it. Written from how the platform actually works, and updated in the same change as the code it describes.
Last updated 2026-10-29
Security practices
The controls every workspace gets, on every plan. Access is decided per module and per repository, and the record of who did what is never edited.
Single sign-on and invite-only accounts
Sign in with Microsoft Entra ID, or with an emailed link and 6-digit code. A new account needs an approved company domain or a single-use invite code, and disposable email domains are refused.
Permissions per module and per repository
Every API route declares the permission it requires, and a test fails if any route is missing a guard. Roles can be granted on chosen repositories instead of the whole workspace.
Agents never exceed their owner
An API key used by a coding agent holds its own scopes intersected with its owner's permissions, re-checked on every call and every repository.
Private means private
Members can mark their own conversations, traces and plans private. Administrators cannot read past that; only a workspace Owner can, and every such read is audited.
Encrypted credentials
Integration credentials are stored encrypted with AES-256-GCM. Database credentials are read from Azure Key Vault when the service starts.
Verified webhooks
Every webhook is verified before anything is queued. GitHub, Slack and Stripe deliveries are checked against their HMAC signatures, GitLab deliveries against a secret token unique to each repository, compared in constant time, Linear and Jira deliveries against their HMAC signatures (Jira's with a secret unique to each connection) and refused once outside a short time window, and automation webhooks against a signature made with a secret unique to each automation, refused when more than five minutes old.
A permanent security record
Sign-ins, sign-in failures and refused requests are written as security events that are never updated or deleted. Sessions and daily credential use are recorded alongside them and kept indefinitely. Administrative changes are written to an audit log.
Isolated sandboxes
Test runs and remediation work clone the repository into a fresh, isolated sandbox that is deleted when the job finishes, so nothing one run leaves behind can reach the next. Code-graph builds, which only read already-merged code of the default branch and never run it, keep one sandbox per repository: it stops after 15 idle minutes and keeps its clone on disk, so the next build can update it instead of starting over.
Releases that cannot take production down
Each release starts in a staging slot and must pass a health check before it is swapped in. A release that fails never reaches users, and rolling back is a swap.
Data handling
inline reads your code to review it and keeps the conclusions, not the codebase. Here is exactly where the line sits.
What inline reads
Pull request diffs and the repository files a review needs, through the GitHub API at the commit under review. Dependency manifests and lockfiles for security monitoring. For reachability analysis and the AI bill of materials, an archive of the default branch that is read in memory and discarded when the job ends.
What inline stores
Review findings, comments and walkthroughs, including the diff a walkthrough explains. Security alerts with their evidence: file paths, line numbers and short excerpts. Dependency names and versions. Code-graph indexes of symbols and their call and import relationships. A per-repository profile distilled from past reviews. A record of every AI run: prompts, model output and tool calls.
What inline does not store
Copies of your repositories in inline's own database or file storage. The archive read for reachability and the AI bill of materials is held in memory only. Test and remediation sandboxes are deleted when their job finishes; the one exception to keeping no clone is the code-graph sandbox described above, which holds the default branch between builds.
Secrets in the record
Credentials that appear in prompts, tool calls or output are redacted before the AI run record is written. MCP configurations in the AI bill of materials keep environment variable and header names, never their values, and credentials passed in the server command, its arguments or connection URLs (including keys carried in the URL path) are redacted.
Retention
The AI run record and the security audit trail are kept indefinitely, so any past decision can be explained. Runtime error history follows the retention window set for the workspace.
Model training
inline does not train models on your code or data. Model requests go through each provider's commercial API and are governed by that provider's API terms, linked below.
Subprocessors
The services that process workspace data on inline's behalf, what each one does, and what it receives.
Model providers and retention
Inside inline, prompts and model output are part of the AI run record: kept indefinitely, with secrets redacted at write, and oversized payloads moved to blob storage rather than cut.
Questions, reviews and reports
Security questionnaires, data-processing questions and vulnerability reports all go through one form, and a person reads every one.
Contact us about security