Presidio Hardened Ikigov Assess

🇬🇧 English · 🇩🇪 Deutsch

IKI-Gov Assessment Tool — operationalises the IKI-Gov-Referenzmodell (Integrated KI-Governance Reference Model) as a practical CLI tool for assessing AI use cases against a structured governance framework.

The IKI-Gov framework structures AI governance along a central lifecycle (Kontext → Konzeption → Entwicklung → Freigabe → Betrieb → Anpassung → Außerbetriebnahme) surrounded by six domains and measured across six dimensions (M1–M6) with six quality gates (G0–G5).

Reference: Stantchev, V. IKI-Gov-Referenzmodell — Integrated KI-Governance Reference Model.

The book

This tool implements the IKI-Gov reference model, introduced in the Springer monograph by Vladimir Stantchev — published in two editions:

• AI and IT Governance (English) — Springer, Berlin; ISBN 978-3-662-74001-9; forthcoming 11 January 2027
• KI und IT-Governance (German) — Springer, Berlin; ISBN 978-3-662-74093-4; forthcoming 28 December 2026

The book works from classical IT governance (COBIT, ITIL, ISO/IEC 38500) toward AI governance across ethics, law, risk, and data, then assembles IKI-Gov: the lifecycle, six domains, six measurement dimensions (M1–M6), and six quality gates (G0–G5). The 25 checklist items scored here are drawn from the book's framework chapter and its workshop/approval-gate appendix; the ISO/IEC 42001 and EU AI Act mappings follow its orientation tables.

The book presents the model as a reasoned synthesis and a working heuristic for orientation — not legal advice and not a conformity assessment. This tool holds the same line (see the disclaimers on the euaiact-gap and iso-gap commands). Both editions are now available for preorder from Springer (Berlin); the Springer catalogue page and DOI will be added here once live.

Installation

pip install presidio-hardened-ikigov-assess

# With dependency CVE checking
pip install "presidio-hardened-ikigov-assess[audit]"

# With Ed25519 public-key evidence verification
pip install "presidio-hardened-ikigov-assess[crypto]"

Quick Start

# Parameter-driven assessment
iga assess --use-case "fraud-scoring" --risk-class high --lang en \
    --affirm S1,S2,S3,D1,D2,T1,T4,O1,I1

# Interactive wizard (step-by-step)
iga assess --interactive --lang de --risk-class high --use-case "kredit-scoring"

# Gate readiness check
iga gate --gate G2 --risk-class high \
    --affirm S1,S2,S3,D1,D2,T1,T4,O1,I1 --lang en

# CI pipeline gate assertion (exit 0 OPEN / 2 PARTIAL / 3 BLOCKED)
iga gate --gate G1 --risk-class high --affirm S1,S2,D1,D2 --assert-gate G1

# Strict mode: skipped gate-critical items count as blocking
iga gate --gate G2 --risk-class high --affirm S1,S2 --skip D3 --strict --assert-gate G2

# Machine-readable JSON (scriptable, no progress bars)
iga assess --affirm S1,S2,S3 --quiet
iga gate --gate G0 --affirm S1,S2 --skip S3 --quiet

# Export report to Markdown (stdout)
iga report --use-case "fraud-scoring" --risk-class high \
    --affirm S1,S2,S3,D1,D2,T1 --format markdown

# Export report to JSON
iga report --use-case "fraud-scoring" --affirm S1,S2 --format json

# Write the report to a file (Markdown or JSON)
iga report --use-case "fraud-scoring" --affirm S1,S2,T4 --output audit/fraud-scoring.md
iga report --use-case "fraud-scoring" --affirm S1,S2 -f json -o fraud-scoring.json

# ISO/IEC 42001 clause-level coverage gap analysis
iga iso-gap --use-case "fraud-scoring" --risk-class high --affirm S1,S2,S3,I1,I2
iga iso-gap --affirm S2,S3,I1,I2 --quiet   # machine-readable JSON

