Skip to main content
This page answers the questions an initial security review usually raises about connecting the Keldyn MCP server (“KC”): what happens to data you send it, whether it changes what your coding agent can reach, and who at Keldyn can see your data. For compliance-specific questions (model training, subprocessors, GDPR/DPA, attestations), see Compliance.

​
Key concerns

​
Could uploading data to KC leak my IP, PII, or cardholder data?

Anything you send to KC — tool inputs, and anything a persisted tool call writes back to Keldyn (evidence text, control status, findings) — is protected the same way as data entered through the web app: encrypted in transit and at rest, and scoped to your team’s access control (see below). It’s never used to train models (see Compliance). Keldyn does not process or store payment card data. If a control’s evidence relates to a payment flow, record an attestation or reference to it rather than pasting actual cardholder data into Keldyn.

​
Does connecting KC give my coding agent extra access?

No — MCP access and your coding agent’s access are two separate things. KC authenticates over OAuth as you, scoped to one team, and that token only unlocks the specific Keldyn tools listed in the MCP server guide (read/write your Keldyn governance data). Connecting KC does not grant your coding agent (Cursor, Claude Code, etc.) any new access to your filesystem, shell, cloud accounts, or CI/CD — whatever access your agent already has is unrelated to and unchanged by KC, and Keldyn has no visibility into it.

​
Does KC read or write to my production or other sensitive environments?

No. KC only reads and writes Keldyn governance data (frameworks, controls, evidence, tasks, use cases, Trust Center configuration) through the Keldyn API — it holds no credentials to, and cannot reach, your source repositories, infrastructure, or production/staging environments. Prompts like collect-evidence or review-changes ask your coding agent to look at your local codebase and propose evidence; that scan happens entirely on your side, and nothing reaches Keldyn until the agent makes an explicit MCP tool call (for example update-control) to save it — which you can review first, see Responsible use. For the full step-by-step, including the one step where Keldyn’s own AI is involved (an architecture summary), see Data flow.

​
Encryption, in plain terms

  • In transit: every connection to Keldyn — the web app, the API, and KC — is HTTPS. Nothing moves between you and Keldyn unencrypted.
  • At rest: the application database and uploaded files (evidence, documents) are encrypted at the storage layer. Passwords are hashed, never stored as plain text. Integration credentials and other long-lived secrets get an additional layer of encryption on top of that.

​
Who at Keldyn can access your data, and when

Day to day, access to your data is scoped by team and role like anyone else’s — there’s no standing back door for Keldyn staff. The only way a Keldyn team member can view your account is a deliberate “act as you” support flow, gated end to end:
  • Only platform admins using a Keldyn company account can start it.
  • It requires a stated reason and the admin re-authenticating (password, plus a one-time code if they have 2FA on).
  • The resulting access is single-use and expires almost immediately if unused, and it never grants more than the target user already had.
  • Every step — who, for whom, why, and when — is written to an audit trail that can’t be edited or deleted afterward.
That non-routine access is sampled and reviewed monthly, and who has any standing access at all is reviewed on a quarterly cycle.

​
Retention and deletion

Your data lives for as long as your account or team does, and you control it directly: use cases, evidence, and documents can be edited or deleted from the product at any time. Deleting your account is self-service and permanent — it’s treated as a GDPR right-to-erasure request. Your personal data is removed outright, uploaded files are queued for removal from storage shortly after, and any data still needed by teammates you shared a team with is reassigned to another active member rather than disappearing out from under them. Audit logs are the one exception: records of who accessed or changed what are kept as append-only accountability history, separate from the data they describe, and aren’t deleted along with an account.