Skip to content

Playbooks

Common end-to-end tasks you can run through Devici MCP. Each playbook is a short narrative, the tool sequence the agent will follow, and a copy-pasteable prompt you can give your AI client.

These playbooks assume you've completed the Quickstart and the API token you're using has scopes that cover creating and updating content in the relevant collections.

Permissions come from the token's scopes

Devici MCP doesn't have its own tokens or scopes — it uses the same API tokens you'd issue for direct Devici Standard API access. Each token has the scopes you set at creation, and the Standard API enforces those scopes per tool call. If a playbook step needs a scope your token doesn't have, the call fails with 403 Insufficient scope. See Authentication.

Build a threat model from a description

Hand the agent a plain-language description of your system. The agent builds the diagram, identifies threats, and attaches mitigations from the codex.

Tools used: collection_search → threat_model_import_otm → codex_browse → codex_assign_bulk

Prompt:

"Build a threat model in Devici for an online store. The system has:

  • A customer browser
  • A React frontend
  • A Node.js API
  • A Postgres database
  • Stripe for payment processing

Customer browser talks to the frontend over HTTPS. Frontend calls the API over REST. API reads and writes Postgres. API sends payment data to Stripe.

Put the model in the Online Store collection. Run a STRIDE framework codex pass on the model."

What you'll get back:

A new threat model in your Online Store collection with:

  • A rendered canvas showing all five components, dataflows, and trust boundaries
  • STRIDE-categorized threats attached to the right components
  • Codex-sourced mitigations attached to each threat
  • A link you can open in the Devici web app

Build a threat model from a product design document

Drop a product requirements document, design doc, RFC, or architecture spec onto the agent. The agent extracts the architecture from the document, builds the model, and reports back what it could and could not map.

Tools used: collection_search → threat_model_import_otm → codex_browse → codex_assign_bulk → threat_model_validate

Prompt:

"Read the design document at ~/Documents/payments-platform-design.md. Extract the architecture (components, dataflows, trust boundaries, third-party integrations) and build a threat model in Devici in the Payments collection that mirrors it. Run a STRIDE framework codex pass on the model, and at the end tell me anything in the document you could not map onto the model so I can decide whether to extend it."

What you'll get back:

  • A threat model named after the document's topic, in the collection you specified
  • A rendered canvas with the components, dataflows, and trust boundaries the agent extracted from the architecture sections
  • STRIDE threats attached to each component, driven by the codex attributes the agent picked, with each threat's default codex mitigations alongside
  • A validation report at the end calling out anything still missing
  • A summary of what the agent extracted and what it could not map (for example: a future service mentioned but not yet built, or an SSO provider the document references but does not specify)

What makes this work well

The agent does best when the document has an explicit Architecture or System Design section, names components clearly, and describes the data flows between them. If the doc is mostly product positioning or feature requirements with no architectural detail, the agent will model what it can and flag what it could not.

Supported document formats

The agent reads whatever the AI client can open: Markdown, plain text, PDF, Word, Confluence exports, README files in a repo. Format matters less than how clearly the architecture is described in prose, in tables, or in embedded diagrams the AI client can interpret.

Import an existing OTM file

You already have an OTM file (from another tool, an export, or a hand-authored draft) and want it in Devici.

Tools used: collection_search → threat_model_import_otm

Prompt:

"Import the OTM file at ~/Downloads/payments-platform.otm.json into the Payments collection in Devici."