# EU AI Act high-risk obligations (Art. 9–18, 72) — high-risk systems only
iga euaiact-gap --use-case "fraud-scoring" --affirm S1,S2,S3,S4,S5,D1,D5
iga euaiact-gap --affirm S1,S2 --quiet

# Persist assessments and view the portfolio (SQLite at ~/.iga/assessments.db)
iga assess --use-case "fraud-scoring" --risk-class high --affirm S1,S2,S3 --save
iga list                                   # table of saved assessments
iga portfolio                              # aggregated M1–M6 + blocked gates
iga trend --use-case "fraud-scoring"       # delta vs the previous saved run
iga delete --use-case "fraud-scoring"      # hard-delete

# List saved assessments (persistence in v0.6.0)
iga list

Example output

The worked example from the book (Anhang B, corrected proof), at a 100-column terminal:

iga assess --use-case fraud-scoring --risk-class medium --lang en \
  --affirm S1,S2,S3,S4,S5,D1,D2,D4,D5,T1,T2,T3,T4,O1,O2,O3,I1 --skip D3

IKI-Gov Assessment — fraud-scoring  [risk: MEDIUM]

Measurement Dimensions
  M1  Strategie & Ownership                ██████████  100.0 %
  M2  Data Quality & Lineage               ██████████  100.0 %
  M3  Validation & Fairness                ██████████  100.0 %
  M4  Security & Robustness                █████░░░░░   50.0 %
  M5  Compliance Evidence                  ██░░░░░░░░   20.0 %
  M6  Operations, Drift & Incidents        ██████░░░░   60.0 %
────────────────────────────────────────────────────────────────────────────────────────────────────
       Overall maturity                     ███████░░░   71.7 %
       Evidence: 0 verified, 0 evidence-backed of 17 affirmed items; 0 asserted and not counted.

Gate Readiness
  G0  OPEN
  G1  OPEN
  G2  PARTIAL  — skipped: D3
  G3  BLOCKED  — blocking: T5 (A security review of the model…)
  G4  BLOCKED  — blocking: O4 (An incident response and change…), O5 (An audit log — capturing
model…), I2 (Roles and responsibilities for AI…)
  G5  BLOCKED  — blocking: O5 (An audit log — capturing model…), I2 (Roles and responsibilities for
AI…), I3 (An AI risk register per ISO/IEC 42001…), I4 (The AI system lifecycle is documented…), I5
(An internal audit of AI governance…)

The same answers at --risk-class high turn G2 into BLOCKED — blocking (skips not permitted): D3. tests/test_book_example.py pins this output; see docs/book-compatibility.md.

Checklist

25 items derived from the five appendix sections of the IKI-Gov framework:

Scoring

score_m(dim) = sum(weight_i for affirmed items in dim)
               / sum(weight_i for non-skipped items in dim) × 100

overall = arithmetic mean(M1, M2, M3, M4, M5, M6)

Risk-class multipliers: low = 1.0 · medium = 1.5 · high = 2.0. Skipped items are excluded from both numerator and denominator (conservative).

Gates

Status: OPEN (all affirmed) · PARTIAL (some skipped, none denied) · BLOCKED (≥1 denied)

Risk-class-aware thresholds (v0.3.0)

How skips are treated depends on the active risk class:

--strict forces high-risk behaviour at any risk class. When a skip blocks a gate, it is reported separately (blocking_skips) so the reason for a BLOCKED-not-PARTIAL gate is explicit.

CI exit codes

--assert-gate Gn exits with a status-specific code so pipelines can branch without parsing output:

--quiet (-q) on assess and gate emits machine-readable JSON only.

Regulatory-Content Packs (v0.16.0)

The ISO/IEC 42001 and EU AI Act mappings are versioned content packs behind a generic coverage engine, so new frameworks are added as data:

iga content-list                              # built-in + external packs (versions, hashes)
iga framework-gap --framework iso42001 --affirm S1,S2,D1
iga framework-gap --framework euaiact --risk-class high --affirm S1,S2,D5 --quiet
iga framework-gap --framework nist-ai-rmf --affirm S1,S2,S3   # NIST AI RMF (Govern/Map/Measure/Manage)

