How Mipiti Works

Threat models produce controls. Controls get implemented. But the link between a control definition and its implementation is maintained by convention — code review, manual testing, periodic audits. That evidence is point-in-time, self-attested, and decoupled from the codebase. When code changes between audits, nothing mechanically detects that a previously-satisfied control no longer holds. You find out during the next pen test, the next audit, or the next incident.

Mipiti makes that link formal and continuous. It creates a verification pipeline from threat model to codebase that runs on every commit — producing machine-verified, cryptographically attested evidence that your controls are actually implemented, right now, at this commit.

The three-party architecture

The system separates concerns across three independent parties. This separation is not incidental — it's what makes the evidence trustworthy.

The agent implements controls and submits evidence — but evidence from the same party that wrote the code is self-attestation. CI independently verifies those claims against the codebase. The platform evaluates the verified results into an assurance posture. The party that makes the claim is never the party that confirms it.

Five steps, two loops

Step 1 — Describe your feature

You describe what you're building in plain language: "A REST API with JWT authentication, file uploads to S3, and pre-signed download URLs." This can happen in the chat UI, from a Jira issue, or through an AI coding agent via MCP.

Step 2 — Derive threat model and controls

The platform generates a structured threat model:

• Assets — data and components that need protection, each tagged with security properties (Confidentiality, Integrity, Availability, and Usage for non-extractable assets)
• Attackers — capability-defined threat actors described by position and concrete abilities, not vague personas
• Control Objectives — computed as a deterministic cross-product of assets and attackers. Every asset-attacker pair produces one "SHALL" statement. This is not LLM-generated — it's a mathematical guarantee of complete coverage
• Controls — concrete, actionable security measures mapped to control objectives

The methodology is grounded in the Common Criteria Security Problem Definition (ISO 15408) — capability-defined attackers mapped to assets through formal threat definitions — NIST SP 800-30/RMF (traceable control derivation), and HAZOP (systematic hazard analysis). AI handles creative threat identification. The cross-product handles completeness.

Step 3 — Implement and supply evidence

Your AI coding agent (Claude Code, Cursor, or any MCP-capable tool) implements the controls and submits typed assertions as evidence. An assertion is a machine-verifiable claim about a code property:

• function_exists — "auth/middleware.py contains a function called require_auth"
• test_passes — "tests matching test_rate_limit pass"
• config_value_matches — "HSTS max-age is at least 31536000"
• pattern_absent — "no hardcoded secrets matching the pattern API_KEY=..."
• http_header_set — "X-Content-Type-Options: nosniff is set in responses"

There are 21 assertion types in total. Each is a structured claim — not prose, not a screenshot, not a link to a file. The agent submits assertions through the MCP server; the platform stores them and maps them to controls.

Step 4 — Deterministic verification

Your CI pipeline runs mipiti-verify, an open-source CLI that verifies assertions against the actual codebase. A single mipiti-verify run --all command verifies every threat model in the workspace — the API key determines which workspace, so CI configuration is one key and one command.

Verification has two tiers:

Tier 1 — Mechanical. Deterministic, instant, near-zero cost. AST parsing to verify functions exist, test runner execution, regex matching, config file parsing. No AI involved. Catches structural falsehoods — "this function doesn't exist."

Tier 2 — Semantic. AI-assisted, runs after evidence is marked complete. Targeted prompts evaluate whether a function actually implements what the control requires, not just that it exists. Catches semantic falsehoods — "the function exists but it's a no-op stub." Runs inside your CI using your own AI provider (OpenAI, Anthropic, or Ollama).

After both tiers pass, a collective sufficiency check evaluates whether all assertions for a control together constitute sufficient proof. This prevents evidence gaps — "you proved authentication exists but didn't address session timeout."

Results are signed with your CI's private key (ECDSA P-256 or OIDC attestation) and submitted to the platform. The signature is permanently stored alongside the verification result, creating an audit trail that anyone can independently verify.

Step 5 — Attested assurance

The platform evaluates verification results into an assurance posture:

• Mitigated — at least one mitigation group fully implemented and verified
• At Risk — no mitigation group fully implemented
• Unassessed — no controls mapped yet

This evaluation is deterministic — no LLM opinions. Each control objective's risk tier is computed from the asset's impact and the attacker's likelihood (a 3x3 matrix producing Critical, High, Medium, and Low). The posture is auditable, versioned, and exportable.

The CI loop — every commit

Steps 4 and 5 repeat on every commit. When a code change invalidates a previously-passing assertion, the platform detects control drift — a security control that was verified yesterday but no longer holds today. Drift is tied to specific controls and control objectives, so remediation is targeted.

This is the mechanical heartbeat of the system. No human action required. Every push triggers verification, and the assurance posture updates automatically.

The development loop — gaps and drift

When verification reveals gaps — controls that aren't implemented, assertions that fail, or drift from previous state — the feedback flows back to step 2. The AI coding agent can:

• Submit negative findings to flag missing implementations
• Refine the threat model based on what was discovered during implementation
• Derive new controls for attack surfaces that weren't visible at design time
• Implement the missing controls and submit new assertions

Findings follow a lifecycle: discovered, acknowledged, remediated, verified. When a remediated finding has linked assertions and those assertions pass verification, the finding is automatically marked as verified.

This loop is where the model evolves. The initial threat model is a starting point. Real security posture emerges from the interplay between implementation, verification, and refinement.

Why this architecture

Why not just have the platform read the code? Because that creates custody risk. Your threat models contain your security architecture. Your source code contains your implementation. Combining both in one place makes that place a high-value target. Separation of concerns isn't just good engineering — it's a security property of the system itself.

Why typed assertions instead of free-text evidence? Because "see auth.py line 45" is not machine-verifiable. Typed assertions have a defined verification procedure. They can be checked mechanically, repeatedly, on every commit, without human judgment.

Why two tiers of verification? Because mechanical checks are necessary but not sufficient. A function can exist without doing anything meaningful. Tier 1 catches lies. Tier 2 catches deception. Together they approximate what a security reviewer does when reading code — but they do it on every commit, not once a quarter.

Why sign the results? Because verification results without provenance are just more self-attestation. The ECDSA signature proves that a specific CI run, at a specific commit, produced a specific result. An auditor can verify the signature independently without trusting the platform.