Skip to main content
The Keldyn Constitution (KC) — the Keldyn MCP server plus the Keldyn platform it calls — puts your governance data in front of your AI coding agent. This page sets out what that’s for, what it isn’t for, and what to do when its output doesn’t look right.

​
What KC is for

KC lets an AI agent look up and update your organization’s Keldyn data — frameworks, controls and their implementation status, evidence, risks, tasks, and (for admins) Trust Center configuration — from inside your IDE or terminal, acting as you, scoped to the team you signed in with. It is a tooling interface onto the same authenticated Keldyn API the web app uses: a way to bring governance context into your workflow and record routine updates, not an independent source of authority on your compliance.

​
Uses we don’t support

KC is not a substitute for judgement that has to stay with a person or an accredited third party. Don’t use it to:
  • Make a binding legal, regulatory, or audit determination — for example, a final call on GDPR or EU AI Act applicability, or an attestation of compliance. Route those to counsel or your auditor; KC can gather supporting context, not issue the ruling.
  • Stand in for an accredited assessor or auditor. KC surfaces control status and evidence; it doesn’t perform or replace an audit.
  • Send source code, secrets, credentials, or proprietary/customer data through prompts that reach KC or the underlying model. See Compliance for how prompt content is handled.
  • Weaken or bypass a security or compliance control without explicit approval from a person on your team.
  • Publish to your public Trust Center unattended. Trust Center content is public the moment it’s shared — a person reviews what goes out before it does.
  • Act outside the permissions of the signed-in user. KC never escalates access beyond what your team role already allows.
  • Serve as a general-purpose knowledge base for questions unrelated to your Keldyn governance data.

​
A human stays accountable for what ships

KC acts under your account and your team’s permissions, so anything it changes — a control’s status, evidence text, a risk disposition, a published Trust Center page — is attributed to you and stays your responsibility, the same as an edit you’d make in the web app. AI-suggested findings do not overwrite an existing accepted or human-authored finding by default; a person has to accept the change. Review what an agent proposes before you let it save, and before you rely on it in something you ship.

​
If KC’s answer looks wrong

  • Check the record directly. KC reads and writes the same data as the web app, so open the control, risk, or use case there to confirm what’s actually stored before you act on the agent’s summary.
  • Don’t let it stand unverified. If a status or finding looks wrong, don’t ship against it — correct it (for example, via update-control or update-risk-tracking) with a note on why, rather than leaving a wrong answer in place.
  • Report it if it looks like a tool or data bug, not just a one-off bad answer — see Report a bug or security issue for where to send it (and the security address if it looks like a control was bypassed or data was exposed) with the tool call and use case involved, so it can be fixed at the source.