A pack maps each target (clause/article) to the checklist items or gates that evidence it. Drop a JSON pack into IGA_CONTENT_PATH (or ~/.iga/content/) to add or override a framework; an external pack with the same framework_id overrides the built-in. The legacy iso-gap / euaiact-gap commands are unchanged.

ISO/IEC 42001 Coverage

iga iso-gap maps the assessment to ISO/IEC 42001 clause-level coverage. Each clause group (clauses 4–10 and Annex A controls) is reported as covered (all mapped checklist items affirmed), partial, or gap, with the outstanding items listed per incompletely-covered clause:

ISO/IEC 42001 Coverage Gap Analysis — fraud-scoring  [risk: HIGH]

  4   Context of the organization      PARTIAL    (1/2)  — Outstanding items: S4
  5   Leadership                       COVERED    (4/4)
  8   Operation                        GAP        (0/13) — Outstanding items: D1, D2, …
  A   Annex A (Controls)               GAP        (0/12) — Outstanding items: …

Skipped and denied items count as not affirmed (no coverage credit). The item→clause matrix is derived from the IKI-Gov orientation table (tab:framework-iso42001-matrix) and centralised in checklist.ISO_CLAUSES_BY_ITEM. Use --quiet for machine-readable JSON.

EU AI Act (High-Risk Systems)

iga euaiact-gap maps gate readiness to the EU AI Act obligations for high-risk systems (Articles 9–18, plus Art. 72 post-market monitoring). Each article is reported OPEN / PARTIAL / BLOCKED based on the readiness of the gates that generate its evidence:

EU AI Act High-Risk Compliance Gap — fraud-scoring  [risk: HIGH]

  Art. 9   Risk management system     G0, G1, G2, G4   PARTIAL  — G2 BLOCKED, G4 BLOCKED
  Art. 10  Data and data governance   G1               OPEN
  Art. 11  Technical documentation    G2, G3           BLOCKED  — G2/G3 BLOCKED

The gate→article mapping is transcribed verbatim from the IKI-Gov book (tab:framework-euaiact-gates, as corrected in the October 2026 proofs: G4 cites Art. 9 with Art. 72, G5 cites Art. 18 and 17) and lives in euaiact.EU_AI_ACT_ARTICLE_GATES. The command is for high-risk systems only (exits with a warning for low/medium risk); --quiet emits JSON.

This tool does not constitute legal advice or a conformity assessment.

Persistence & Portfolio

iga assess --save persists an assessment to a local SQLite database at ~/.iga/assessments.db (override with the IGA_DB_PATH env var). The portfolio commands then work across saved use cases:

list and portfolio support --quiet for JSON. Only what you provide is stored (use-case name, risk class, language, answers/scores/gates); the database file is created with 0600 permissions and the ~/.iga directory with 0700. delete is a hard delete; no soft-delete log is retained.

External Evidence

Affirmations can be backed by signed evidence emitted by peer presidio-hardened-* controls (first producer: presidio-hardened-ai), upgrading an item from self-attested to evidence-backed — or cryptographically verified against a local trust store. Verification is fail-closed: a missing, malformed, or wrong signature never counts as verified.

# Affirm items from an evidence document, verifying signatures against a trust store
iga assess --use-case "fraud-scoring" --risk-class high \
    --evidence evidence.json --trust trust.json

# Fail-closed: ONLY items whose reference verifies against --trust count.
# Bare --affirm / wizard answers are recorded as "asserted" and do not count.
iga assess --use-case "fraud-scoring" --risk-class high \
    --affirm S1,S2 --evidence evidence.json --trust trust.json --require-evidence

# Verify a document on its own (exit 0 only if every reference verifies)
iga verify-evidence --evidence evidence.json --trust trust.json

--require-evidence means evidence only (v0.26.0)

