> ## Documentation Index
> Fetch the complete documentation index at: https://docs.keldyn.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# From controls to code with MCP
> Use the Keldyn MCP server to read your controls, analyze your codebase for evidence, mark satisfied controls complete, and open tasks to close the gaps.
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](/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
Follow [Keldyn MCP server](/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.
Run the agent from the repository you want to assess so it can read your code while it talks to Keldyn.
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.
```text theme={null}
Using the Keldyn MCP server, list the controls for use case
. 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](/keldyn-mcp-server#built-in-workflows-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.
```text theme={null}
Run review-codebase for use case . 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:
```text theme={null}
Run review-changes for use case 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`.
```text theme={null}
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.
```text theme={null}
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:
Use `list-tasks` (filter by priority or state) and `get-task` to pull the full description and its linked control.
Make the code change described in the task. Keep it scoped to what the control needs, and add or update tests.
Re-run the analysis (or `collect-evidence`) and your tests to confirm the change actually satisfies the control's acceptance criteria.
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.
```text theme={null}
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:
```text theme={null}
Using the Keldyn MCP server for use case :
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
Connect your AI tool and see the full catalog of tools and built-in prompts.
Understand how controls, statuses, and coverage work across the org and each use case.
Attach evidence to controls and manage audits and certifications.
Generate an architecture and track control progress inside the workspace.