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.
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.