--require-evidence is available on every command that takes answers: assess, gate, report, export, certify, framework-gap, iso-gap, euaiact-gap, classify assess and the iga_assess_with_evidence MCP tool. Under the flag an item counts as affirmed only if a reference in --evidence verifies against --trust. A bare --affirm (or wizard) answer without such a reference is asserted: it is recorded, named on stderr, shown in every output as asserted (not counted), and it does not enter the score or the gates. With no --evidence, no --trust, an empty trust store, an unknown signer, a wrong key or a tampered signature, nothing verifies and nothing counts. Skipped items stay skipped.

Before v0.26.0 the flag only filtered --evidence inputs. A bare --affirm still counted, and without --evidence the flag was not read at all, so --require-evidence --trust '{}' over all 25 items reported 100 % with every gate OPEN. See SECURITY.md and CHANGELOG.md (0.26.0, Security).

Every output now marks each item, whatever flags produced it: the per-item provenance (self | evidence | evidence-verified) is always present on affirmed and asserted rows, JSON carries answers.asserted and evidence_coverage (require_evidence, asserted_not_counted), the gate and gap JSON carry an evidence block, the Markdown report has an Evidence column and a summary line under the score, and the signed export manifest carries the same evidence block inside the signed bytes, so a pack states on its face what its numbers rest on.

An evidence document is the producer's EvidenceRef JSON:

{
  "schema": "presidio-hardened/evidence-ref@1",
  "use_case": "fraud-scoring",
  "evidence": [
    {
      "item_id": "D1",
      "source": "presidio-hardened-ai",
      "source_version": "0.2.0",
      "ledger_ref": "pai-ledger:seq/0",
      "content_hash": "abc123def456",
      "signer": "presidio-hardened-ai",
      "signature": "2e7af6d2…",
      "claimed_at": "2026-06-08T00:00:00+00:00"
    }
  ]
}

A trust store maps each signer to its key. An entry is either a bare HMAC secret (back-compat) or an object declaring the algorithm and key material:

{
  "presidio-hardened-ai": "shared-hmac-secret",
  "peer-control": { "alg": "ed25519", "public_key": "<64-hex-char public key>" }
}

For key rotation, public_key (or key for HMAC) may be a list — a signature verifies if it matches any listed key, so a new key can run alongside the old one during an overlap window; revoke by removing the key from the store:

{
  "peer-control": { "alg": "ed25519", "public_key": ["<new public key>", "<retiring key>"] }
}

Ed25519 (RFC 8032) public-key verification lets a verifier hold only public keys (no shared secret with the producer) and requires the [crypto] extra. Signatures are over the canonical {content_hash, signer} message; signer keys are resolved from the local trust store only (no network). Evidence references carry hashes and opaque ledger URIs, never PII. Because that message does not name the item, one signed ref claimed for several items verifies for none of them: each piece of evidence backs exactly one item.

How this fits the wider suite: ikigov-assess is the governance spine that consumes evidence from peer presidio-hardened-* controls. For the cross-repo overview (how the family interlocks and an end-to-end demo), see presidio-hardened-* Suite Architecture (in presidio-hardened-ai).

Gate Certificates (v0.23.0)

A gate certificate (presidio-hardened/gate-certificate@1) makes the certificate the proof. Today a gate decision (OPEN / PARTIAL / BLOCKED) is trusted because iga computed it. A certificate inverts that: it is a compact, signed artifact that any third party verifies locally against a trust store, without running ikigov-assess and without the assessments database — the contrast to centralized policy-decision points (Cedar / Zanzibar class), where the verdict is trusted because a service returned it. This is the product-form of the Computational Jurisprudence program (Stantchev, arXiv 2026): local verification, no engine in the trust path, fail-closed.

The certificate carries its own grounding: the sufficient affirmation set (per-item affirmed / skipped / denied for every gate item), any embedded evidence-refs verbatim, and the decision predicate inputs — the gate's item ids, the risk class, the effective strict flag, and the predicate content hash — so a verifier recomputes the decision from the certificate alone and compares it to the claim.

