Discovery and Assurance

Mipiti operates in two distinct reasoning modes over the same data.

Discovery Mode

Discovery is the AI-exploratory phase. When you generate or refine a threat model, you are in Discovery mode.

• The agentic pipeline uses LLM reasoning to identify assets, attackers, and trust boundaries
• Output is heuristic — comprehensive but not formally verified
• Results are marked with a "Discovery" badge

Discovery gives you a comprehensive starting point in minutes instead of days.

Note: Direct entity edits (add/edit/remove via UI buttons) are not Discovery operations — they are deterministic, create new versions, and preserve existing control mappings. See Working with Models for details.

Assurance Mode

Assurance is the evidence-bound, deterministic phase. It appears on the Assurance page.

• No LLM is involved — pure deterministic evaluation
• Maps implementation controls to control objectives
• Each control objective gets a status:
  • Mitigated by controls — at least one mitigation group is fully implemented
  • Mitigated by assumption — no controls group is complete, but an active, attested assumption covers this CO
  • At Risk — no mitigation group is complete and no active attested assumption covers the CO
  • Unassessed — no controls have been mapped yet
• At-risk and unassessed COs carry a risk reason explaining the required action:
  • Missing controls — controls exist but are not fully implemented
  • Pending attestation — a boundary assumption covers this CO but has never been attested
  • Attestation expired — a boundary assumption previously covered this CO but its attestation has lapsed
• COs are grouped by risk tier (Critical / High / Medium / Low) in the assurance report, so you can prioritize the highest-risk gaps first
• Active, attested assumptions can mitigate COs entirely (when linked and attested); violated/retired assumptions are annotated on affected COs as informational context
• Negative findings flag controls where AI coding agents found missing or incomplete implementations in your codebase
• Produces an auditable compliance posture — for framework-level compliance (OWASP ASVS, etc.), see the Compliance module

Control Alternatives and Defense-in-Depth

Controls generated for a control objective are organized into mitigation groups — alternative paths to satisfy the same CO.

How mitigation groups work

• Within a group (AND): all controls in the group must be implemented together
• Across groups (OR): completing any one group fully mitigates the CO
• No group (defense-in-depth): the control strengthens security but is not required for mitigation

For example, a CO protecting data confidentiality might have:

Implementing either Group 1 (CTRL-01 AND CTRL-02) or Group 2 (CTRL-03) mitigates the CO. CTRL-04 is always defense-in-depth.

Defense-in-depth is computed, not stored

When a CO is mitigated via one group, controls in other incomplete groups automatically become defense-in-depth. This status is dynamically calculated based on current implementation state — it is not a fixed label.

Legacy behavior

Models generated before mitigation groups were introduced have all controls with no group assignment. In this case, the system uses legacy behavior: all controls must be implemented for the CO to be mitigated.

Managing groups

The LLM assigns mitigation groups during control generation. You can manually adjust group assignments in the Assurance page using the group override API.

Control Refinement

AI-generated controls are intentionally prescriptive — they specify exact mechanisms (e.g., "use Argon2id with 64 MiB memory cost"). Sometimes the prescribed mechanism doesn't match the implementation (e.g., you use bcrypt, or SameSite=Lax instead of Strict because OAuth requires it).

Control refinement lets you propose a new description with a justification. The platform evaluates whether the mitigation group still collectively satisfies all mapped control objectives after the change:

1. Propose a new description and justification via refine_control (MCP) or the REST API
2. The AI evaluator checks each mapped CO — does the group of controls still provide coverage?
3. If accepted, the control is updated. The original description, justification, and AI assessment are preserved as an audit trail
4. If rejected, the response includes per-CO reasoning explaining which objectives would lose coverage — use this to adjust and retry

Key properties

• Controls should be prescriptive — the problem is wrong prescriptions, not deviations from prescriptions. Refinement corrects the prescription, it doesn't weaken it.
• Group evaluation, not individual — a control doesn't satisfy an objective alone. The evaluator checks whether all controls in the mitigation group together still cover the COs.
• Fail-closed — invalid AI responses, missing fields, or malformed JSON default to rejection.
• Audit trail — original description is preserved on first refinement and never overwritten by subsequent refinements.

Why two modes?

Many tools use AI for everything, including risk evaluation. This means their risk assessments can hallucinate.

Mipiti uses AI where it adds value (creative threat identification) and determinism where correctness matters (coverage evaluation). Auditors can trust the assurance posture because it is not an LLM opinion — it is a mathematical cross-product.

Trust Boundaries and Assumptions

Trust Boundaries

A trust boundary is an architectural boundary where trust transitions occur — for example, "Public internet to API gateway" or "Application server to third-party payment processor." Trust boundaries define which security properties are your responsibility to implement vs. which you must assume about the environment.

