add_component
Add a component to a threat model to map trust boundaries to repositories, enabling scoped security controls and reachability analysis.
Instructions
Add a component to a threat model.
Components bridge security architecture to code organization. They
map trust boundaries to repos so controls can be scoped to the
codebase that implements them. They also drive the deterministic
reachability composer's asset-boundary derivation: an asset's
trust-boundary footprint is the union of its components'
trust_boundary_ids.
A component with empty repo_url is speculative — a topology
waypoint that hasn't been bound to code yet. The coherence report
surfaces these as component_unbound findings. Speculative
components are valid in the lifecycle (LLM-proposed during
generation, or operator-added during planning); ground them via
edit_component once the code exists.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Component name (e.g., "Backend API", "Auth Worker"). | |
| path | No | Path within repo for monorepos (e.g., "services/auth"). | |
| model_id | Yes | ID of the threat model. | |
| repo_url | No | Repository URL (e.g., "github.com/org/backend"). Empty string is valid for speculative components — pass a real URL once you've identified the codebase. | |
| server_version | Yes | ||
| trust_boundary_ids | No | Comma-separated trust boundary IDs that this component spans (its deployment zone). Drives reach decisions for any asset scoped to this component. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||