Skip to main content

Renamed from TrustOps. See the upgrade guide for command aliases, existing volumes and release availability. GRC Lake — collect, evaluate, resolve, and export: read-only evidence from cloud, identity, code, and data sources, evaluated through a common control framework and framework packs.

PyPI version Python 3.11+ CI status License: Apache 2.0 OpenSSF Scorecard

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, linked through 94 common safeguards. 1,415 requirements have safeguard mappings; 340 have reviewed mappings and the other 1,075 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

Quick start

With Docker Compose v2:

git clone https://github.com/msaad00/grc-lake.git
cd grc-lake
docker compose up

Open localhost:8787/console/dashboard/. The demo binds to loopback and has authentication disabled. Follow the 5-minute tutorial to connect a source and export results.

Install with pip, run from source, or connect an agent

Python 3.11+:

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 --port 8787

From source, with uv and Node 22+:

uv sync --frozen --extra dev --extra server
make demo-local

For MCP over stdio:

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

Read headless GRC for agent credentials and authority.

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

GRC Lake overview with framework coverage, priority actions, and evidence freshness

Screens show the bundled synthetic company. They demonstrate workflows, not a customer deployment or an audit opinion.

Architecture

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/>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 -. local lake .-> CLI
  Generations -. local lake .-> 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. The CLI works on a local lake; the MCP server reads a local lake or calls the authenticated API. See architecture.

Evidence modes

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

Mode Start with How it works
Existing lake Logs, security events, and evidence already ingested into your lake or warehouse. Read-only readers query existing tables; lake mappings translate their fields into evidence. Snowflake, ClickHouse, Databricks, BigQuery, and Iceberg/Parquet readers include OCSF presets for Amazon Security Lake. S3 evidence and SIEM exports are also supported sources.
Ingest Cloud, identity, code, endpoint, and SaaS systems; no existing lake required. Read-only connectors collect evidence into storage you own. Sources include AWS, Azure, GCP, GitHub, GitLab, Okta, Google Workspace, Jira, Intune, and HR systems.

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. Existing-lake readers preserve the source system and materialize assessment evidence into the GRC Lake lake; they do not move the GRC Lake application into your warehouse.

Product tour

Workflow What you get
Collect Source evidence with identity, timestamps, hashes, and collection status.
Evaluate Deterministic results pinned to a catalog and evidence generation.
Resolve Assigned findings, follow-up verification, and independently reviewed decisions.
Export Snapshots, workpapers, OSCAL, and scoped, revocable auditor shares.

Know what is covered

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

Framework roster showing evidence coverage and assessment results

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.

Evidence workspace with freshness and source lineage
More screens: remediation, audit room, and mobile

Remediation workspace Auditor workpapers and exports GRC Lake overview on a narrow screen

Self-host

Use Docker or Helm, configure SSO and scoped credentials, and choose the storage and writer topology. Evidence stays in storage you operate; data leaves through the connectors, sinks, and model integrations you configure.

  • JSONL is the local evidence authority. Warehouse paths 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.0 -R msaad00/grc-lake -p '*.whl'
gh attestation verify grc_lake-0.3.0-py3-none-any.whl -R msaad00/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.

Generated catalog coverage and control families

20 framework packs · 94 reusable safeguards · 21 control families in 10 categories · 2,252 catalogued requirements. 2 more registry entries are planned or superseded and hold no requirements.

1,415 requirements have safeguard mappings; 340 have reviewed mappings. Catalog coverage and evaluated customer posture are separate measures.

Control families by category:

  • Governance and risk: Risk management · Governance
  • Identity and access: Identity and access
  • Data protection and privacy: Data protection · Privacy
  • Secure engineering: Change management · Secure development · Secure architecture
  • Infrastructure security: Configuration management · Vulnerability management · Network security
  • Detection and response: Detection · Audit logging · Incident response
  • Resilience and integrity: Availability and recovery · System maintenance · Processing integrity
  • Third-party and supply chain: Third-party risk
  • People and physical: People security · Physical security
  • AI governance: AI governance

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.

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

Need Start here
Try a complete workflow 5-minute tutorial
Understand the design Architecture · All docs
Deploy and authenticate Deployment · Server auth
Understand storage and retention Data flow · Operations
Integrate an agent Headless GRC · Agent skills
Evaluate audit evidence Audit readiness · Evidence recovery
Contribute Contributing · Security · Trust boundaries

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 documentation images from the running synthetic demo with npm --prefix app/web run demo-screenshots. License: Apache 2.0.

Metadata

Release files for grc-lake 0.3.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for grc-lake 0.3.0
File Size Uploaded
grc_lake-0.3.0.tar.gz 3.3 MB Details

Built distribution (wheel)

Table of built distributions (wheels) for grc-lake 0.3.0
File Interpreter ABI Platform
grc_lake-0.3.0-py3-none-any.whl Python 3 none any Details

Total release size: 6.5 MB

Release files / grc_lake-0.3.0.tar.gz

Download URL grc_lake-0.3.0.tar.gz
Size 3.3 MB
Tags Source
SHA-256 checksum
How to use checksums
ab449d9704df47009f32053d18a065a2c513b5e8775b3ede6307bd7991de0c4c
BLAKE2b-256 checksum
How to use checksums
3c57469d24da5dec06f893a1a0f9a815d6c3c400e95621faea75226b15527560
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 9, 2026.

Transparency log

Release files / grc_lake-0.3.0-py3-none-any.whl

Download URL grc_lake-0.3.0-py3-none-any.whl
Size 3.2 MB
Tags Python 3
SHA-256 checksum
How to use checksums
1cceb79cef8bb2e359f5bffdd3c80ebe425286bee4251698b348beaa66538b8c
BLAKE2b-256 checksum
How to use checksums
e66d023bb017a8dc2b0b2cb04ca2ba1a77129f05eb73264497a365f4f004629c
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 9, 2026.

Transparency log

Release history Release notifications | RSS feed

0.3.4

2 release files

0.3.3

2 release files

0.3.2

2 release files

0.3.1

2 release files

This release

0.3.0 This release

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page