
Presidio Hardened Ikigov Assess
io.github.presidio-v由 GitHub 帳號 presidio-v 發布v0.29.1更新於 Nov 2, 2026
IKI-Gov AI governance assessment: score AI use cases, check quality gates G0-G5, map to EU AI Act.
概覽
依 IKI-Gov 治理模型為 AI 使用案例評分,檢查品質關卡 G0–G5,並對應到 ISO/IEC 42001 與歐盟 AI 法案。
- 可以做什麼
- 說明治理模型:生命週期階段、構面 M1–M6、關卡 G0–G5、章節與風險等級
- 列出 25 個檢查項目及其編號、文字、所屬構面、相關關卡與章節
- 依已確認或略過的檢查項目編號,計算各構面分數、整體成熟度與關卡就緒狀態
- 評估單一關卡 G0–G5,並列出阻擋項目與略過項目
- 將已確認項目對應到 ISO/IEC 42001 條款涵蓋度與歐盟 AI 法案高風險義務
- 依帶簽章的證據文件評分,並以本機信任庫驗證 HMAC 或 Ed25519 簽章
- 適用情境
- 適合需要依結構化治理框架評估 AI 使用案例、準備關卡就緒檢查,或為審查產生 ISO/IEC 42001 與歐盟 AI 法案落差檢視的情況。它只是定位用的啟發式工具,不構成法律意見或符合性評估。
- 執行需求
- 以 Python 套件形式在本機執行(uvx 或 pip 安裝)。未宣告需要帳號、API 金鑰或環境變數。選用附加元件提供相依套件漏洞檢查與 Ed25519 驗證;證據驗證需要證據文件與本機信任庫檔案。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 Presidio Hardened Ikigov Assess,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
presidio-hardened-ikigov-assess
🇬🇧 English · 🇩🇪 Deutsch
[PyPI version] [Python] [GitHub release] [Tests] [CodeQL] [OpenSSF Scorecard] [OpenSSF Best Practices] [License: MIT]
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
Quick Start
Example output
The worked example from the book (Anhang B, corrected proof), at a 100-column terminal:
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
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:
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:
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:
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.
--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
--evidenceinputs. A bare--affirmstill counted, and without--evidencethe flag was not read at all, so--require-evidence --trust '{}'over all 25 items reported 100 % with every gate OPEN. SeeSECURITY.mdandCHANGELOG.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:
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:
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:
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 (inpresidio-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.
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 theeai-classification@1document 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:selfif any affirmed gate item has no embedded evidence-ref, elseevidence-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-verifiedfails 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 declaredassurance_tier(attested|optimistic|zk, defaultattested) is honoured only under@2and 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-tiercan 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 ownassurance_tierisattestedand 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.
Certificate identity (v0.29.0)
certificate_content_hash(cert) returns the identity of a certificate: SHA-256 over the
canonical bytes the issuer signs (the document minus signature), lowercase hex. It is
the hash a downstream payload puts in its parents to name the gate decision that
admitted it, per the family evidence contract. It ignores the signature block, so
re-signing keeps it; any change to the signed content changes it. framework_content_hash
names the gate rule shared by every certificate under it and is not a parent. The
identity says nothing about validity; verify the certificate first.
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.
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:
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:
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
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
Run a profiled assessment from a classification document
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.
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
The answers.json format is:
Artifact layout per use case
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:
After iga workshop run writes the leave-behind, the customer signs the
manifest as owner:
Presidio then countersigns the customer-signed manifest as assessor. The
attestation is a separate workshop-attestation@1 evidence document bound to
the manifest hash:
Verify a leave-behind (customer side)
The customer verifies their owner signature and, when required, the presidio assessor attestation:
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.
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 --versionskips 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
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
來源:README.md,提交 252c6dc
工具
0版本歷史
4- v0.29.1最新Oct 26, 2026
- v0.29.0Oct 18, 2026
- v0.28.0Oct 8, 2026
- v0.27.0Sep 30, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分