grc-lake 0.3.3

Open-source trust operations, on your evidence lake. Self-hosted GRC engineering: collect read-only evidence from cloud, identity, code, and existing security lakes; evaluate it with deterministic, version-pinned control tests; export snapshots, workpapers, and OSCAL.

• 20 framework packs, 2,252 catalogued requirements (1,965 distinct; FedRAMP Moderate's 287 rows restate NIST SP 800-53 controls), linked through 96 common safeguards. 1,417 requirements have safeguard mappings; 339 have reviewed mappings and the other 1,078 are proposed.
• 25 read-only source adapters (7 in preview), plus OCSF presets for existing security lakes.
• Fails closed: missing, stale, or partial evidence never produces a pass, and proposed mappings are not attestable.
• One engine, four surfaces: console, REST API, CLI, and MCP server. Agents propose; humans approve.

Quick start · Architecture · Evidence modes · Product tour · Self-host · Frameworks · Documentation · Current coverage · Roadmap

Quick start

Python 3.11+ on macOS or Linux:

python -m venv .venv
source .venv/bin/activate
pip install "grc-lake[server]"
grc-lake fixtures load --company golden --out ./lake --rebase-times
grc-lake assessment status --lake ./lake
grc-lake serve --server --allow-insecure-no-auth --lake ./lake --host 127.0.0.1 --port 8787

Open localhost:8787/console/dashboard/. This local demo uses synthetic data and disables authentication. Use the production setup before connecting real evidence. Follow the 5-minute tutorial for the workflow.

git clone --branch v0.3.2 --depth 1 https://github.com/koda-ai-studio/grc-lake.git
cd grc-lake
docker compose up

git clone https://github.com/koda-ai-studio/grc-lake.git
cd grc-lake
uv sync --frozen --extra dev --extra server
make demo-local

pip install 'grc-lake[mcp]'
GRC_LAKE_LAKE=./lake grc-lake-mcp

Renamed from TrustOps. See the upgrade guide for command aliases, existing volumes and release availability.

The PyPI package is grc-lake, the CLI is grc-lake, and the MCP server is grc-lake-mcp.

Screens show the bundled synthetic company, captured from 0.3.3 candidate source 9e741ffb on 2026-10-12, with evidence investigation, the AI model and agent worklist, and shared framework/control identities. Main can include changes newer than the published package. These screens demonstrate workflows, not a customer deployment or an audit opinion.

Architecture

Deploy GRC Lake on your own infrastructure or in the cloud, using a VM, containers, or Kubernetes. Hosting location, application storage, and evidence sources are separate choices:

• Application storage: filesystem mode uses one writable replica; distributed mode uses PostgreSQL and S3-compatible object storage with multiple API replicas and workers. Both can run on-premises or in the cloud.
• Evidence sources: collect directly from supported systems or read existing self-managed and cloud lakes through supported connectors and mappings.

flowchart LR
  Sources["Sources<br/>cloud · identity · code · existing lakes"]
  Collect["Collect<br/>read-only · normalize · hash"]
  Evaluate["Evaluate<br/>deterministic, version-pinned control tests"]
  Generations["Assessment generations<br/>filesystem or PostgreSQL + S3<br/>hash-verified, published atomically"]
  Snapshots["Snapshots<br/>hash-chained ledger"]
  API["REST API"]
  Console["Console"]
  MCP["MCP server"]
  CLI["CLI"]
  Sources --> Collect --> Evaluate --> Generations --> Snapshots
  Generations --> API
  API --> Console
  API --> MCP
  Generations -. filesystem mode .-> CLI
  Generations -. filesystem mode .-> MCP

Connectors only read from source systems. Deterministic rules own every result; agents can propose changes but do not decide them. Each run publishes a new generation whose artifact hashes are verified before it becomes current, and each snapshot records its predecessor's hash. CLI assessment commands use a filesystem lake; cluster commands manage distributed operation. MCP reads a filesystem lake or calls the authenticated API; distributed deployments require API mode. See architecture and distributed deployment.

Queued evaluations and snapshots retain tenant-scoped result receipts, allowing an authorized caller to inspect a committed result after a lost worker response. Operation lists support cursor pagination; queue admission, response storage and collector retries have explicit limits. See the assessment application contract for failure codes, retry guidance and the limits of local recovery.

Distributed operators can inspect committed objects without trusting replica caches and follow the backup and restore runbook. The built-image qualification restores PostgreSQL and S3 objects into fresh stores and checks evidence, snapshot chains, operation receipts and tenant isolation. This synthetic single-host drill does not establish production recovery times or storage failover.

Evidence modes

Both modes feed the same evaluation engine, assessments, and review workflows.

Already have a lake? Start with bring your own lake. Collecting new evidence? Start with connector setup. Lake mappings are experimental; preview and live-provider qualification vary by reader. See the connector catalog for status. Compatibility depends on the supported reader, schema mapping, and access configuration; arbitrary lake backends are not automatically supported. Existing-lake readers preserve the source system and materialize assessment evidence into GRC Lake's configured application storage. A source warehouse does not replace that storage.

Product tour

The console groups navigation by workflow, with category icons and a top-mounted collapse control. The compact rail opens each category's pages on demand and remembers your preference. Findings and framework drawers resize and separate assessment, evidence, triage, and history into focused views. Lists use pagination; source operations have a focused dashboard view with clickable provider marks and source-specific evidence links. A compact vendor review summary leads to the dedicated Vendor risk workspace. Audit room leads with observed gaps and next actions; Trust center separates scoped sharing from active-link management. Framework identities, control-family icons, and provider marks appear inside the console as well as in this tour. The graph keeps selected-node details beside large icon-led nodes. Evidence investigation connects exact records to controls, CCF safeguards, environments, repository context, findings, and explicitly linked vendor assessments. Depth and layer controls keep local neighborhoods bounded. Expand the workspace for more room, drill into a selected node, and roll up to the preceding view; mapping review stays separate from assessment.

Connector setup separates configuration, access testing, first sync, and result review. Cloud authorization separates provider preparation from target configuration. Required fields and permissions remain visible; advanced identity settings and schedules are progressively disclosed. Access reviews open on pending decisions and explain the next action without implying that recording a decision changes provider access.

Know what is covered

Framework coverage separates assessed controls, missing evidence, and unreviewed mappings. A passing sample does not establish full framework compliance.

Follow evidence to a decision

Inspect the source, freshness, and affected controls before assigning a finding. Closing a task requires fresh verification; approval actions require an eligible human session. Agents can collect, explain, and propose work.

More screens: setup, graph, AI governance, sources, access reviews, remediation, audit room, and mobile

AI governance lists recorded models and agents with owners, environments, signals, and next actions. Inspect an asset to follow its exact control links or open its filtered evidence. Observed controls and recorded lineage remain distinct from freshly evaluated controls and complete lineage.

Access reviews scope and seed campaigns from collected identity evidence. Human SSO reviewers record decisions and rationale; recording a revocation decision does not change access at the provider. Vendor assessment status describes the recorded review, not complete vendor coverage or certification.

Self-host

Use Docker or Helm, configure SSO and scoped credentials, and choose the storage and writer topology. See the deployment and lake compatibility matrix for hosting, storage, source-reader and export support. Evidence stays in storage you operate; data leaves through the connectors, sinks, and model integrations you configure.

• Local mode: one writable replica with a local JSONL lake and SQLite or PostgreSQL.
• Distributed mode: multiple API replicas and tenant workers share PostgreSQL and S3-compatible object storage, with private scratch space and fenced publication. Enable it explicitly using the distributed deployment guide. A single tenant evaluation still runs on one worker; production capacity and provider failover require deployment-specific qualification.
• Warehouse exports have separate setup and qualification requirements. See data flow.
• Authentication is required for production. The loopback demo is a separate setup. Human approval, tenant isolation, and read-only auditor access are enforced at the API boundary.
• Retain evidence deliberately. Use the operations guide for generation archival, history costs, and external integrity checkpoints.

See the connector catalog for implementation and preview status, and credential setup for each source.

Verify a release

Wheels and sdists carry SLSA build provenance, and each GitHub release attaches a CycloneDX SBOM of the locked runtime dependencies:

gh release download v0.3.2 -R koda-ai-studio/grc-lake -p '*.whl'
gh attestation verify grc_lake-0.3.2-py3-none-any.whl -R koda-ai-studio/grc-lake

Frameworks

Common safeguards connect source evidence to framework requirements. Proposed crosswalks remain review work; reviewed mappings are version-pinned and still need applicable evidence. The legacy fedramp-moderate pack represents the NIST 800-53B Moderate foundation, not a complete FedRAMP authorization package.

Framework packs · Coverage catalog · Common controls · Control families screen · Crosswalk screen

Evidence boundaries

Missing, stale, blocked, or partial evidence cannot establish a passing control. Inventory observations establish presence, not the effectiveness of a control. Exceptions and compensating measures are review records, not automatic passes. Scoped risk decisions retain evidence, expiry and independent review; extensions require a new approval. See governance.

Local fixture tests, exported hashes, and screenshots do not establish live provider qualification, production capacity, certification, or customer adoption. An independently retained checkpoint is needed to detect a complete local history replacement. See evidence recovery and audit readiness.

Documentation

Develop

uv sync --frozen --extra dev --extra server --extra mcp
uv run pytest -q
uv run pre-commit run --all-files
npm --prefix app/web ci
npm --prefix app/web run build

Regenerate the header and catalog counts with make readme-header. Rebuild the synthetic demo and recapture its light, dark, and mobile screens with make demo-screenshots-full (requires Playwright Chromium). License: Apache 2.0.