Generate an architecture from your codebase

A use case’s architecture model is what threat modeling and the architecture compliance checks run on. An agent on the Keldyn MCP server can infer it from the repo: technical assets, data assets, trust boundaries, shared runtimes, communication links. Then it saves the model and analyzes it. You stay in the editor.

The generate-architecture prompt models your system from the code and config it can inspect, not from a questionnaire. Run the agent from the repository you want to model so it can read your source.

What you’ll use

Piece	Type	Role
`generate-architecture`	Prompt	Briefs the agent to infer a Threagile model from the codebase (or a scope) and save it.
`update-use-case-architecture`	Tool	Validates the model against the Threagile schema and saves it to a use case.
`analyze-use-case-architecture`	Tool	Runs Threagile security analysis + RCM compliance checks and returns fixable issues.
`keldyn://threagile-schema`	Resource	The authoritative schema for allowed properties and enum values.

Before you start

Connect the MCP server

Follow Keldyn MCP server to connect your AI tool and sign in to the team that owns the target use case.

Open the repository

Start the agent from the repo (or monorepo) you want to model, so it can list and read your files.

Have a use case ready

Know which use case the architecture belongs to. If you don’t pass one, the agent will list your use cases and ask you to choose before saving.

1. Generate the model

Invoke the generate-architecture prompt. It accepts three optional arguments:

Argument	Purpose
`useCaseId`	The use case to save to. Omit it and the agent runs `list-use-cases` and asks you which one.
`scope`	A path, glob, or monorepo package to base the model on (e.g. `apps/api`). Defaults to the whole repository.
`instructions`	Extra product/architecture hints to honor while modeling.

Use the generate-architecture prompt for use case <USE_CASE_ID>,
scoped to apps/api. Map the services, data stores, auth, and
external integrations from the code, then save the model.

Behind the scenes the agent will:

Map the system from code

List tracked files (e.g. git ls-files), then read entrypoints, service boundaries, APIs, data stores, auth, queues, external integrations, and infra/config: restricted to your scope if you set one.

Use the real schema for enums

Read the keldyn://threagile-schema resource for allowed property names and enum values (rather than guessing), including production-required root fields like business_criticality.

Save via the tool

Call update-use-case-architecture with the architectureData object and your useCaseId, and report back the useCaseName and whether success was true.

The model should reflect only assets and links you can justify from the code: the prompt explicitly avoids inventing services that aren’t evidenced. If the agent proposes something you don’t recognize, ask it to cite the file it inferred it from.

Infrastructure-as-code counts as evidence too. If your repository defines infrastructure with Terraform (or similar), tell the agent to read it: files like *.tf, *.tfvars, and modules describe your real deployed topology (VPCs and subnets → trust boundaries, managed databases and buckets → data stores, load balancers/queues/functions → technical assets, security groups → communication links). Point the scope and instructions at them so the model is grounded in what’s actually provisioned:

Use generate-architecture for use case <USE_CASE_ID>. Also read the
Terraform under infra/ (*.tf, *.tfvars, modules/) and use it to infer
trust boundaries, data stores, and external services alongside the app code.

If saving fails schema validation, the agent re-reads keldyn://threagile-schema, fixes the model, and retries update-use-case-architecture once. Pasting the JSON into chat is not enough: the model only persists when the tool call succeeds.

2. Analyze the architecture

Once a model is saved, run analyze-use-case-architecture to threat-model it and check it against your frameworks in one pass.

Run analyze-use-case-architecture for use case <USE_CASE_ID> and list
the issues by severity.

It returns a unified, most-severe-first list of issues combining two sources:

Security risks (from Threagile): each with severity, CWE, STRIDE category, and the affected asset.
Compliance failures (failed RCM architecture checks): each with the frameworkName and rcmId it violates.

Every issue includes a proposedEdit: a natural-language remediation the agent can turn into an architecture change.

Argument	Purpose
`useCaseId`	The use case to analyze. Omit to use the first listed use case.
`run`	`true` (default) runs a fresh Threagile analysis (can take up to ~3 minutes). Set `false` to read the last stored analysis instead. RCM compliance checks are always computed live.

Analysis requires a saved architecture: run generate-architecture / update-use-case-architecture first. Issues are capped at 32 per call; when more remain, the result flags truncated with a remainingIssues count so you fix a batch at a time.

3. Remediate and re-verify

Architecture hardening is a loop: fix a batch of issues, save, and re-run to confirm they cleared and fetch the next batch.

Turn proposed edits into model changes

For each issue, convert its proposedEdit into a concrete change to the architecture object (e.g. add an encryption protocol on a link, introduce a trust boundary, tag a data asset).

Save the updated model

Call update-use-case-architecture with the revised architectureData.

Re-run the analysis

Call analyze-use-case-architecture again to verify the fixed issues are gone and pull any remaining ones.

For the highest-severity issues from the analysis, apply the proposed
edits to the architecture, save with update-use-case-architecture, then
re-run analyze-use-case-architecture to confirm they're resolved.

Don’t try to fix hundreds of issues at once. Work the returned batch (up to 32), re-run, and repeat: the tool is designed for this incremental loop.

Keeping the model current

Re-run generate-architecture, or edit with update-use-case-architecture, after you add a service, a data store, or an integration. Stale models produce stale findings. The controls-to-code workflow closes architecture checks against whatever model is saved, so a wrong model closes the wrong gaps.

Next steps

Resolve architecture risks (CWEs)

Give every Threagile risk from this analysis a documented disposition.

From controls to code

Read your controls, analyze code for evidence, and close gaps with tasks.

Keldyn MCP server

Connect your AI tool and see the full catalog of tools and prompts.

Working with a use case

Explore the Architecture Workspace and track control progress in the app.

Frameworks & controls

See how architecture checks feed control coverage and maturity.

Home

Getting started

Integrations

AI Tooling

Guides

Security & compliance

Generate an architecture from your codebase

What you’ll use

Before you start

1. Generate the model

2. Analyze the architecture

3. Remediate and re-verify

Keeping the model current

Next steps

Resolve architecture risks (CWEs)

From controls to code

Keldyn MCP server

Working with a use case

Frameworks & controls

​What you’ll use

​Before you start

​1. Generate the model

​2. Analyze the architecture

​3. Remediate and re-verify

​Keeping the model current

​Next steps

Resolve architecture risks (CWEs)

From controls to code

Keldyn MCP server

Working with a use case

Frameworks & controls

What you’ll use

Before you start

1. Generate the model

2. Analyze the architecture

3. Remediate and re-verify

Keeping the model current

Next steps