From controls to code with MCP

Your controls are the “constitution” your system has to live by. This guide shows how to drive a full controls-to-code loop with an AI agent connected to the Keldyn MCP server: read the controls that apply to a use case, analyze your repository for implementation evidence, mark the controls that are already satisfied as Implemented (with evidence), open tasks for the ones that aren’t, and then address those tasks in code.

Every MCP tool call runs as you, scoped to the team you selected at sign-in. Marking a control complete or creating a task writes to your live Keldyn workspace, so review the agent’s proposed changes before you approve them.

Before you start

Connect the MCP server

Follow Keldyn MCP server to connect Claude Code, Cursor, or another MCP client, and sign in to the team that owns the use case you want to work on.

Open your repository

Run the agent from the repository you want to assess so it can read your code while it talks to Keldyn.

Know your use case ID

Have the target use case’s ID ready (you can also ask the agent to find it with list-use-cases). The steps below use it to scope controls to the right system.

The loop at a glance

Phase	What happens	Key MCP tools
1. Read the controls	Pull the controls (the “constitution”) for the use case and their requirements	`list-controls`, `get-control`
2. Analyze the code	Search the repo (or just your current changes) for implementation evidence	`review-codebase`, `review-changes`, `collect-evidence` (prompts)
3. Mark what’s done	Set satisfied controls to Implemented with evidence text	`update-control`
4. Open the gaps	Create remediation tasks linked to the partial/failing controls	`create-task`
5. Address the tasks	Make code changes, then verify and close out	`update-task`, `update-control`

1. Read the controls (get the “constitution”)

Start by pulling the controls that apply to the use case and reading their requirements — description, implementation guidance, acceptance criteria, and developer prompts.

Using the Keldyn MCP server, list the controls for use case
<USE_CASE_ID>. Then fetch the full details for every code-relevant
control (get-control) so we know the acceptance criteria for each.

Under the hood the agent calls list-controls (scoped with useCaseId) to enumerate controls and their current status, then get-control per rcmId for the full requirement text.

Ask the agent to group the controls by theme — authentication, encryption, API security, logging, change management, data-subject rights — so the code analysis in the next step can run per domain.

2. Analyze the codebase for evidence

Now point the agent at your repository and ask it which controls the code already satisfies. The MCP server ships built-in prompts for exactly this:

review-codebase — reviews the whole repo (or a scoped path/package) against your controls. Use it for an initial, full assessment of a use case.
review-changes — reviews only your current changes (your working diff / a branch) against the controls, instead of the entire codebase. Use it during day-to-day development and in code review to catch control impacts before you merge.
collect-evidence — scans for positive evidence that code-related controls are satisfied, then asks you to confirm before saving.

Run review-codebase for use case <USE_CASE_ID>. For each control,
tell me whether it can be marked addressed from the code alone,
and cite the exact files and line ranges as evidence.

For an initial baseline, run review-codebase across the whole repository. Once that’s done, switch to review-changes so each PR is checked against your controls incrementally — it’s far faster than re-scanning everything and keeps control status in sync as you ship. For example:

Run review-changes for use case <USE_CASE_ID> against my current
branch. Flag any control my changes affect, and tell me if any
previously-Implemented control now needs re-evidencing.

For a large repository, ask the agent to explore in parallel across domains (auth/RBAC, encryption/secrets, API security, logging/CI-CD, and data-subject-rights) and report file paths plus short excerpts. The output should sort every control into one of three buckets:

Addressed — code fully satisfies the control’s technical acceptance criteria.
Partially addressed — code contributes but gaps remain (or it needs infra/policy evidence).
Not addressed — no supporting code, or the control is out of scope for the codebase.

Only mark a control complete when the code genuinely meets its acceptance criteria. Controls that depend on infrastructure settings, organizational policy, or hosting-platform configuration usually can’t be closed from code alone — capture those as tasks instead.

3. Mark satisfied controls as Implemented

For each control in the Addressed bucket, have the agent write concrete, file-referenced evidence and flip the status to complete with update-control.

For every control we confirmed as addressed, call update-control with
status "complete" and evidenceText that names the implementing files
and how they satisfy the requirement.

The update-control tool accepts:

Field	Purpose
`rcmId`	The control to update (e.g. `IAM6`, `A.5.15`).
`useCaseId`	Scope the update to this use case’s tracking.
`status`	`todo` (Pending Review), `in_progress`, `complete` (Implemented), or `ignored` (Not Applicable).
`evidenceText`	Implementation notes / evidence (reference the files and line ranges).
`assignedTo` / `finding`	Optionally set the control owner or a finding.

