add_component
Add a component to a threat model.
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 either speculative (your own
code, not linked to a repo yet) or external (e.g. a third-party
service, the customer's IdP, or other external infrastructure you
call but don't own).
The component's trust boundary tells them apart: bind an
internal-zone component to its repo via edit_component; leave an
external-zone component unbound — its component_unbound finding
is a permanent external-dependency marker, not a gap to close.
Binding by "some client code touches it" is wrong: client code for
external dependencies lives in your repo too.
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 | |||