The agent finds the collection (or creates it if it doesn't exist), reads the file, and runs the import.

Convert a draw.io diagram into a Devici threat model

You have a .drawio architecture diagram and want it as a real threat model.

Tools used: collection_search → threat_model_import_otm → codex_assign_bulk

Prompt:

"Take the draw.io file at ~/Documents/payments-architecture.drawio, convert it into a Devici threat model in the Payments collection, and run a STRIDE framework codex pass on the model."

The agent reads the draw.io XML, maps shapes to Devici node types (process, external entity, datastore, trust boundary), preserves the visual layout, imports it, and then attaches codex content for STRIDE.

Run a STRIDE pass on an existing threat model

You already have a model in Devici and want to enumerate threats systematically.

Tools used: threat_model_content_snapshot → codex_browse → codex_assign_bulk → threat_model_validate

Prompt:

"Take the threat model Online Store, Core Architecture in the Online Store collection. Run a STRIDE pass over every component using the codex. Then validate the model and list any gaps."

What you'll get back:

  • A snapshot of what was already on the model (so the agent doesn't duplicate)
  • New attributes on each component, picked to match what each component IS, DOES, or HANDLES
  • STRIDE threats attached to each component, derived from those attributes through the codex
  • Codex default mitigations attached to each threat (whatever the codex defines as the threat's default set — no top-N truncation, no padding)
  • A validation report at the end listing anything still missing

Methodology framing

"Methodology" and "framework" are interchangeable — use either word. To frame a model, ask the agent for one (STRIDE, LINDDUN, MAESTRO, any framework in your codex) or several at once (e.g. "STRIDE + LINDDUN"). The methodology is stored as a setting on the model itself, so the framing persists across passes; the agent updates it on your behalf when you specify one. See How do I limit threats to a specific methodology? for the details.

Update a threat model after architecture changes

The system changed: a new service, a different auth model, a new datastore. You want the threat model to reflect reality.

Tools used: threat_model_content_snapshot → threat_model_update → codex_assign_bulk

Prompt:

"In the Online Store, Core Architecture model, the team added a new service called Inventory Service between the API and Postgres. It runs on the same VPC as the API, talks to the API over gRPC, and reads and writes Postgres. Add it to the model, draw the right dataflows, and run a STRIDE pass on the new component."

The agent updates the existing model rather than creating a new one, keeping audit history intact. Snapshotting first means the new STRIDE pass only adds content for the new service, not duplicate content on the components that were already covered.

Browse and assign codex content explicitly

When you want to control exactly which codex items get attached, for instance when modeling against a custom organization framework.

Tools used: threat_model_content_snapshot → codex_browse → codex_assign_to_component (or codex_assign_to_threat)

Prompt:

"In the Mobile App model, find the Authentication Service component. Browse the custom codex for our company's "OWASP MASVS" framework. Attach all attributes that apply to a mobile authentication service. The codex will surface the resulting threats with their default mitigations — report any coverage gaps so I can decide what to add."

The agent snapshots the model first to see what's already attached to the component, walks through the codex catalog, picks attributes that match what the component IS, DOES, or HANDLES, and applies only what's not already there. Built-in and custom-codex attributes bring the threats they're linked to in the codex (and each threat's default mitigations) along automatically, so you usually only need the attribute step.

Inspect what's on a model

You want a clear picture of what's currently attached to a model: which components have which attributes, threats, and mitigations, and how the framework distribution looks.

Tools used: threat_model_content_snapshot

Prompt:

"Take the Online Store, Core Architecture model. Tell me what attributes, threats, and mitigations are currently attached. Group by component, then show me the top five most common threats and which components they appear on."

A read-only flow with a single tool call. Useful for:

  • A status check before sharing a model in review
  • A planning step before adding new codex content (lets the agent diff against the current state and only add what's missing)
  • Producing a quick framework-distribution report (use flat: true to dedupe by title across the whole model)

Generate a summary or report

You want a digestible view of a model for a review, a report, or a stand-up.

Tools used: threat_model_export (with export_format=summary) → dashboard_report

Prompt:

"Give me a summary of the Payments Platform threat model: how many components, threats, and mitigations, what's not yet mitigated, and what got changed in the last 30 days."

The agent exports a summary, pulls dashboard analytics for the date range, and writes back a clean report you can paste into a doc.

Validate before a review

Run a completeness check before sharing a model with a reviewer.

Tools used: threat_model_validate

Prompt:

"Validate the Online Store, Core Architecture model. List any components without threats, threats without mitigations, or orphaned entities. Flag real misses (components the codex pass skipped) separately from codex coverage gaps (threats with no default mitigations)."

The validator returns a structured list. The agent will pick out anything blocker-level and surface it to you.

Bulk operations across a large model

For models with hundreds of components, the bulk codex tool keeps tool-call counts manageable.

Tools used: threat_model_content_snapshot → codex_browse (catalog) → codex_assign_bulk

Prompt:

"Take the Cloud Platform model. For every component without attributes, pick the right codex attributes (the ones that fit what each component IS, DOES, or HANDLES) and apply them in bulk."

The agent inspects the model, fetches the codex catalog once, and submits one or more codex_assign_bulk calls (each capped at 20 ops by the API) until every component is covered.

See also