# Emit a signed gate certificate after evaluating a gate
iga certify --gate G2 --use-case "fraud-scoring" --risk-class high \
    --affirm S1,S2,D1,D2,D3,D4,D5,T1,T2,T3 \
    --evidence evidence.json --trust trust.json \
    --issuer "presidio-assessor" --sign-alg ed25519 \
    --sign-key-file issuer.key --output cert.json

# Verify locally against a trust store — no DB, no engine, fail-closed
iga verify-certificate --certificate cert.json --trust trust.json

When --evidence is supplied to iga certify, --trust is mandatory and every evidence-ref must verify before it is embedded; a failing ref aborts issuance. Verification then independently runs five checks, each with a distinct fail reason: unknown schema → unknown-schema; the issuer signature (detached, over the canonical bytes of the certificate minus the signature field) → bad-signature / unknown-issuer; predicate identity → predicate-content-mismatch; every embedded evidence-ref re-verified against the verifier's trust store → evidence-ref-failure; and the decision recomputed from the embedded predicate inputs vs the claim → decision-mismatch. It reads only the certificate and the trust store.

Canonicalization and signing reuse the family conventions used by evidence-refs and the workshop manifest: canonical JSON is json.dumps(sort_keys=True, separators=(",", ":"), ensure_ascii=False) UTF-8, hashed with SHA-256; the issuer signature is HMAC-SHA256 or Ed25519 (RFC 8032), resolved from the same trust-store shape as evidence-refs.

Scope of the claim (no overclaiming): a gate certificate proves that, under the declared predicate and the embedded affirmation set / evidence, the gate decision recomputes to the claimed value. It does not prove that the underlying controls are effective, nor that the evidence's real-world claim is true.

Lineage, validity, grounding and tiers (v0.26.0)

Four additive, optional fields, all inside the signed content, so pre-v0.26 certificates verify unchanged:

• parents (--parent <hex>, repeatable) — ADR-0002 provenance parents: the content hashes of the evidence this decision rests on, typically the eai-classification@1 document and the workshop manifest. Signed over, so lineage cannot be rewired after issuance; acyclic by construction; omitted when empty. Resolving a parent is the consumer's walk, not the verifier's.
• not_after (--valid-days N) — a validity bound. Expiry is the only revocation this format has, deliberately: no revocation list, no accumulator, no coordination. The verifier fails closed past it (expired); verify-certificate --at <UTC> verifies as of a given instant, which makes the check reproducible. No bound means no expiry.
• grounding — the weakest provenance in the affirmation set: self if any affirmed gate item has no embedded evidence-ref, else evidence-verified. A self-attestation by a named signer is not the attested tier; it is an unbonded assertion. The verifier recomputes it (grounding-mismatch) and --min-grounding evidence-verified fails closed on any self-attested item (grounding-below-minimum).
• Assurance tiers — evidence documents may now be evidence-ref@2 (presidio-evidence ADR-0003); a ref's declared assurance_tier (attested | optimistic | zk, default attested) is honoured only under @2 and round-trips into the certificate. It is a declaration: the verifier re-checks the ref's signature, never a fraud proof or a zk proof, and reports the weakest declared tier so --min-evidence-tier can demand a floor (evidence-tier-below-minimum); a certificate with no embedded ref fails that floor too (no-evidence-for-tier-floor). The certificate's own assurance_tier is attested and nothing else; a certificate declaring any other tier is rejected (unsupported-assurance-tier), which keeps a future zk gate certificate from being mistaken for one this verifier can check.

MCP Server

The assessment engine is also available as a Model Context Protocol server, so MCP-capable LLM agents and clients can run IKI-Gov assessments as tools.

# Install with the MCP extra (requires Python 3.10+ and the mcp 2.x SDK)
pip install "presidio-hardened-ikigov-assess[mcp]"

# Run the server over stdio
iga-mcp

It is listed in the MCP Registry as io.github.presidio-v/presidio-hardened-ikigov-assess; registry clients start it with uvx --from "presidio-hardened-ikigov-assess[mcp]" presidio-hardened-ikigov-assess, which runs the same server as iga-mcp.

