What you send us
Depending on the scan type, you send Sentinelleai a git repository URL, an uploaded archive, a deployed contract address, or a web/DNS hostname you have proven you control. An uploaded archive is written to a temporary location, validated against path-traversal and size limits, and extracted only after that validation passes — see How a scan works for the extraction guards.
What we keep
A completed scan's findings are kept: severity, the affected file and line (where applicable), the tool that raised it, and its reasoning or message text. The scan's summary counts and score (when the scan was not degraded) are kept alongside it.
What we delete, and when
The source itself is not part of what is kept. A cloned repository or an extracted upload lives in a temporary directory only for the duration of the scan that reads it, and is removed once that scan ends — success or failure alike, since the cleanup runs unconditionally rather than only on the success path.
Who can see it
Every scan, report, and finding is owned by the individual account that created it. With authentication enforced on an installation, an ordinary member sees only their own rows, an administrator sees every row on that installation, and a request with no valid session sees nothing. This rule is enforced from one shared place rather than re-implemented per page or per API route, specifically so a list view and a by-id view of the same data cannot drift apart and leak one tenant's report to another. See Accounts & access for the full rule, including how an organisation's shared billing differs from shared visibility.
Where it runs
Sentinelleai's hosted service runs in the United States. For real incidents, an on-demand forensic analyst is available: small cases run on an always-on CPU server in the US; a mid-sized or larger incident bursts to a GPU rented in the EU for the duration. No hyperscaler and no Chinese-origin model sits anywhere in that forensic path. Retention for that material is short, and it is deleted afterward.
Secrets you give us
Alert channels can require credentials — an SMTP password, a webhook URL that embeds a live bot token. These are sealed at rest and are never returned to you in the clear: reloading your alert settings shows a placeholder in place of the password, and a webhook URL comes back redacted (masked, with only its non-sensitive shape visible). Saving the form again without touching those fields sends the placeholders back rather than overwriting a working credential with a mask — a failure mode this platform has specifically guarded against, since a naive round-trip once overwrote a working key with its own placeholder string.
The evidence ledger
A separate, append-only activity record — the evidence ledger — chains each entry to the one before it by hash, so the sequence itself can be checked for internal consistency: an entry cannot be quietly altered or removed without breaking the chain that follows it. The ledger's own head is anchored externally on a recurring basis so its state at a point in time can be shown to predate any later dispute.
Security of the platform itself
Every response the application returns — HTML pages and API responses alike — carries a set of security headers: a strict Content Security Policy scoped to the platform's own origin, with a fresh nonce minted per request for the two inline scripts the app needs, X-Frame-Options: DENY, and a locked-down Permissions Policy disabling camera, microphone, geolocation, and payment API access by default. Session cookies are HttpOnly (unreadable to page script), SameSite=Lax, and marked Secure on every connection except plain-HTTP localhost. A session token itself is never stored — only its cryptographic digest — so reading the database does not hand over a usable session. See Lockdown & inline protection for how the platform responds if it is itself compromised.