Skip to main content
This page gives the high-level compliance answers that customers, prospects, and their own compliance reviewers ask before adopting Keldyn — including when the Keldyn platform is accessed through the Keldyn MCP server (“KC”). KC is a tooling interface: every request it makes runs against the same authenticated Keldyn API as the web app, under the token of the signed-in user, so everything on this page applies whether you use Keldyn through the app or through KC. For anything that changes over time — certification scope and dates, current subprocessor list, audit status — this page links out to the Trust Center, so the answer is never out of date. If your Keldyn organization has published its own Trust Center, use that URL for scope specific to your contract; Keldyn’s own Trust Center is at trust.keldyn.ai/keldyn.

​
Is anything sent to KC used to train models?

No. Content sent to Keldyn — including prompts, tool inputs, and governance data that AI features or KC tool calls process — is used only to serve that request. Keldyn does not use customer content to train or fine-tune any model. See AI data handling for the full posture (human oversight, access control on AI artifacts).

​
Where is data processed and stored, and under which jurisdiction?

Keldyn’s application, API, and MCP server run on cloud application-hosting infrastructure operated by companies based in the United States, and the primary application database is a managed PostgreSQL service. Data you send to Keldyn — directly or through KC — is processed and stored on this infrastructure. Not every AI-assisted feature or KC action calls out to a model provider — for example, code review and evidence-collection prompts run entirely on your own agent’s model, not Keldyn’s. Where a Keldyn-side model call does happen (for example, generating an architecture summary when an architecture is saved), the request is routed through an AI inference gateway to a model provider; that hop is transient and is not used for training. See Data flow for exactly which steps involve this hop. Exact regions and any data-residency commitments for your contract are confirmed on the Trust Center rather than restated here, since infrastructure and regional configuration can change.

​
Which subprocessors are involved when KC runs?

When you use KC (or the Keldyn web app), the following subprocessors are involved in processing your data: This list reflects the subprocessors in the data path for a typical KC request. The Trust Center is the authoritative, current subprocessor list for your organization’s contract — check it for any additions or changes.

​
What is Keldyn’s role under GDPR, and is a DPA available?

For the governance, risk, and compliance data your organization enters into Keldyn — including data submitted through KC — Keldyn acts as a data processor, processing that data on your organization’s instructions; your organization remains the data controller. For the limited account data needed to administer your Keldyn account itself (such as billing and login), Keldyn acts as a controller. A Data Processing Addendum (DPA) is available. Contact your Keldyn representative or request it through the Trust Center to get the current version executed for your organization.

​
Which attestations does Keldyn hold?

As an early-stage company, Keldyn does not yet hold completed third-party security attestations (for example, SOC 2 or ISO 27001); these are on the roadmap as the company scales. The Trust Center is the live source for Keldyn’s current attestation and audit status, including any in-progress or planned certifications — see it for current scope and status rather than relying on a copy here.