Systems

What is a system?

A system is a lightweight grouping of related threat models within a workspace. If you have 50 feature-level threat models for a single product, a system lets you organize them together.

A threat model can belong to at most one system. Models that aren't added to any system remain standalone.

Creating a system

1. Navigate to Systems in the sidebar
2. Click Create System
3. Enter a name and optional description
4. Optionally select models to add immediately

Adding models to a system

On the system detail page, click Add Model to see a list of unaffiliated models in the current workspace. Select a model to add it.

If a model already belongs to another system, you must remove it from that system first.

Removing models

Click the remove button on any model card in the system detail view. The model becomes unaffiliated — it is not deleted, just removed from the system.

Deleting a system

Deleting a system removes the grouping only. All member models become unaffiliated and are not deleted.

Tags

A tag is a lightweight, overlapping label for grouping models — audit scopes, ad-hoc selections, portfolios. Unlike a system (where a model belongs to at most one), a model can carry many tags, and tags can overlap freely. A tag is purely organizational: it has no effect on a model's security posture or on how controls are credited.

Manage a model's tags from the Overview tab of its detail page: remove a tag, attach an existing one, or create-and-attach a new one inline.

Tag risk view

A tag's risk view aggregates the per-control-objective risk across every model the tag contains — the same idea as the system risk view, but over a set you compose freely. It is delegation-aware: an objective that is mitigated via a cross-model delegation reads as covered here, consistent with the model's own assessment.

Tag as a compliance / audit scope

A tag can also serve as a compliance scope spanning several models — select frameworks for the tag (propagated to its members), get a cross-model compliance coverage report, and produce a signed auditor report that aggregates every member model's report plus the cross-model dependency graph and attestation status. These are the same capabilities a system offers, now available over any tag.

Tags vs. systems. Both group models. A system is a single-membership container; a tag is overlapping and flexible, and now covers everything a system does — grouping, the aggregate risk view, compliance scoping, and the auditor export — plus delegation (below) for cross-model control reliance. Going forward, prefer tags for grouping and audit/compliance scopes, and delegation for cross-model reliance. Systems remain fully supported; their cross-model dependency mechanism (next section) is being superseded by delegation.

Cross-model dependencies

Being superseded by delegation. The assumption-linking mechanism in this section predates the foundations and delegation model. For a model that relies on a shared service's control, prefer declaring a delegation — it validates that the provider's control actually satisfies your objective, credits only verified controls, and re-checks automatically when the provider changes. Assumption-linking remains available for existing systems.

When models in a system have external assumptions about each other, those assumptions can be linked to the model that should satisfy them.

For example, if your API's threat model assumes "the database encrypts data at rest," and your database service has its own threat model with a control for encryption — you can link the assumption to the database model. The platform will:

1. Create a compliance requirement on the target model
2. Track whether mapped controls in the target model satisfy the requirement
3. Auto-attest the assumption when satisfied

View cross-model dependencies in the Dependencies tab of the system detail page.

Linking an assumption

In the Assumptions tab of a model, use the Link to model action on an external assumption to select the target model in the same system. The assumption becomes a cross-model dependency.

How satisfaction works

Cross-model assumptions have two independent satisfaction paths:

1. Auto-attestation from controls — when assessing a model, the platform checks directly whether the target model's mapped controls are all implemented. When they are, the dependency is satisfied and the source model's control objectives are automatically mitigated. No manual attestation needed.
2. Manual attestation — you can also manually attest the assumption (e.g., while controls in the target model are still being implemented).

Either path alone suffices. If the auto-attestation check fails but a valid manual attestation exists, the assumption is still satisfied. If the link is later removed, the manual attestation continues to apply.

This is always accurate — satisfaction via controls is evaluated inline from the current state of the target model's controls, not from cached attestation records. Consistent with how CI attestation staleness is checked inline from assertion results.

Foundations and delegation

When a model is built on top of shared services — an auth service, a logging platform, a shared datastore — you don't want to re-prove the same controls in every model that uses them. Delegation lets a model rely on a control that is implemented and proven in another model.