Register it with an MCP client (e.g. Claude Desktop) by adding to the client's config:

{
  "mcpServers": {
    "iki-gov-assess": {
      "command": "iga-mcp"
    }
  }
}

Tools

All tools share the CLI's input validation and output sanitisation, return the same structured JSON schema as iga report --format json, and respect the per-session abuse guard (returning a tool error rather than terminating the server when exceeded).

Evidence-Pack Export (v0.15.0)

Export a signed, audit-ready bundle of an assessment and verify it later:

# Write report.md + report.json + manifest.json (sha256 of each artifact + framework hash).
# Seal the manifest with an HMAC key read from a file (kept off argv / shell history).
iga export --use-case fraud-scoring --risk-class high --affirm S1,S2,D1 \
    --bundle audit/fraud-scoring/ --sign-key-file ~/.iga/seal.key

# Re-hash artifacts against the manifest (and check the optional HMAC seal).
iga verify-bundle --bundle audit/fraud-scoring/ --sign-key-file ~/.iga/seal.key

The manifest.json content-hashes every artifact and records a framework_content_hash pinning the checklist + ISO/EU AI Act mappings that produced the assessment, so any later edit is detected by verify-bundle. Use --zip to emit a .zip. (PDF rendering and a public-key manifest signature are deferred; the hash manifest + optional HMAC seal are the integrity baseline.)

The seal key is resolved from --sign-key-file <path> (preferred), then --sign-key <key> (inline; avoid — visible in shell history and the process list), then the $IGA_SIGN_KEY environment variable. Use the same source for export and verify-bundle.

Classificator Bridge (eai-classification/v1)

v0.20.0 — producer-agnostic interchange layer between the Enterprise AI Classification Framework and the IKI-Gov assessment engine.

The bridge accepts documents from any producer that conforms to the eai-classification/v1 schema — the research eai-classificator tool, partner survey tooling, or hand-crafted JSON. The schema is keyed to the model (6×6 matrix: types T1–T6 × autonomy levels L1–L6), not to any one tool's output format.

Example classification document

{
  "schema": "eai-classification/v1",
  "producer": {"tool": "eai-classificator", "version": "1.0.0"},
  "use_cases": [
    {
      "id": "fraud-scoring",
      "type": "T1",
      "level": "L4",
      "name": {"de": "Betrugserkennung", "en": "Fraud Scoring"},
      "confidence": 0.92,
      "tags": ["finance", "high-risk"]
    },
    {
      "id": "customer-chat",
      "type": "T4",
      "level": "L3",
      "ecosystem": true
    }
  ]
}

L6 / ecosystem regime: level L6 is the non-ordinal ecosystem/multi-system coordination overlay. Set "ecosystem": true on any L1–L5 use case to indicate it participates in a multi-system coordination regime — the parser normalises the effective cell level to L6 and retains base_level for the record. level=L6 combined with ecosystem=false is a contradiction and is rejected.

Ingest a classification document

# Human table: use case, cell, risk presumption, strict, obligations, note
iga classify ingest --file classification.json --lang de

# Machine JSON: includes pack content_hash and producer echo
iga classify ingest --file classification.json --quiet

Run a profiled assessment from a classification document

# Resolve the selected use case's profile, then run the full assess pipeline
iga classify assess \
    --file classification.json \
    --select fraud-scoring \
    --affirm S1,S2,D1,D2,T1 \
    --lang de \
    --quiet \
    --save

# The profile's risk_class and strict flag are pre-set from the classification
# pack. --strict may further tighten; profile strict=true cannot be loosened.

The classify assess command reuses the full existing pipeline (compute_scores, evaluate_all_gates, render_json, store.save_assessment, log_security_event) and logs a iga-classify-assess security event including the cell id and the profile pack content_hash.

Classification-profile pack override

The built-in pack (eai-classification-default, DRAFT semantics) is automatically loaded. To override it, drop a JSON file with "pack_kind": "classification-profile" into IGA_CONTENT_PATH (default ~/.iga/content/). The file must cover all 36 cells; a pack with the same framework_id overrides the built-in.

