`froga` CLI reference
froga is the Risk-Driven Development (RDD) CLI for high-risk AI systems. RDD is an established software-engineering term (Boehm, Fairbanks) that Venturalítica specializes for AI regulatory risk treatment (see lineage). Every subcommand operates on a git repository (flag --repo, default is the working directory .). Subcommands that write artifacts sign them with ECDSA-P256+DSSE (pluggable signer: local or Scaleway KMS, per FROGA_SIGNING_BACKEND) before writing them to .froga/. There are 22 visible subcommands (plus the hidden assess): init, run, status, verify, export, anchor, pubkey, compile, reconstruct, soa, conformance, risk-projection, impact, request, approve, review, reject, retire, auth, entitlement, sign-pliego, and sign-detached.
froga init
Section titled “froga init”Creates the project skeleton inside a git repository: generates the .froga/ directory and the froga.yaml manifest (with the risk section of the assurance program), if they do not already exist.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
What it writes
Section titled “What it writes”froga.yaml— system manifest (if it did not exist)..froga/— signed-artifact directory (if it did not exist).
Example
Section titled “Example”froga init --repo /path/to/projectfroga run
Section titled “froga run”Runs the full pipeline (steps P1–P11) with drift detection: recomputes only the sections marked stale against froga.lock, anchors the result, and signs the evidence bundle.
The risk gate determines the exit code: if any blocking control fails, froga run returns exit ≠ 0 even though the evidence is still anchored and signed.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
What it writes
Section titled “What it writes”.froga/bundle.json— signed evidence bundle (ECDSA-P256+DSSE)..froga/bundle.json.sig— DSSE signature of the bundle.froga.lock— freshness anchor (hashes of pipeline sections).
Normative relevance
Section titled “Normative relevance”The risk gate implements the continuous monitoring requirement of EU AI Act Art. 9 and the treatment loop of ISO 23894 §6.5.
Example
Section titled “Example”froga runfroga status
Section titled “froga status”Detects drift against froga.lock and evaluates the state of gate controls without recomputing. Returns exit 0 if the system is up-to-date and conformant; exit ≠ 0 on drift or failing blocking controls.
Use it as a CI/CD gate with no recomputation cost.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
What it returns
Section titled “What it returns”- Prints the drifted sections and failing controls.
- Exit 0 = freshness ✓ + conformance ✓; exit ≠ 0 if either fails.
Example
Section titled “Example”froga statusfroga verify
Section titled “froga verify”Verifies the ECDSA-P256+DSSE signatures of the entire evidence dossier present in .froga/: bundle.json, reconstruct.json, conformance/*.json and risk-projection/*.json (each against its .sig). entitlement.json is deliberately excluded: it is signed by the Venturalítica issuer, not by the system. It verifies against an explicit public key — the third-party verification path (auditor, contracting authority), which does not need the manufacturer’s private key. The pubkey resolves in order: --pubkey → .froga/PUBKEY.txt → (only with --allow-dev-key) the local signing backend.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--pubkey | string | (.froga/PUBKEY.txt) | Signer’s public key (uncompressed SEC1, hex 04…, 130 characters). If omitted, .froga/PUBKEY.txt is read. |
--allow-dev-key | bool | false | Falls back to the local signing backend when there is no --pubkey and no .froga/PUBKEY.txt. Development only: you verify against your own key, with no non-repudiation towards a third party. |
--export | path | (none) | Instead of the repo dossier, verifies an export package (the directory produced by froga export): checks the git bundle, the manifest signature against its pubkey.pem, and that the manifest describes that bundle. See froga export. |
What it returns
Section titled “What it returns”- Prints
firma VÁLIDA(valid signature) and exit 0, orfirma INVÁLIDA(invalid signature) and exit ≠ 0. - A dossier artifact missing its
.sigis a failure: a signed dossier must carry the signature of every piece. - Fails if the bundle or signature does not exist (indicates
froga runhas not been executed), or if there is no public material to verify against (no--pubkey, noPUBKEY.txt, no--allow-dev-key).
Example
Section titled “Example”# Third-party verification: against the signer's published pubkeyfroga verify --pubkey 04a1b2…# With .froga/PUBKEY.txt present in the repofroga verifyfroga pubkey
Section titled “froga pubkey”Prints the configured engine signer’s public key (ECDSA-P256, uncompressed SEC1 format, 65 bytes in hexadecimal). The customer exports it and registers it in the cloud (the connection’s signerPubkey field) so the cloud can verify their signed evidence (per-connection verification).
What it returns
Section titled “What it returns”- The public key in hexadecimal (130 characters,
04prefix) on standard output. - Honors the signer configured by
FROGA_SIGNING_BACKEND(localorscaleway-kms).
Example
Section titled “Example”froga pubkey# 0477b3dc…c60froga compile
Section titled “froga compile”Compiles the assurance program (Art. 9) declared in the risk section of froga.yaml and generates the corresponding oscal.assessment_plan. This plan is the formal gate contract: it defines which controls are measured and under what conditions.
Also emits advisory warnings about the control hierarchy (prEN 18228 cl. 9.1.2): does not block compilation, but flags controls without a declared hierarchy level.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
What it writes
Section titled “What it writes”- The file declared in
oscal.assessment_plan(OSCAL assessment plan).
Normative relevance
Section titled “Normative relevance”EU AI Act Art. 9 (risk management system); ISO 23894 §6.4 (assessment planning).
Example
Section titled “Example”froga compilefroga reconstruct
Section titled “froga reconstruct”Reconstructs the ISO 23894 risk treatment cycle per risk by replaying the git history of the evidence bundle (.froga/bundle.json). The process is deterministic and requires no language model.
For each risk, the report traverses five phases: ① identification (commit that introduced the risk into the AssuranceProgram), ② analysis (likelihood × impact → inherent level), ③ evaluation (vs. risk appetite), ④ treatment (empirical FAIL→PASS arc per commit), ⑤ residual risk (ISO cycle: CLOSED / OPEN / DISCREPANCY / ACCEPTED).
Also reports the most recent management approval (ISO 42001 §6.1.3) and the treatment priority order (ISO 42001 §6.1.2e2).
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--out | bool | false | If specified, writes .froga/reconstruct.json (+ .sig) in addition to printing to stdout. |
What it writes (with --out)
Section titled “What it writes (with --out)”.froga/reconstruct.json— structured signed report (ECDSA-P256+DSSE)..froga/reconstruct.json.sig— DSSE signature.
Normative relevance
Section titled “Normative relevance”ISO 23894 §6.4.2 (identification), §6.4.3 (analysis), §6.4.4 (evaluation), §6.5 (treatment and residual); ISO 42001 §6.1.2–6.1.3.
Example
Section titled “Example”froga reconstruct --outfroga export
Section titled “froga export”Exports an offline-verifiable audit package: a self-contained directory that a third party (notified body, auditor) checks with no network and no access to the forge. It packs the full git DAG as a git bundle plus a signed DSSE manifest that binds that bundle to the derived ISO 23894 verdict via reconstruct_sha256 (reproducible by cloning the bundle and re-running froga reconstruct). The strong verdict binding is that digest, not the bundle hash.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--out | path | (froga-export-<system>-<oid>/) | Output directory for the package. |
--ref | string | HEAD | Ref to export (its entire ancestor DAG is packed). |
What it writes
Section titled “What it writes”<out>/repo.bundle—git bundleof the full DAG up to the ref.<out>/manifest.dsse.json— signed DSSE in-toto manifest (predicategit-bundle/v1), including the signer keyid.<out>/pubkey.pem— the signer’s public key (SPKI PEM). The auditor must confirm it out-of-band against the publisher’s known key: the signature proves integrity, not authenticity on its own.<out>/README.txt— offline verification instructions.
Fails closed if the repository is shallow or has refs/replace/* (the DAG would not be faithful), or if the destination exists and is non-empty.
Normative relevance
Section titled “Normative relevance”EU AI Act Annex IV (technical documentation deliverable to third parties); ISO 23894 §6.4–6.5 (verifiable reconstruction of the treatment cycle).
Example
Section titled “Example”froga export --out audit-package/froga verify --export audit-package/froga anchor
Section titled “froga anchor”Signs the tip of the governed ref (HEAD by default) with a DSSE topology-anchor act and writes it to the annotated tag froga/anchor. Thanks to the Merkle property of the git DAG, the tip’s OID commits to the entire ancestor history: anchoring it closes the A2 vector (the cloud deriving the lifecycle by blindly trusting the topology reported by the forge’s REST API, instead of verifying it against a compromise signed by the engine itself).
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--ref | string | HEAD | Ref whose tip gets anchored. |
What it writes
Section titled “What it writes”- The annotated tag
froga/anchor(git tag -a -f), moved to the ref’s tip, carrying the signed DSSE envelope (predicatetopology-anchor/v1) as the tag message.
Fails closed if the repository is shallow or has refs/replace/* (the DAG would not be faithful), or if no signing key is configured.
Normative relevance
Section titled “Normative relevance”EU AI Act Art. 12 (record-keeping); ISO 23894 §6.4 (traceability of the topology the treatment cycle is derived from).
Example
Section titled “Example”froga anchorfroga soa
Section titled “froga soa”Generates the Statement of Applicability (SoA — ISO/IEC 42001 §6.1.3 b/c/f). Crosses the ISO/IEC 42001:2023 Annex A catalog against the measures declared in the AssuranceProgram and the latest evidence bundle. Classifies each control as:
- INCLUDED — covered by at least one AssuranceProgram measure (shows implementation status: IMPLEMENTED / PARTIAL / PLANNED / NOT IMPLEMENTED).
- EXCLUDED — explicitly justified decision (§6.1.3f).
- OMITTED — no measure implementing it and no declared exclusion (gap to review).
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
Normative relevance
Section titled “Normative relevance”ISO/IEC 42001:2023 §6.1.3 b/c/f (Statement of Applicability for the AI management system).
Example
Section titled “Example”froga soafroga conformance
Section titled “froga conformance”Evaluates per-clause conformance of the signed evidence bundle against a normative standard (prEN 18228 or ISO 23894). Projects the bundle onto the standard’s clause catalog and classifies each clause as COVERED / PARTIAL / GAP, grouped by the standard’s cycle phase.
Without --standard, emits all standards declared in context.applicable_standards of froga.yaml (highest-priority standard first).
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--standard | string | (all applicable) | Standard id, e.g. eu/pren-18228@2026 or iso/23894@2023. Omit to emit all standards declared in applicable_standards. |
--history | bool | false | Projects conformance on each bundle iteration (evidence commits), not just the current state. |
--out | bool | false | Writes .froga/conformance/<slug>.json (+ .sig) per standard, in addition to printing. |
--against-pliego | path | — | Gate against a signed OSCAL tender (pliego) from the contracting authority: intersects the clauses the tender requires with the bidder’s signed conformance evidence. Exit ≠ 0 if any block clause fails. |
--aapp-pubkey | string | — | Public key of the contracting authority that signed the tender (SEC1 hex 04…, 130 characters). Required with --against-pliego. The format is validated at parse time: malformed → usage error (exit 2), never a misleading “Rejected”. |
--pubkey | string | (.froga/PUBKEY.txt) | Public key of the bidder that signed the evidence. If omitted, .froga/PUBKEY.txt is read. Same SEC1 format, validated at parse time, as --aapp-pubkey. |
--allow-dev-key | bool | false | Falls back to the local signing backend for the bidder’s pubkey (development only, no non-repudiation). |
What it writes (with --out)
Section titled “What it writes (with --out)”.froga/conformance/<slug>.json— signed per-standard conformance report..froga/conformance/<slug>.json.sig— DSSE signature.
Gate against a signed tender (--against-pliego)
Section titled “Gate against a signed tender (--against-pliego)”With --against-pliego <pliego.oscal.yaml> --aapp-pubkey <hex>, conformance stops being an informational projection and becomes a procurement gate: it verifies the contracting authority’s signature on the tender (see froga sign-pliego), intersects the clauses the tender marks as block with the bidder’s signed conformance evidence, and returns exit ≠ 0 if any fail. This is what makes the tender impose the threshold (the contracting authority), not the vendor. Signature authenticity does not imply acceptance nor conformance: they are three distinct checks.
Exit codes — a usage error is not dressed up as a verdict:
- exit 0 — the delivery would be Accepted (all
blockclauses covered). - exit 1 — the delivery would be Rejected (naming the failing clause), or an execution error (missing
--aapp-pubkey, the bidder’s pubkey cannot be resolved…). - exit 2 — usage error: a malformed pubkey (
--aapp-pubkeyor--pubkeythat is not04+ 128 hex) is refused at parse time, with the expected format in the message. Exit 2 is not a verdict on the delivery — previously, a malformed key ended up disguised as “Rejected · missing” on every clause.
Normative relevance
Section titled “Normative relevance”prEN 18228 (CEN/CENELEC JTC 21, risk management EU AI Act Art. 9); ISO 23894 (AI risk management); EU AI Act Art. 9; EU AI Act Art. 47 (supply chain, with --against-pliego).
Example
Section titled “Example”froga conformance --standard eu/pren-18228@2026 --outfroga conformance --history# The contracting authority checks the bidder's delivery against its signed tenderfroga conformance --against-pliego pliego.oscal.yaml \ --aapp-pubkey 04a1b2… --pubkey 0477b3…froga impact
Section titled “froga impact”Generates the AI system impact assessment (ISO/IEC 42001 §6.1.4): for each system declared in the AssuranceProgram, lists the intended purpose, decisions made, and affected persons; and analyses reasonably foreseeable misuse (EU AI Act Art. 9(2)(b)), crossing it against the risk register to identify misuse scenarios not addressed by any risk.
Returns exit ≠ 0 only on dangling references: an addressed_by field pointing to a non-existent risk in the register (indicates a broken AssuranceProgram). Unaddressed misuse is flagged but does not block (advisory).
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
Normative relevance
Section titled “Normative relevance”ISO/IEC 42001:2023 §6.1.4 (AI system impact assessment); EU AI Act Art. 9(2)(b) (reasonably foreseeable misuse).
Example
Section titled “Example”froga impactfroga request
Section titled “froga request”Records the approval request for the treatment plan as a signed act in .froga/acts/ (a DSSE envelope signed with the --by actor’s key, declared in the signers: block of froga.yaml). The maintainer uses this command to initiate the formal review cycle; the act is attributed, dated and signature-verifiable, and picked up by froga reconstruct.
The typical cycle is: froga request (maintainer) → human review → froga approve (management) or froga reject (management, with reason).
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--by | string | (required) | Person or role requesting approval, e.g. "Jane Roe <jane@org>". |
What it writes
Section titled “What it writes”A signed act .froga/acts/NNNN-request.json: an in-toto DSSE envelope signed with the --by actor’s key (replaces the Froga-Approval-Requested-by: commit trailer that level 2 wrote, which was decorative and forgeable).
Normative relevance
Section titled “Normative relevance”ISO/IEC 42001:2023 §6.1.3 (review and approval process for risk treatment).
Example
Section titled “Example”froga request --by "Jane Roe <jane@org>"froga approve
Section titled “froga approve”Records the management approval of the treatment plan and acceptance of the residual risk (ISO/IEC 42001 §6.1.3) as a signed act in .froga/acts/ (a DSSE envelope signed with the --by actor’s key). The act is thus attributed to a person or role, dated and signature-verifiable, and picked up by froga reconstruct.
The four-eyes check is cryptographic: the approval must be signed with a key DIFFERENT from the one that signed the request (froga request); a self-approval with the same key does not count as a second pair of eyes.
If froga run is executed after the approval without a subsequent approval, froga reconstruct will mark the approval as STALE.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--by | string | (required) | Person or management role approving, e.g. "Jane Roe <jane@org>". |
--reason | string | (optional) | Reason for the approval, e.g. the conscious acceptance of an amber residual. |
What it writes
Section titled “What it writes”A signed act .froga/acts/NNNN-approve.json: an in-toto DSSE envelope signed with the --by actor’s key (replaces the Froga-Approved-by: commit trailer that level 2 wrote).
Normative relevance
Section titled “Normative relevance”ISO/IEC 42001:2023 §6.1.3 (approval of risk treatment and acceptance of residual risk).
Example
Section titled “Example”froga approve --by "Jane Roe <jane@org>"froga review
Section titled “froga review”Records the periodic risk review (ISO/IEC 23894 §6.6) as a signed act in .froga/acts/ (a DSSE envelope signed with the --by actor’s key). A review recorded after the approval, with no newer approval, reopens the cycle (the “under periodic review” state) until management re-approves. It covers the TIME leg of the review (the cadence is declared in risk.review_interval of froga.yaml); the “significant change” leg is already covered by the STALE approval marker.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--by | string | (required) | Person or role performing the review, e.g. "Jane Roe <jane@org>". |
What it writes
Section titled “What it writes”A signed act .froga/acts/NNNN-review.json: an in-toto DSSE envelope signed with the --by actor’s key (replaces the Froga-Reviewed-by: commit trailer that level 2 wrote).
Normative relevance
Section titled “Normative relevance”ISO/IEC 23894:2023 §6.6 (review and monitoring of the risk management process).
Example
Section titled “Example”froga review --by "Jane Roe <jane@org>"froga reject
Section titled “froga reject”Records the rejection of the approval as a signed act in .froga/acts/ (a DSSE envelope signed with the --by actor’s key). The reason is mandatory (--reason). The review cycle returns to pending state: the maintainer must correct the evidence and run froga request again.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--by | string | (required) | Person or management role rejecting, e.g. "Jane Roe <jane@org>". |
--reason | string | (required) | Reason for rejection, e.g. "missing bias evidence for subgroup X". |
What it writes
Section titled “What it writes”A signed act .froga/acts/NNNN-reject.json (in-toto DSSE), with the reason in the act payload (replaces the Froga-Rejected-by: commit trailer that level 2 wrote).
Normative relevance
Section titled “Normative relevance”ISO/IEC 42001:2023 §6.1.3 (risk treatment review process; traceability of rejection decisions).
Example
Section titled “Example”froga reject --by "Jane Roe <jane@org>" --reason "missing bias evidence for age subgroup"froga merge
Section titled “froga merge”Fuses a treatment branch into its base with four-eyes-by-key verified — an approve DSSE act on the branch signed with a different key than the request — a --no-ff merge, and a signed topology anchor act over the new tip (A6b). Reproduces LocalForge.mergePR outside the TS harness.
froga merge --branch treat/species-recall --base main --by "Marta Dev <marta@example.com>"| Flag | Value | Default | Meaning |
|---|---|---|---|
--repo | path | . | Repository to operate on. |
--branch | name | (required) | Treatment branch to merge (the one carrying the approve act). |
--base | name | main | Base branch the merge lands on. |
--by | identity | (required) | Identity of the merge commit (cosmetic — the four-eyes lives in the act signature, not the commit author). |
--title | text | (branch name) | PR/MR title for the merge message. |
--signer | ref | (env) | Signer of the topology anchor act after merging (see froga request). |
froga pr
Section titled “froga pr”Opens the PR/MR of the current branch in the forge (A1: GitLab). Takes the open subcommand.
froga pr open --base main --title "Treat species-recall"| Flag | Value | Default | Meaning |
|---|---|---|---|
--repo | path | . | Repository to operate on. |
--base | name | main | Target branch of the PR/MR. |
--title | text | (none) | PR/MR title (defaults to the forge’s own default). |
froga deliver
Section titled “froga deliver”Records the delivery of a mandatory deliverable (Annex IV, DoC, DORA RoI, DPIA, DoC-MDR) as a signed act in .froga/acts/. It is the delivery record that enables the marketable state: it replaces the old «deliverable: <kind> downloaded» commit message (which was decorative and forgeable).
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--by | string | (required) | Person or role collecting the deliverable, e.g. "Jane Roe <jane@org>". |
--kind | string | (required) | Kind of deliverable delivered: annex-iv, doc, dora-roi, dpia, doc-mdr. |
What it writes
Section titled “What it writes”A signed act .froga/acts/NNNN-deliver.json: an in-toto DSSE envelope signed with the --by actor’s key, with the deliverable kind in the payload.
Normative relevance
Section titled “Normative relevance”EU AI Act Art. 11 and Annex IV (technical documentation); Art. 47 (EU declaration of conformity, DoC); DORA Regulation (Register of Information, RoI).
Example
Section titled “Example”froga deliver --by "Jane Roe <jane@org>" --kind annex-ivfroga retire
Section titled “froga retire”Records the withdrawal of the system from the market or operation as a signed act in .froga/acts/ (a DSSE envelope signed with the --by actor’s key). The reason is optional. froga reconstruct will report the system as RETIRED from this act onward.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository to operate on. |
--by | string | (required) | Person or role retiring the system, e.g. "Jane Roe <jane@org>". |
--reason | string | (optional) | Reason for retirement, e.g. "end of operational lifecycle". |
What it writes
Section titled “What it writes”A signed act .froga/acts/NNNN-retire.json: an in-toto DSSE envelope signed with the --by actor’s key (replaces the Froga-Retired-by: commit trailer that level 2 wrote).
Normative relevance
Section titled “Normative relevance”EU AI Act Art. 9 (AI system lifecycle); EU AI Act Art. 61 (post-market monitoring and withdrawal).
Example
Section titled “Example”froga retire --by "Jane Roe <jane@org>" --reason "end of operational lifecycle"froga risk-projection
Section titled “froga risk-projection”Projects the risks in the signed evidence bundle against a normative risk framework (ISO 14971, prEN 18228, ISO 23894) and writes the result as a signed on-demand artefact. The mechanism mirrors froga conformance but raised from the measure level to the risk level: for each risk, it derives the framework’s normative vocabulary (hazard → hazardous situation → harm for ISO 14971; source → pathway → consequence for prEN 18228) and evaluates benefit-risk if declared.
Without --framework, emits all frameworks with a risk-projection catalog declared in context.applicable_standards of froga.yaml.
| Flag | Type | Default | Description |
|---|---|---|---|
--repo | path | . | Path to the git repository. |
--framework | string | (all applicable) | Risk framework id (e.g. iso/14971@2019, eu/pren-18228@2026, iso/23894@2023). Omit to emit all declared in applicable_standards that have a projection catalog. |
What it writes
Section titled “What it writes”.froga/risk-projection/<slug>.json— signed projection (ECDSA-P256+DSSE)..froga/risk-projection/<slug>.json.sig— DSSE signature.
The projection is derived from the sealed bundle.risk_analysis and signed on demand; it is never sealed into the main bundle.
Normative relevance
Section titled “Normative relevance”ISO 14971:2019 (medical device risk analysis: hazard→hazardous situation→harm + benefit-risk); prEN 18228 (source→pathway→consequence); ISO 23894 (ISO 23894 treatment cycle — a parity test verifies that the projected level == residual_overall). The cloud renders the verified artefacts in Annex IV §5.
Example
Section titled “Example”# Project to ISO 14971 (medtech)froga risk-projection --framework iso/14971@2019
# Project to all applicable frameworks with a projection catalogfroga risk-projectionfroga keygen
Section titled “froga keygen”Generates (or reuses) the signer’s local ECDSA-P256 key pair without touching the network: writes the private key to ~/.froga/signing.key (permissions 600) and prints the derived SEC1 public key and its origin (generated, reused, or taken from FROGA_SIGNING_KEY). This is the first-class offline path for air-gapped environments (on-prem CI, manufacturers): signing works with no account and no cloud. Enrolment is an optional later step: froga auth reuses this key if it already exists (it never regenerates it).
| Flag | Type | Default | Description |
|---|---|---|---|
--out | path | ~/.froga/signing.key | Alternative path for the key file to create or reuse. |
What it writes
Section titled “What it writes”~/.froga/signing.key(or--out) — the signer’s private key (permissions600); never transmitted.- On screen: the SEC1 public key in hex (same as
froga pubkey) and where the key lives.
froga auth
Section titled “froga auth”Registers the signer’s local key pair in the cloud: generates (or reuses) the ECDSA-P256 pair at ~/.froga/signing.key (permissions 600) and enrolls only the public key into the given system (ScmConnection). The private key never leaves the machine. This is the step that binds a signer (person or CI) to a system by its role before declaring, approving, or executing.
| Flag | Type | Default | Description |
|---|---|---|---|
--system | string | (required) | ID of the system (ScmConnection) the signer is associated with. |
--url | string | (required) | Cloud base URL, e.g. https://app.venturalitica.ai. |
--role | string | declarant | Signer role: declarant, approver, or executor. |
--label | string | froga-cli | Human-readable signer label, e.g. "Nerea's laptop" or "CI GitHub Actions". |
--code | string | — | Interactive enrollment code (generated in the Seigarrena UI). Excludes --token. |
--token | string | — | CI deploy token (alternative to the interactive code). Excludes --code. |
What it writes
Section titled “What it writes”~/.froga/signing.key— the signer’s private key (permissions600); never transmitted.- Registers the public key in the cloud (
ScmConnection.signerPubkey) with the declared role.
Normative relevance
Section titled “Normative relevance”EU AI Act Art. 12 (attributable record-keeping); separation of duties (four-eyes) via the signer’s role.
Example
Section titled “Example”froga auth --system sys_abc123 --url https://app.venturalitica.ai --role declarant --code 482913froga entitlement sync
Section titled “froga entitlement sync”Requests the system’s signed standards entitlement from the cloud and writes .froga/entitlement.json into the repository. This is what enables the paid standards catalogs (open-core): the engine reads it to know which standards it may project. The cloud never writes to .froga/; froga does, and the user or CI commits the file.
Issuance is gated by the organisation’s plan: requesting a standard the plan does not license answers 403, naming the minimum plan that includes it. Which standard lands in which plan: Plans & standards.
| Flag | Type | Default | Description |
|---|---|---|---|
--system | string | (required) | ID of the system (ScmConnection) in the cloud. |
--url | string | (required) | Cloud base URL, e.g. https://app.venturalitica.ai. |
--token | string | (required) | CI deploy token (FROGA_DEPLOY_TOKEN). |
--repo | path | . | System root directory (contains froga.yaml and .froga/). |
--standards | string | (those in froga.yaml) | Standards to request, comma-separated (e.g. eu/pren-18228@2026,eu/mdr@2017). Omit to use the applicable_standards from froga.yaml. |
What it writes
Section titled “What it writes”.froga/entitlement.json— cloud-signed standards entitlement (the user/CI commits it).
Example
Section titled “Example”froga entitlement sync --system sys_abc123 --url https://app.venturalitica.ai --token "$FROGA_DEPLOY_TOKEN"froga entitlement dev (ephemeral environment, DEV ONLY)
Section titled “froga entitlement dev (ephemeral environment, DEV ONLY)”In a cloud-less environment (demos, local CI) sync isn’t available (it needs --token). froga entitlement dev signs the entitlement LOCALLY with the DEV issuer embedded in the binary (froga_core::verify::dev_issuer_scalar_hex), covering the paid standards declared in froga.yaml’s context.applicable_standards, and writes it to the same .froga/entitlement.json.
It is advisory, NOT valid in production: the DEV issuer’s scalar is public (it lives in the compiled binary). A release binary does not anchor it as a trusted issuer unless FROGA_ISSUER_PUBKEY is explicitly set to its pubkey — something only the ephemeral environment itself does, never production.
froga entitlement dev --repo .froga sign-pliego
Section titled “froga sign-pliego”The contracting authority signs the OSCAL tender (pliego.oscal.yaml) with its local keyring key (ECDSA-P256, the same scheme used to sign evidence). The private key never leaves the contracting authority’s machine. The result is a DSSE/in-toto envelope (<FILE>.sig) verifiable with the authority’s public key: this is what makes the tender binding, so that froga conformance --against-pliego can impose its clauses on the bidder.
| Flag | Type | Default | Description |
|---|---|---|---|
--out | path | <FILE>.sig | Path to write the DSSE envelope. |
What it writes
Section titled “What it writes”<FILE>.sig— the tender’s DSSE/in-toto envelope, verifiable with the authority’s public key.
Normative relevance
Section titled “Normative relevance”EU AI Act Art. 47 (supply chain); public procurement: the signed tender fixes the conformance threshold the bidder must meet.
Example
Section titled “Example”froga sign-pliego pliego.oscal.yamlfroga sign-detached
Section titled “froga sign-detached”Signs any artifact (binary, tarball, wheel…) with ECDSA-P256 and writes the detached signature in DER format. Verifiable with OpenSSL using the engine’s public key in PEM format (froga pubkey --pem).
| Flag | Type | Default | Description |
|---|---|---|---|
--out | path | <FILE>.sig | Path to write the DER signature. |
What it writes
Section titled “What it writes”<FILE>.sig— the artifact’s detached DER signature.
Example
Section titled “Example”froga sign-detached froga-0.1.1-linux-x86_64.tar.gz# Verify the signature:openssl dgst -sha256 -verify <(froga pubkey --pem) \ -signature froga-0.1.1-linux-x86_64.tar.gz.sig \ froga-0.1.1-linux-x86_64.tar.gzAnnex IV is not a subcommand
Section titled “Annex IV is not a subcommand”The Annex IV (EU AI Act Art. 11) is not emitted by the engine. The engine only produces signed evidence: the bundle.json (with per-field provenance) and the .froga/* artifacts. The control plane (the cloud) assembles and renders Annex IV from the signed bundle.json and exports it to PDF (Typst). It is not an engine artifact, it is not committed, and there is no froga annex-iv command.
See The .froga/* artifacts for the artifacts the engine does emit.