Trust boundaries are first-class structural entities. You can add, edit, or remove them via the Overview page or MCP tools (add_trust_boundary, edit_trust_boundary, remove_trust_boundary). Each change creates a new model version with full carry-forward.

What trust boundaries do:

• Attackers are positioned at specific boundaries (trust_boundary_ids on the attacker) — making explicit which attacker can reach which asset
• COs for asset/attacker pairs that cannot reach each other across any boundary are annotated as boundary-unreachable — providing visibility without filtering (the full cross-product is always preserved)
• When a new trust boundary is added, Mipiti auto-generates a boundary assumption covering any unreachable COs, giving you an immediate starting point for attestation
• Boundary context flows through to the assessment report: boundary-excluded COs display an Outside boundary badge and carry a risk reason (Pending Attestation or Attestation Expired) that tells you the required action — submit or renew the linked boundary assumption rather than implement controls

Assumptions

An assumption represents a documented security property that is tracked through attestation rather than proven through code assertions. Typically, assumptions cover properties outside your trust boundary — security obligations upheld by an external party (customer, vendor, operator) that you cannot implement yourself. They can also represent internal environmental properties (infrastructure configuration, operational procedures) that you track through attestation rather than code-level proof.

Examples:

• "Customer restricts CI runner egress to allowlisted domains"
• "Payment processor maintains PCI DSS certification"
• "Deployment infrastructure enforces network segmentation"

Assumptions are managed on the Assumptions page (add, edit, soft-delete, restore).

CO-Level Mitigation

An assumption can be linked to one or more COs it covers. When linked and attested with a current (non-expired) attestation, the assumption mitigates those COs in the assessment — they show as mitigated_by: assumption rather than at_risk.

This is the correct model for COs where no positioned attacker can reach the asset across any trust boundary: instead of leaving them permanently at_risk (misleading) or fabricating unimplementable controls (wrong), you record the responsible party's obligation and track their attestation.

Control-Level Assumed-By

Some COs span a trust boundary — part is your responsibility, part is external. For these, individual controls within the CO can be marked as externally handled using assumed by (assume_control MCP tool or the Assurance page). A control with assumed_by pointing to an active, attested assumption counts as active for mitigation group completeness — without being marked as implemented by you.

This correctly handles the case where a CO like "Protect session tokens from MITM" requires both TLS enforcement (yours — a control) and TLS termination configuration (vendor's — assumed).

Attestation

An attestation is a timestamped record that the responsible party affirmed an assumption holds:

Mipiti does not verify attestations — it records them, tracks expiry, and flags gaps. The auditor verifies, same as SOC 2 CUECs (Complementary User Entity Controls).

When an attestation expires, affected COs revert to at_risk until re-attested or covered by controls.

Assumption Lifecycle

Violation Workflow

When an assumption is violated or its attestation expires, affected COs become at_risk. Four remediation paths:

1. Re-attest — submit a new attestation with updated expiry (submit_attestation MCP tool or the Assumptions tab on the model detail page)
2. Restore — if the assumption was soft-deleted and is still valid, restore it and re-attest
3. Convert to controls — generate controls for the affected COs and retire the assumption linkage (convert_assumption_to_controls MCP tool). For control-level assumptions, assumed_by is cleared and the control reverts to not_implemented. For CO-level assumptions, the LLM generates replacement controls.
4. Accept risk — formally document that the risk is accepted (see Risk Acceptance)

Risk Acceptance

Some control objectives may remain at risk by deliberate choice — the cost of mitigation outweighs the risk, or the risk is accepted temporarily while controls are being implemented.

Risk acceptance is distinct from assumption-based mitigation:

• Assumption — the risk is handled by an external party who you trust to implement it
• Risk acceptance — the risk is known, unmitigated, and you are formally documenting that decision

Risk acceptance is a formal, human-owned decision made through the Assurance page:

1. Navigate to the Assurance page and run an assessment
2. In the assessment report, find an at-risk CO and click Accept Risk
3. Fill in:
   • Owner — the person or team accountable for this risk going forward
   • Justification — why the risk is being accepted (required)
   • Review by — a future date when the acceptance must be re-evaluated (required, must be in the future)
4. The CO remains at_risk in the assessment but is annotated with the acceptance record

Key properties

• Human-only — risk acceptance is never automated. AI agents cannot accept risk on your behalf.
• Revocable — an active acceptance can be revoked at any time, returning the CO to its unaccepted at-risk state.
• Expirable — when the review date passes, the acceptance is marked as expired and surfaces for re-evaluation.
• Auditable — every acceptance records who accepted, when, and why.
• Informational only — risk acceptance does not change the assessment result. A CO with accepted risk is still at_risk. The acceptance explains why the risk is tolerated and when it must be reconsidered.