Good evidence text is specific: name the middleware, service, or migration that implements the control and briefly explain how it meets the acceptance criteria. Future auditors (and your future self) will thank you.

4. Open tasks for the gaps

For each partially addressed control, have the agent create a remediation task and link it to the control with rcmId so it shows up against that control in Keldyn.

For each partially addressed control, create a task (create-task) that
describes the current state, the specific gap, and the remediation.
Set rcmId to the control's id and choose a priority based on risk.

create-task links to the control at creation when you pass rcmId:

Field	Purpose
`name`	Short, action-oriented task title (required).
`description`	Current state, the gap, and the remediation steps (reference files).
`priority`	`URGENT`, `HIGH`, `MEDIUM` (default), or `LOW`.
`rcmId`	The control this task remediates — set it so the task is linked.
`assignedUserId` / `deadline` / `timeEstimate`	Optional ownership and scheduling.

Write the gap and remediation into the task description while the analysis is fresh. A task that says “login enforces TOTP at the API, but the web credentials flow never sends the code — add a TOTP step to the login page” is actionable months later; “fix MFA” is not.

5. Address the tasks in code

Switch the agent into an implementation mode and work the tasks. A tight loop:

Pick a task

Use list-tasks (filter by priority or state) and get-task to pull the full description and its linked control.

Implement the change

Make the code change described in the task. Keep it scoped to what the control needs, and add or update tests.

Verify

Re-run the analysis (or collect-evidence) and your tests to confirm the change actually satisfies the control’s acceptance criteria.

Close the loop

Mark the task done with update-task, then call update-control to set the control to complete with evidence text pointing at the new code.

Take the HIGH priority tasks one at a time. For each: implement the fix
in code, add tests, verify it, then update-task to done and update-control
to complete with evidence referencing the new files.

Start with the highest-risk tasks (URGENT/HIGH) — e.g. missing rate limiting, SSRF exposure, or absent encryption-at-rest — before polishing lower-priority documentation and policy gaps.

Putting it together

A single end-to-end prompt can kick off the whole loop; the agent will pause for your approval before it writes anything back to Keldyn:

Using the Keldyn MCP server for use case <USE_CASE_ID>:
1. List the controls and fetch each one's requirements.
2. Analyze this repository and decide which controls the code satisfies.
3. Mark fully-addressed controls complete with file-referenced evidence.
4. Create tasks (linked by rcmId) for the partially addressed controls.
Show me the plan before making any changes in Keldyn.

Next steps

Developer SDLC playbook

Example prompts to stay control-aligned from the first session through review and release.

Keldyn MCP server

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

Frameworks & controls

Understand how controls, statuses, and coverage work across the org and each use case.

Evidence & audits

Attach evidence to controls and manage audits and certifications.

Working with a use case

Generate an architecture and track control progress inside the workspace.

Address & evidence controls

Back each control with a unit test and evidence that points at code + test paths.

Resolve architecture risks (CWEs)

Run the equivalent close-the-gap loop for Threagile security risks.

Home

Getting started

Integrations

AI Tooling

Guides

Security & compliance

From controls to code with MCP

Before you start

The loop at a glance

1. Read the controls (get the “constitution”)

2. Analyze the codebase for evidence

3. Mark satisfied controls as Implemented

4. Open tasks for the gaps

5. Address the tasks in code

Putting it together

Next steps

Developer SDLC playbook

Keldyn MCP server

Frameworks & controls

Evidence & audits

Working with a use case

Address & evidence controls

Resolve architecture risks (CWEs)

​Before you start

​The loop at a glance

​1. Read the controls (get the “constitution”)

​2. Analyze the codebase for evidence

​3. Mark satisfied controls as Implemented

​4. Open tasks for the gaps

​5. Address the tasks in code

​Putting it together

​Next steps

Developer SDLC playbook

Keldyn MCP server

Frameworks & controls

Evidence & audits

Working with a use case

Address & evidence controls

Resolve architecture risks (CWEs)

Before you start

The loop at a glance

1. Read the controls (get the “constitution”)

2. Analyze the codebase for evidence

3. Mark satisfied controls as Implemented

4. Open tasks for the gaps

5. Address the tasks in code

Putting it together

Next steps