How AutoCISO Works

This page explains, at the level an integrator or a security reviewer needs, how data moves through AutoCISO and how each request is checked. It does not describe internal infrastructure.

From raw lists to findings

Everything starts from two inputs: your employee list (who works here) and the user lists of your applications (who has an account where). AutoCISO matches every account to an employee and builds the access inventory; every report, finding and piece of access evidence is derived from that inventory.

Inputs are matched into the access inventory; everything else is derived from it.

Matching treats an exact email address as decisive. When only a name is available and it fits several employees, the row is held for review instead of being guessed — see Correct an employee match. Screenshots and PDFs are read with AI; which provider sees what is described in AI providers.

How an API request is checked

Every request made with an API token passes the same checks before any data is read. The organisation always comes from the token itself, never from the request.

The checks an API-token request passes, in order.

The order of the scope and plan checks differs by surface; the Access model has the details.

What happens to an SBOM upload

An upload (POST /sscs/sboms/upload) is parsed and stored in the request; vulnerability matching runs afterwards, so the response returns quickly and findings appear a little later in Vulnerability Findings. To wire this into a pipeline, see Upload an SBOM from CI.

An SBOM upload: synchronous parsing, background matching.

Tenant isolation

Each organisation’s data is isolated from every other organisation’s. Every record belongs to exactly one organisation, and every request — from the console, the REST API or MCP — is scoped to the organisation bound to its verified credentials:

  • The console takes the organisation from your signed-in session and membership.
  • An API token is bound to the organisation that created it. No endpoint or MCP tool accepts an organisation identifier, so a token cannot be pointed at another tenant.
  • A person who belongs to several organisations switches between them explicitly; their role can differ in each.

Evidence over time

Evidence for an ISO 27001 control is kept as a history in the Evidence Vault. The newest item for a control is the current one; older items stay as history, and anything older than the freshness window is flagged as stale so it can be refreshed before an audit.

Evidence for one control: the newest item is current, older items become history.

See Upload evidence for a control for how this looks in the console.

Last reviewed: 2026-10-09

Was this page helpful?

Esc