This is distinct from the composition tree (which is about containment — a model being a sub-part of a parent). Delegation is about reliance: independent models that depend on each other's controls. A product can delegate different objectives to several different foundations (auth to one, logging to another) without absorbing those foundations' threat models.

Manage delegations from the Dependencies tab of a model's detail page.

Declaring a foundation

On a shared-service model, mark it as a foundation and choose which of its controls it advertises as providable. A foundation only ever advertises controls (a proven mechanism), never bare objectives — so anything delegated to it terminates at a real, verifiable control.

Two kinds of dependency

• Delegated — your model does not implement an objective itself; the foundation handles it entirely. The objective is credited via the foundation's control.
• Relied upon — your model has its own control, but that control's validity is contingent on the foundation's control. Your model keeps its obligation; the dependency is recorded as a contingency.

In both cases the credit terminates at the foundation's verified control — a delegated objective shows as Mitigated only while the provider's control stays verified.

Attaching a foundation

The fastest path: open the Dependencies tab, pick a foundation, and let the platform propose which of your objectives each advertised capability covers. Review the proposed matches, select the ones that fit, and create them in one step. Each proposed delegation is created as a draft.

You can also declare a single dependency directly.

Validation before credit

A declared dependency does not grant credit immediately. The platform runs an LLM semantic check asking whether the foundation's control genuinely satisfies your objective — fully, partially, or not at all. A dependency carries credit only after that check passes and you confirm it. A partial match is never silently treated as full coverage, and the platform won't quietly change a "delegated" dependency into a "relied upon" one — it surfaces the recommendation for you to decide.

Keeping dependencies honest

Dependencies are re-checked as the foundation changes:

• If the foundation's control regresses or is removed, every dependency on it breaks and a finding is raised on the relying model so the lost coverage is visible.
• If the foundation's control is reworded or reworked, the dependency is automatically re-validated against the new mechanism and broken if it no longer holds.

Each foundation also shows who relies on it (in the Dependencies tab), so before you change a shared control you can see the blast radius across the models that depend on it.

Same-workspace only

A model can only delegate to foundations in the same workspace. Delegation never reaches across workspace boundaries — a control's proof lives within its own workspace, and credit must rest on a proof you can actually inspect.

MCP tools

• declare_foundation — advertise a model's controls as providable.
• create_reliance / confirm_reliance / delete_reliance — declare, confirm, and remove dependencies.
• propose_attach_foundation / attach_foundation — propose and bulk-create delegations.
• list_reliance — a model's dependencies plus who relies on it.

Components

A component is a deployable unit that bridges security architecture to code organization. It maps trust boundaries (where attackers can reach) to repos (where the code lives).

Why components?

A threat model may describe a feature that spans multiple codebases — a backend API, a frontend app, a worker service. Without components, all controls appear in one flat list. With components, each control is scoped to the codebase that implements it.

Adding components

In the model detail page, add components with:

• Name — e.g., "Backend API", "Auth Worker"
• Repo URL — e.g., github.com/org/backend
• Path — for monorepos, e.g., services/auth (optional)
• Trust boundaries — which trust boundaries this component operates within

How scoping works

Controls with a component_id are scoped to that component. When a coding agent works in a repo, it matches the git remote URL to a component's repo_url and sees only the controls relevant to its codebase. Unscoped controls (no component) are visible to all.

MCP tools

• add_component / edit_component / remove_component — manage components
• get_controls with component_id — filter controls by component

Sharing threat models

To share a threat model publicly (e.g., for an open-source component), export it from the model detail page. The export includes model structure, controls with implementation status, and assumptions as conditions. Cross-model attestation data (assumptions linked to other models) is stripped since it's deployment-specific. Manual attestations are preserved.

For auditors who need the full picture including cross-model dependency satisfaction, use the system export from the system detail page. This produces a comprehensive report showing all models, the cross-model dependency graph, and attestation status.

MCP tools

Systems are available via MCP:

• list_systems — list all systems in the workspace
• get_system — get a system with model summaries
• create_system — create a new system
• add_model_to_system — add a model to a system
• get_system_dependencies — view cross-model dependency graph
• link_dependency — link an assumption to a target model