Data flow

What leaves your environment, where it goes, who holds it, and for how long. Two products: a Keldyn MCP server (“KC”) tool or prompt, and the PR Review Bot. Only one of them sends code out.

Tools (list-controls, update-control, update-use-case-architecture, and the rest) read or write Keldyn data. Each call is a request and a response.
Prompts (start-dev, review-changes, review-codebase, collect-evidence, generate-architecture) hand your agent a brief and a little Keldyn context. A coding-agent review runs on your own model. Your code does not reach Keldyn during that step.
The PR Review Bot is the flow where code leaves. It sends the changed lines of a pull request, the version identifiers, and the use case id.

KC tools and prompts assume you are already connected. The one-time OAuth login is on Keldyn MCP server. The Review Bot is a repository integration, below.

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

Most tool calls take this path: list-*, get-*, update-control, update-risk-tracking, create-task, Trust Center admin tools, and the rest of that family.

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) do not scan your code. They assemble a text brief from a little Keldyn context and hand it to your agent. The agent does the 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, such as 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

For every KC prompt, the scan and the reasoning happen on your side, on your own model. The only thing that can reach Keldyn from that prompt is the finding, evidence line, or architecture object your agent explicitly saves with a follow-up tool call. Each prompt’s rules require your review before that save. See Responsible use.

PR Review Bot

A coding-agent review (review-changes, review-codebase, start-dev) runs on your own model. Your code stays in your environment for that review. The PR Review Bot is the one flow where code leaves your environment. When a connected repository opens or updates a pull request, or someone comments @keldyn, the bot sends exactly:

Changed lines: the pull request diff.
Version identifiers: the repository, the pull request, and the head commit.
Use case id: the use case the repository is reviewed against, so the verdict uses that use case’s controls.

Step	What data	Where it goes	Who can see it	How long
1. The review starts	Changed lines, version identifiers, and the use case id	Your git host, over HTTPS, to the Keldyn Review Bot	Keldyn, for this review	Until the verdict is produced
2. The verdict is produced	The same changed lines, version identifiers, and use case id	Keldyn Review Bot → Requesty (AI inference gateway) → AWS Bedrock (Anthropic models, `eu-west-1`)	Requesty and AWS Bedrock, for that single inference call. Keldyn does not train on it, and the model provider does not keep it for training (see Compliance)	For the inference call. Nothing of the changed lines is kept after the verdict
3. The verdict is recorded	The verdict, the file path, and the line number	Stored with the run in PostgreSQL, and posted as a check and comments on your pull request	Your team, in Review history. Anyone who can open the pull request can see the comments on your git host	The run record stays with the account. Nothing of the changed lines is kept after the verdict

To read the changed lines in place, the review checks out that pull request head in a short-lived sandbox and may read a line the change depends on. The checkout is discarded when the run finishes. Nothing of the changed lines is kept after the verdict.

Where Keldyn’s own AI is involved, without your source code

Saving an architecture is a Keldyn-side model call, and it does not send your source code. When update-use-case-architecture saves a Threagile model, typed by hand or produced by generate-architecture, keldyn-api writes a plain-language management summary of it. The model is asset names, types, technology, trust boundaries, and data flows. That is GRC metadata describing the system for risk analysis. It is not your source code, so this hop is not your codebase reaching a model provider. The request:

Step	What data	Where it goes	Who holds it	How long
Architecture is saved	The architecture model, formatted into a compact prompt payload. Formatting is a normal step for any model call. Nothing 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, and 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

Stays on your own model: source code, files, and diffs read during a coding-agent review (review-changes, review-codebase, start-dev). That review runs on your model. Your code does not reach Keldyn.
The one flow where code leaves your environment: the PR Review Bot. It sends the changed lines, the version identifiers, and the use case id. Those changed lines go to Keldyn, then to Requesty and AWS Bedrock (Anthropic models, eu-west-1) for the verdict. Nothing of the changed lines is kept after the verdict. Your team can see the run record; people who can open the pull request can see the comments on your git host.
Leaves your machine, stays inside Keldyn: anything you pass as a KC tool argument (evidence text, control status, an architecture model, a task) goes to keldyn-api, Postgres, or S3 over HTTPS, the same as if you had typed it into the web app.
Leaves Keldyn to a subprocessor, and is not your source code: the architecture-summary call, sent transiently to Requesty/Bedrock. That payload is Keldyn GRC metadata (an asset and trust-boundary model). Your codebase does not reach a model provider through KC. Nothing here is used for training. See Compliance for the subprocessor list.
Stays on 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)

PR Review Bot

Where Keldyn’s own AI is involved, without your source code

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)

​PR Review Bot

​Where Keldyn’s own AI is involved, without your source code

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

PR Review Bot

Where Keldyn’s own AI is involved, without your source code

Security analysis stays on Keldyn’s own infrastructure

What leaves your environment, at a glance

Related