Lab 01: Continuous risk identification

This lab is for GRC practitioners, security engineers and risk professionals who want to understand how system evidence can support risk identification.

The aim is to connect observations to a business objective and express a candidate scenario that someone can inspect and challenge. It is not to produce a risk score, declare an incident or choose a treatment.

Start with the published lab

Open Lab 01 on GitHub.

Use the repository’s current setup instructions for prerequisites, local configuration and Jupyter execution. Keep API keys outside notebooks and version control. Live model calls may incur provider charges.

The published lab demonstrates a bounded workflow around a known use case. It should not be described as validated discovery of unknown enterprise risks.

What the discovery extension adds

A newer local experiment proposes candidate scenarios without predefined scenario rules. It is not yet part of the published GitHub lab.

Its flow is:

Source records
  -> validate and preserve provenance
  -> group evidence by business service and time window
  -> add the service objective
  -> propose candidate scenarios with an LLM
  -> challenge each proposal
  -> check citations and retain questions for human review

The prototype starts with structured, explicitly mapped mock records. It is not a high-volume production collector.

Inspect an example

Service: Customer release signing.

Objective: Customers receive software authorized by the release owner.

Record T1, from the mock build configuration:

1
{
2
  "external_pull_requests_execute": true,
3
  "worker": "signer"
4
}

Record T2, from the mock secret inventory:

1
{
2
  "available_to": "every job on signer",
3
  "credential": "production-signing-key",
4
  "key_status": "active",
5
  "worker": "signer"
6
}

Candidate risk statement

The following statement is copied from the saved discovery run using gpt-5.4-2026-03-05:

If jobs triggered by external pull requests run on the “signer” worker and that worker makes the active “production-signing-key” available to every job, then untrusted pull-request code could potentially use the signing key to authorize software that was not approved by the release owner. The business consequence could be that customers receive software that appears validly signed but is not actually authorized by the release owner.

What could change the conclusion?

Jobs may be isolated from the signing key. Signing may require an independent approval. External contributors may be restricted to trusted parties. Those possibilities need evidence.

The model’s second pass retained the candidate. That is a model disposition, not independent validation of the risk.

What has and has not been demonstrated

The experiment generated and challenged scenarios on authored mock examples, with source citations. This supports demonstrating the method in a lab.

It does not establish reliable discovery in a real company. Independent test cases, realistic ingestion, stable tracking across windows and practitioner review are still needed.

Questions to work through

1. Which facts establish the condition, and which parts of the statement are assumptions?
2. What evidence would show that a signing approval gate prevents the proposed event?
3. How should the candidate change when a later observation contradicts the original condition?
4. What would make the evidence insufficient to retain any candidate?

The useful output is not just a sentence. It is a sentence whose reasoning, evidence and limits remain inspectable.