{
  "pack_kind": "classification-profile",
  "framework_id": "eai-classification-default",
  "version": "my-org-1.0",
  "profiles": {
    "T1.L1": {"risk_presumption": "low", "strict": false,
               "obligations": ["iso42001", "euaiact"],
               "notes": {"en": "Minimal oversight required."}},
    "T1.L2": { "..." : "..." }
  }
}

ContentPacks (regulatory framework gap mappings) and ProfilePacks coexist in the same directory; the loader discriminates by pack_kind.

JSON Schema for external producers

schemas/eai-classification.v1.schema.json (repo root) provides a JSON Schema draft/2020-12 definition that partner producers can use for pre-publication validation. The Python parser in classification.py is the authoritative source; jsonschema is not a declared project dependency.

Workshop Mode (T-B3/T-B4)

iga workshop run is the live customer-workshop tool: run it on a laptop connected to a projector, point it at a classification document, and it renders each use case in large-format, high-contrast rich output while simultaneously writing a leave-behind artifact (the "Übergabeunterlage") per use case to disk. The whole cycle (projector rendering plus artifact generation) targets under 2 minutes per use case. Since v0.22.0 the recommended custody model is customer anchored: the customer signs the manifest with a key generated on their own hardware, and presidio countersigns as assessor in a separate attestation document.

Offline-capable

Workshop mode is designed for air-gapped customer sites. It explicitly bypasses the startup CVE / dependency check (pip-audit requires network access; on an air-gapped site it would hang, time out, and emit a noisy "inconclusive" warning). The dep-check bypass is automatic when the workshop subcommand is detected; no --no-dep-check flag required. Security posture is maintained by running pip-audit on the founder's machine before the session.

Example

# Generate leave-behind artifacts for all use cases in a classification document,
# in German (default), writing to ./workshop-out/<date>/.
iga workshop run \
    --file classification.json \
    --lang de

# Generate for selected use cases only.
iga workshop run \
    --file medical.json \
    --select infusion-pump-dosing \
    --select surgical-robotics \
    --out /tmp/workshop-2026/

# Pre-populate answers (assessor filled a form earlier).
iga workshop run \
    --file classification.json \
    --answers answers.json

# Quiet: write artifacts only, no projector output.
iga workshop run --file classification.json --quiet

The answers.json format is:

{
  "fraud-scoring": {
    "affirm": ["S1", "S2", "S3", "D1", "D2"],
    "skip":   ["I4", "I5"]
  }
}

Artifact layout per use case

workshop-out/<date>/<use_case_id>/
  report.de.md       Markdown leave-behind (localised)
  report.json        Full assessment JSON + classification provenance block
  sign.py            Standalone customer owner signer
  SIGNING.md         Bilingual signing-ceremony runbook
  assessor.pub       Presidio assessor public key, when supplied/derived
  manifest.json      Content-hashed manifest (presidio-hardened/workshop-leavebehind@1)
  manifest.sig       Ed25519 detached signature (UNSIGNED marker if no key provided)
  attestation.json   Optional presidio assessor attestation envelope
  attestation.content.json

manifest.json records: tool version, cell id, risk class, language, profile-pack content hash, SHA-256 of every artifact, and whether the artifact is signed.

Customer owner signing and presidio attestation

Generate the customer owner keypair on customer hardware. The private key is created mode 0600; hand only the public key to presidio for the engagement trust store:

iga workshop keygen --out customer-key.hex --signer "ACME GmbH"

After iga workshop run writes the leave-behind, the customer signs the manifest as owner:

iga workshop sign \
    --dir workshop-out/2026-07-04/infusion-pump-dosing/ \
    --key customer-key.hex \
    --signer "ACME GmbH"

Presidio then countersigns the customer-signed manifest as assessor. The attestation is a separate workshop-attestation@1 evidence document bound to the manifest hash:

