Data flow

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 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)
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).

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)
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 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 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.

Home

Getting started

Integrations

AI Tooling

Guides

Security & compliance

Flow A — a tool call (read or write Keldyn data)

Flow B — a prompt (agent-guided workflow)

The one step where Keldyn’s own AI is involved

Security analysis stays on Keldyn’s own infrastructure

What leaves your environment, at a glance

​Flow A — a tool call (read or write Keldyn data)

​Flow B — a prompt (agent-guided workflow)

​The one step where Keldyn’s own AI is involved

​Security analysis stays on Keldyn’s own infrastructure

​What leaves your environment, at a glance

​Related

Flow A — a tool call (read or write Keldyn data)

Flow B — a prompt (agent-guided workflow)

The one step where Keldyn’s own AI is involved

Security analysis stays on Keldyn’s own infrastructure

What leaves your environment, at a glance

Related