SaibleDocs
Inventory

Your AI inventory, from what you already run

Found on your platforms, in your code and at the gateway (the browser extension is coming); claimed by its owner, who adds the purpose and the risk class.

ConnectGitHub org · GitLab groupplatforms · gateway · browser (coming)Readevery repository, nightlyfixed patterns, no modelCandidatesone per deployable unit,key, caller, endpoint, roleClaimpurpose · risk classtyped by the ownerAinto a new or an existing systemAttestthe owner, every 90 daysa ledger record↺ read again every night, only what moved;Scan now at once;unclaimed 14 days: flagged to admins
From what you run to a system with an owner · nothing typed until the claim
  • GitHub organisation
    every repository, archived included and flagged, none skipped; one system per deployable unit
  • GitLab group
    every project of the group and its subgroups, by group token; GitLab.com and self-managed
  • Self-hosted hosts
    GitHub Enterprise Server, GitLab self-managed: a collector you run reads them and pushes the findings
  • OpenAI
    each API key, in its project
  • Anthropic
    each workspace or service-account key
  • Azure OpenAI
    each model deployment
  • Amazon Bedrock
    each caller: an IAM role seen in CloudTrail
  • Databricks
    each serving endpoint
  • Snowflake
    each role calling Cortex
  • A repository you scan
    one per application, on the Policy tab: the AI SDKs and models it imports
  • The gateway
    each application registered with a Saible key
  • The browser extension
    AI services people use, by team: Catalog › People
  • roadmap
    Azure DevOps · Bitbucket
    after GitHub and GitLab
  • roadmap
    One system across platforms
    a repository matched to its keys, roles and images
Where a system is found · tick: fills the catalog · roadmap: not built

Each repository is read as one archive of its head commit, in memory, and discarded; the next scan re-reads only repositories whose head moved. With the collector the archive is read on your own network and only the findings below are sent. The per-application scan on Policy → From your code is separate: it keeps the trimmed line a finding sits on, and the inventory takes only the SDK and model names from it.

  • Read, by fixed patterns
    • Dependency manifests naming an AI SDK or agent framework; imports in code
    • Environment variable names: OPENAI_API_KEY, ANTHROPIC_API_KEY, AZURE_OPENAI_*, BEDROCK_*
    • Model id strings; prompt files and system prompts; .mcp.json and tool schemas; AGENTS.md, CLAUDE.md, .cursorrules
    • Terraform and CloudFormation for Bedrock agents, Azure OpenAI deployments and Vertex endpoints; CODEOWNERS
    • One archive per repository whose default branch moved, read in memory; no model reads your code
  • Kept by Saible
    • Repository names, the head commit, each unit's folder, and the file and line a signal sits on with the matched name only
    • SDK, framework and model names; environment variable names; counts of prompts, tools and MCP servers
    • A CODEOWNERS team, shown in the claim drawer as a suggestion; a person named there is only flagged
    • A confidence of high, medium or low, computed from the kinds of signal found
  • Never
    • Source code or prompt text stored, or sent to a model; prompts are counted; a line's text beyond the matched name
    • An environment variable's value, or your code host's token in a finding
    • A person's name or e-mail on a candidate: workloads, never people
    • A repository skipped because it looks stale; a connection Saible opens into your network
The organisation-wide scan · what is read, what Saible keeps, what it never does
  • Metadata: readthe list of repositories, their default branch and whether each is archived
  • Contents: readone archive of the head commit per repository whose branch moved, read in memory
  • All repositoriesthe installation covers the organisation; nothing is picked by hand and nothing skipped
  • App ID · installation ID · private keytyped once at Connect; the key goes to the per-tenant secret store and an installation token is minted per scan
  • Your own GitHub App on the organisation, or Saible's when your instance offers the install link. The push and repository events are not read yet: a change is picked up by the nightly scan or Scan now; webhooks are on the roadmap.