iga workshop attest \
    --dir workshop-out/2026-07-04/infusion-pump-dosing/ \
    --engagement hc-workshop-2026-001 \
    --sign-key ~/.iga/workshop-assessor.key \
    --signer presidio-hardened-ikigov-assess

Verify a leave-behind (customer side)

The customer verifies their owner signature and, when required, the presidio assessor attestation:

# Verify the artifact in the infusion-pump-dosing/ directory.
iga workshop verify \
    --dir workshop-out/2026-07-04/infusion-pump-dosing/ \
    --pubkey <customer-public-key>

# Require a valid presidio attestation bound to the manifest.
iga workshop verify \
    --dir workshop-out/2026-07-04/infusion-pump-dosing/ \
    --pubkey <customer-public-key> \
    --require-attestation \
    --attestation-pubkey <presidio-assessor-public-key>

# Machine-readable JSON result.
iga workshop verify \
    --dir workshop-out/2026-07-04/infusion-pump-dosing/ \
    --pubkey <customer-public-key> \
    --quiet

Exit 0 if all artifact hashes and the signature verify; exit 1 otherwise (fail-closed). An UNSIGNED leave-behind fails too, because matching hashes alone prove nothing about who produced the files; pass --allow-unsigned to accept hash consistency only. The JSON result carries authenticated: true only when a signature verified.

Named delegation chain (v0.23.0)

The customer-signature → manifest-hash → presidio-attestation lineage is exposed as an explicit delegation chain: an ordered list of named links, each stating its role, signer, what it signs, and the hash it references. --show-chain walks the chain link-by-link with a distinct failure reason per link (owner-sig-invalid, owner-key-mismatch, assessor-missing-key, plus every attestation reason such as attests-manifest-mismatch); --require-chain additionally fails closed unless an owner link is present. This is additive and derived — the chain is assembled at verify time from the existing owner block, manifest.sig, and attestation, so manifests produced before v0.23.0 (which carry no chain) verify unchanged.

iga workshop verify \
    --dir workshop-out/2026-07-04/infusion-pump-dosing/ \
    --pubkey <customer-public-key> \
    --attestation-pubkey <presidio-assessor-public-key> \
    --show-chain --quiet

Security

See SECURITY.md for the full security policy.

Security controls built into the tool:

• Input validation for all CLI parameters (type, bounds, allow-list)
• HTML-escaping of all user-supplied strings in report output
• Structured security event log at ~/.iga/security.log (no content logged, structural metadata only)
• On-startup CVE check via pip-audit (suppress with --no-dep-check; iga --version skips it, so reporting the installed version works offline)
• Session rate limiting (default: 100 assessments; override via IGA_MAX_ASSESSMENTS)

Project supply chain: OpenSSF Best Practices silver and OpenSSF Scorecard (current scores in the badges at the top). Changes to main need a second reviewer's approval; release tags are signed; each release publishes to PyPI via OIDC Trusted Publishing with a provenance attestation and a CycloneDX SBOM; the parsers are fuzzed (Atheris).

Roadmap

Full version deliberation log: PRESIDIO-REQ.md

Planned (next 12 months)

Directional; planned or in-flight work, not commitments:

• Next — broader framework-gap coverage (ISO/IEC 42001 refinements and EU AI Act updates as implementing acts land) and additional evidence producers feeding the assess --evidence / gate-certificate flow.
• Under evaluation — reproducible builds and per-file provenance toward the OpenSSF gold criteria.

Development

# Install in editable mode with dev dependencies
pip install -e ".[dev]"

# Run tests
pytest

# Lint and format
ruff format .
ruff check . --fix

License

MIT. See LICENSE.

SDLC

This repository is on the open-source baseline of the PRESIDIO hardened-family SDLC (report · PDF). The controls measured for it, and any open gaps, are its row in the applicability matrix.

Governance, Architecture & Security

• Governance — roles, decision process, and project continuity.
• Architecture — components, processing flow, and trust boundaries.
• Assurance case — the security claims and the evidence for each.
• Security policy — supported versions and how to report a vulnerability.
• Contributing · Code of Conduct · Versioning