Export

Export your threat models for sharing, review, or compliance documentation.

Formats

How to export

1. Go to the Models page or Assurance Dashboard
2. Select a model
3. Click Report (HTML), PDF, CSV, or Audit archive

The Report and PDF formats include the enriched report: trust boundaries, assets, attackers, control objectives, implementation controls with traffic-light status, assurance summary, risk tier breakdown, verification status, and compliance coverage (if a framework is selected). Cross-model attestation data (assumptions linked to other models in a system) is stripped from model exports — those attestations are deployment-specific. Manual attestations are preserved.

The CSV format includes the raw model structure: trust boundaries, assets (with security properties), attackers, control objectives, and assumptions.

Audit archive (JSON)

The audit archive is a self-contained JSON envelope carrying the complete evidence chain an auditor needs to re-verify every "verified implemented" claim — without needing access to the origin Mipiti instance.

What it contains:

• Every version of the threat model (with timestamps and change history)
• Controls with their current implementation status
• Assertions with their full content, Tier 1 and Tier 2 verification verdicts, attested flags, and the CI-side attestation that signed the submission (Sigstore bundle for OIDC-capable CIs; workspace ECDSA signature for non-OIDC CIs)
• Findings (gap discovery) with their lifecycle history
• Risk acceptances
• Assumption overrides and attestation history
• Instance sufficiency signatures per control (ECDSA P-256 over the canonical verdict + a content hash of every assertion that fed the decision)

Independently verifiable:

• CI Sigstore bundles verify against Sigstore's public Fulcio root + Rekor transparency log — no dependency on the origin instance, and the Rekor inclusion proof is portable for years.
• Workspace ECDSA submission signatures verify against the origin workspace's published public key.
• Instance sufficiency signatures verify against the origin instance's public ECDSA key, which the target instance imports via the Admin Panel's Trusted Signers section.

Tampering with any signed field — flipping a Tier 1/Tier 2 verdict, mutating an assertion's parameters, adding or removing assertions after signing — invalidates the relevant signature on verify.

Importing an archive

Another Mipiti instance (or the same one) can restore the archive via the Import audit archive button on the Models page. A fresh model_id is assigned on every import, so the same envelope can be imported any number of times. Title collisions in the target workspace auto-suffix (imported YYYY-MM-DD) — you can rename afterwards.

Via MCP, use export_threat_model_archive / import_threat_model_archive.

Viewing and verifying a sufficiency signature

On the Assurance tab, any control with an evaluated sufficiency verdict shows a small padlock next to its status badge. Click it to open the signature modal, which shows:

• The signed payload (verdict, reasoning, evaluated timestamp, sufficiency model)
• The signer fingerprint and the assertions content hash
• The raw base64 signature and the signer's public key (PEM)
• A Verify signature button that re-checks the signature server-side
• Copy bundle for offline verification with openssl or the cryptography Python library

System export

For a system-level report that includes cross-model dependencies and attestation status, use the system export from the Systems page. This is the auditor artifact — it shows the full composition including which assumptions are satisfied by which controls across models.

Jira export

For Jira integration, use the dedicated "Export to Jira" button instead. This creates structured Jira issues rather than a flat document export. Each Jira issue includes mitigation group information in the description to show which controls are alternatives and which are defense-in-depth. See the Integrations section for details.