The fallback: a fine-grained organisation tokenContents: read and Metadata: read on all repositories. It belongs to the person who made it and stops with their account, so the code hosts card shows it as Person-bound. A GitLab group token needs read_api and read_repository.No write permission is asked for. Nothing is pushed to a repository. Test lists the repository count and nothing else.
The GitHub App on your organisation · what it asks for and why
  • FirstA collector you run
    • A distroless image: non-root, no shell, no inbound port, outbound only to your code host and to your Saible instance
    • Connect the host in Saible as “Our collector reads it”, then issue a collector key: sdc.<org>.<secret>, shown once; Saible keeps its SHA-256
    • Runs as a cron job or a Kubernetes CronJob; asks Saible which commits it already holds, reads only what moved, pushes the findings
    • The same scanner as Saible's own, so the push gives the same systems as a pull; up to 200 repositories per push
    • Every pushed value is checked on arrival for its shape: a name, a path, a line number, a team slug; anything else is refused
    Saible never opens a connection into your network, and holds no credential for the host. Revoke the key from the console; disconnecting the host revokes it. The image is built from the repository and comes with your onboarding (docs/Collector-Install.md); a signed, published image is on the roadmap.
  • SecondPrivate connectivity, if you prefer to run nothingroadmap
    • AWS PrivateLink: your endpoint service, Saible's interface endpoint in the region of your instance
    • Then an allow-listed fixed egress address, as the gateway's control-plane calls use today
    • Then VPC peering, for a Dedicated Saible instance only
    Design and documentation only (docs/Discovery-Private-Connectivity.md); the Terraform for it is on the roadmap.
Self-hosted code hosts · Saible never opens a connection into your network
  • SplitA unit that is really several services: name the folders and why. Each folder becomes a system of its own; a folder with no signal is refused. The record says whether the parent was kept or replaced.
  • MergeSeveral units that are one product: pick the rows, name it and say why. One system to claim; a reconnect keeps the merge.
  • Not AIAn org admin sets a row aside with why: a test fixture, nothing deployed calls a model. It is not listed again.
  • ConfidenceHigh: an SDK, import or infrastructure declaration plus another kind of signal. Medium: one strong signal, or a supporting one. Low: a prompt file or README mention alone. Coding-assistant files alone never make a system.
Correcting what was found · each an override the next scan keeps, and a ledger record
  • PurposeWhat the system is for, in a sentence. Required to claim; never pre-filled.
  • AI Act risk class and its reasonProhibited, high, limited or minimal, with the reason in a sentence; or decide later. The owner declares it; Saible never does.
  • Owner and teamThe CODEOWNERS team is a suggestion in the claim drawer; the person confirms it. Data classes and autonomy are declared by the owner, or taken from the data map where your platforms' tags say so.
  • ApprovalsA claim into an existing system by its owner or an org admin; a policy change by a second person; an attestation by the owner, every 90 days.
What stays with a person · Saible proposes; it never decides a purpose or a risk class

Home and the catalog count the systems found with no owner, in code and on the platforms, with where each was found and how long it has waited; after 14 days a system is flagged to the org admins.

The AI Act inventory lists each discovered, unclaimed system as such, with where it was found and the date first seen, and no owner, purpose or tier until a person claims it. The AI landscape report counts them, apart from the names seen in use with no registration. No owner suggestion appears on a report. A row count is a list of what was found, never a register on its own.

See chains, checks and the evidence pack for what the reports hold, and control coverage for where Know and Own come from.

On the reports
Do it
  1. 1Open Catalog → Systems → Discovered from code → Connect GitHub: your GitHub organisation through a GitHub App or a fine-grained token, or a GitLab group through a group token. For a self-hosted host choose Our collector reads it, then Collector key and run the collector where it can reach the host.
  2. 2Connect your AI platforms under Settings → Providers. The first scan runs tonight, or press Scan now; Test counts the repositories and reads nothing else.
  3. 3Open Discovered from code: each service that calls a model, with its repository and folder, how sure Saible is and what was found. Home and the catalog's figures count what has no owner, in code and on the platforms.
  4. 4Open a row: where each signal was found, file and line, and the CODEOWNERS team as a suggestion. Press Claim it and type the purpose and the risk class; or Split it by folder, pick rows to Merge, or mark it Not AI, each with why.
  5. 5Press Attest as owner on the system's Access tab, and again every 90 days. Mark what is not yours Not ours.
For your agents

This topic is also written as Agent Skills your agents can load: discovery, catalog, code-scan, exposure-report, human-ai-use. Ask us for them.

Next · Control Plane · SpendSpend feeds from your providers →