# Security & trust

# Security & trust

inline reads your source code and acts on your repositories, so how it handles access and data matters. This page lays out the guarantees plainly.

## Access is least-privilege

- inline's GitHub access comes only from the [connection you grant](./connect-github.html) — the GitHub App scoped to the repos you choose, or an admin's OAuth. It requests only the permissions its features use, and you can see and revoke that access from GitHub at any time.
- Cloud monitoring uses **read-only** roles (Monitoring Reader + Security Reader) and authenticates against your own tenant, so inline holds **no long-lived credential to your cloud** — see [cloud monitoring](./cloud.html).
- Linking a personal GitHub account is an **identity** link only; it never grants repository access.

## Your data stays in your tenancy

The database and artifact storage live in your own cloud tenancy. Reviews, findings, code-graph indexes, sandbox evidence, and uploaded compliance documents are stored there, in access-controlled storage. Secrets you provide (test credentials, integration webhooks) are encrypted at rest and never shown back in full.

## Code runs in isolation

Anything that executes your code — [sandbox tests](./sandbox.html), [code-graph](./codegraph.html) builds, [fix](./auto-fix.html) verification, and [pentest](./pentest.html) validation — runs in an **ephemeral, isolated microVM**, not on shared infrastructure. Each run is cloned fresh and torn down after.

## Offensive tooling is fenced in code

The [pentest](./pentest.html) module attacks your own code, so its safety is enforced by the runtime, not by a prompt. The validation agent's shell is screened against a denylist that blocks destructive and exfiltration operations before they can run — recursive deletes, disk wipes, reverse shells, piping the internet into a shell, pushing to remotes, and more. There is no network-egress tooling. Proofs must be non-destructive.

## AI proposes, humans decide

inline is built so a model never has unilateral authority over your repositories or your policy:

- **Findings are suggestions.** You accept, dismiss, or ignore each one; nothing is forced.
- **Fixes are pull requests.** Auto-fix and remediation open a separate PR you review and merge — inline never commits into your branch, and it verifies its own patch before offering it.
- **Suppression rules need approval.** When the [feedback loop](./feedback-loop.html) notices a pattern you keep rejecting, it *proposes* a rule and waits — inline never silences a class of finding on its own.
- **Findings are never silently dropped.** Anything suppressed is stored with a reason and visible in the portal, so you can audit what inline chose not to say.

## Signal over noise

Every monitor confirms before it alerts — a raw "you depend on a package with a CVE" is validated by an agent that reads your code first. This isn't only a quality choice; it's a trust one. A tool that cries wolf gets muted, and a muted security tool protects nothing.