assign_asset_to_components
Links a security asset to one or more components, establishing code-ownership and trust boundary context for reachability analysis. Validates that all referenced components exist on the current model.
Instructions
Replace an asset's component scope.
Mirror of assign_control_to_components for assets. Components
are the canonical bridge between security architecture (trust
boundaries) and code organization (repos). Linking assets to
components flows boundary context into reachability derivation
without giving Asset its own trust_boundary_ids.
An asset's component scope can be:
Unscoped (empty string): no explicit code-ownership binding. Reach decisions fall back to LLM judgment of the asset's description / security properties.
Single-component: standard case for assets handled by one deployable unit.
Multi-component: a multi-instance asset that flows through several components (e.g., a session token on client + cache
DB — each component handles a distinct instance).
Mechanical, non-AI-gated. Validates only that every referenced component exists on the model.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| asset_id | Yes | ID of the asset to scope (e.g., "A1"). | |
| model_id | Yes | ID of the threat model. | |
| change_reason | Yes | Why this scope is appropriate (min 10 chars). Captured in the model's version history. | |
| component_ids | Yes | Comma-separated component IDs (e.g., "CMP1,CMP2"). Empty string = unscoped. | |
| server_version | Yes |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||