> ## 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. # Data flow > Where data goes, step by step, from the moment you run a Keldyn MCP server (KC) tool or prompt to the moment an answer comes back. This page walks through what happens to your data on a single KC request — from the moment your coding agent calls a **Keldyn MCP server ("KC")** tool or prompt, to the moment the answer comes back. It's written to be cleared against your own data-flow diagram before you adopt KC. There are two distinct journeys depending on what you invoke, and they behave very differently for data leaving your machine: * **Tools** (`list-controls`, `update-control`, `update-use-case-architecture`, etc.) read or write Keldyn data directly — every call is a request/response round trip to Keldyn. * **Prompts** (`start-dev`, `review-changes`, `review-codebase`, `collect-evidence`, `generate-architecture`) hand your agent a brief and a small amount of Keldyn context; the actual codebase scanning and reasoning then runs **on your machine, using your agent's own model** — nothing about your code reaches Keldyn during that step. Both assume you're already connected — see [Keldyn MCP server](/keldyn-mcp-server) for the one-time OAuth login that scopes every subsequent call to your user and team. ## Flow A — a tool call (read or write Keldyn data) This is the path for the great majority of tool calls: `list-*`, `get-*`, `update-control`, `update-risk-tracking`, `create-task`, Trust Center admin tools, and so on. | Step | What data | Where it goes | Who holds it | How long | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1. Agent calls a KC tool | The tool's arguments (e.g. a use case id, a status, evidence text you or your agent wrote) | Leaves your machine over HTTPS to the **Keldyn MCP server** | keldyn-mcp, in memory for this request only | Milliseconds — never written to disk by keldyn-mcp | | 2. keldyn-mcp forwards the call | The same arguments, plus your OAuth Bearer token | Over HTTPS to **keldyn-api** (the same API the web app uses) | keldyn-api | For the duration of the request | | 3. keldyn-api authenticates and executes | Token is validated (`GET /me`); the request reads/writes the relevant rows | **PostgreSQL** for structured data; **S3-backed storage** for uploaded files/evidence documents | keldyn-api / its database | As long as your account or that record exists — you can edit or delete it any time (see [Retention and deletion](/data-security#retention-and-deletion)) | | 4. Audit entry is written | Only the **tenant, user, tool name, timestamp, and outcome** (success/failure) — never the tool's inputs or outputs | Fire-and-forget `POST` to keldyn-api's internal audit endpoint | keldyn-api, in an append-only table | Kept as permanent accountability history, not deleted with the account | | 5. Response comes back | The requested data (or confirmation of the write) | keldyn-api → keldyn-mcp → your agent, over HTTPS | Back on your machine | N/A — it's now in your agent's context | Nothing in this flow is sent to a third-party AI model. It's the same authenticated Keldyn API call the web app makes for the same action, just issued by your agent instead of a browser click. ## Flow B — a prompt (agent-guided workflow) Prompts (`start-dev`, `review-changes`, `review-codebase`, `collect-evidence`, `generate-architecture`) don't scan your code themselves — they assemble a text brief from a little Keldyn context and hand it to your agent, which does the actual work locally. | Step | What data | Where it goes | Who holds it | How long | | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------- | | 1. Agent invokes a prompt | A framework name, use case id, or diff you supply (optional) | To keldyn-mcp, over HTTPS | keldyn-mcp, in memory | For the duration of the request | | 2. keldyn-mcp fetches context | A small, targeted read — e.g. the applicable controls for your org/use case, or a use case's name and description | keldyn-mcp → keldyn-api → Postgres → back | keldyn-api / Postgres (already-stored data, nothing new written) | N/A — a read only | | 3. keldyn-mcp returns a brief | A text prompt combining that context with instructions (e.g. "review these changes against these controls") | Back to your agent, over HTTPS | Your agent's context | Held by your agent like any other message | | 4. **Your agent does the work — on your machine** | Your source code, diffs, or files, read by **your agent's own model** (Cursor, Claude Code, etc.) | **Nowhere.** This step never calls Keldyn or any Keldyn-side AI model. As the `review-changes`/`review-codebase`/`start-dev` prompts put it: *"Keldyn spends no inference tokens here... the review runs on the user's model/tokens."* | Your machine / your agent's model provider only (governed by your own agent's settings, not Keldyn's) | Not applicable to Keldyn | | 5. Agent presents findings and asks before saving | A proposed evidence summary, architecture model, or review finding | Shown to you in your editor first | Your machine | Until you decide | | 6. You approve → agent calls a tool | Only the **specific text your agent chooses to save** — e.g. an evidence summary citing file paths, or a Threagile architecture JSON — not your raw source tree | Now follows **Flow A** above (`update-control`, `update-use-case-architecture`, etc.) | keldyn-api / Postgres | Per Flow A | This is the answer to "does my code leave my machine": for every prompt, the scan and the reasoning happen entirely on your side. The only thing that can reach Keldyn is whatever specific finding, evidence line, or architecture object your agent explicitly saves with a follow-up tool call — and each prompt's rules require your review/approval before that happens (see [Responsible use](/responsible-use)). ## The one step where Keldyn's own AI is involved There is exactly one point in the KC flow where data is sent to a third-party model provider: **saving an architecture.** When `update-use-case-architecture` saves a Threagile model (whether typed by hand or produced by the `generate-architecture` prompt above), keldyn-api generates a plain-language management summary of it. The Threagile model itself — asset names, types, technology, trust boundaries, data flows — is Keldyn GRC metadata *describing* your system for risk analysis, not your source code, so this isn't your codebase or IP reaching a model provider. That request: | Step | What data | Where it goes | Who holds it | How long | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Architecture is saved | The architecture model, formatted into a compact prompt payload (a standard step for any LLM call, not a redaction — nothing sensitive is stripped because none of it is source code) | keldyn-api → **Requesty** (AI inference gateway) → **AWS Bedrock** (Anthropic models, `eu-west-1`) | Requesty / Bedrock, only for the duration of that single inference call | Transient — not stored by the model provider, not used to train any model (see [Compliance](/compliance#is-anything-sent-to-kc-used-to-train-models)) | | Summary comes back | A short paragraph plus key components/connections/trust boundaries | Back to keldyn-api | Stored alongside the architecture in Postgres | Same as the architecture record — until you edit or delete it | Untrusted content is screened before this hop (prompt-injection/jailbreak checks) — see [Cybersecurity](/cybersecurity) for the AI-specific controls this and other AI-assisted features are tested against. ## Security analysis stays on Keldyn's own infrastructure Running `analyze-use-case-architecture` (or the security refresh triggered automatically after a save) does **not** call a third-party AI model. It sends the architecture model to **Threagile**, a self-hosted, deterministic risk-analysis engine Keldyn runs on its own infrastructure (the same one that also evaluates framework compliance checks). Threagile returns a list of risks, which keldyn-api stores in Postgres alongside the use case. No subprocessor beyond Keldyn's own hosting is involved in this step. ## What leaves your environment, at a glance * **Never leaves your machine:** your source code, files, and diffs read during a prompt's local scanning step (Flow B, step 4) — that's the whole point of prompts running on your agent's model. * **Leaves your machine, stays inside Keldyn:** anything you pass as a tool argument (evidence text, control status, an architecture model, a task) — goes to keldyn-api/Postgres/S3 over HTTPS, same as if you'd typed it into the web app. * **Leaves Keldyn to a subprocessor:** only the architecture-summary call described above, sent transiently to Requesty/Bedrock. That's Keldyn GRC metadata (an asset/trust-boundary model), not your source code — your codebase never reaches a model provider through KC, and nothing here is used for training. See [Compliance](/compliance#which-subprocessors-are-involved-when-kc-runs) for the full subprocessor list. * **Never leaves Keldyn's own infrastructure:** the Threagile security analysis, which runs on Keldyn-hosted infrastructure rather than a third party. ## Related * [Keldyn MCP server](/keldyn-mcp-server) * [Data security](/data-security) * [Compliance](/compliance) * [Responsible use of the Keldyn Constitution](/responsible-use) * [Cybersecurity](/cybersecurity)