Skip to main content
The Keldyn Constitution (KC) is the Keldyn MCP server plus the Keldyn platform it calls. It puts your governance data in front of a coding agent. Below: what that is for, the uses we will not support, and what to do when an answer looks wrong.

​
What KC is for

An agent can look up and update your organization’s Keldyn data from an IDE or a terminal: frameworks, controls and their status, evidence, risks, tasks, and (for admins) Trust Center configuration. It acts as you, on the team you picked at sign-in. Same authenticated API as the web app. Useful for pulling governance context into the work and recording routine updates. It is not an authority on whether you are compliant.

​
Uses we don’t support

KC does not replace a person, or an accredited third party, when the decision has to be theirs. Don’t use it to:
  • Issue a binding legal, regulatory, or audit determination. A final call on GDPR or EU AI Act applicability, or an attestation of compliance, goes to counsel or your auditor. KC can gather context. It does not issue the ruling.
  • Stand in for an accredited assessor or auditor. KC shows control status and evidence. It does not perform an audit.
  • Send source code, secrets, credentials, or proprietary or customer data through prompts that reach KC or a model behind it. A coding-agent review runs on your own model, in your editor, and that code stays in your environment. The PR Review Bot is a separate flow, below. It sends the changed lines of a pull request, the version identifiers, and the use case id. Nothing of the changed lines is kept after the verdict. How prompt content is handled is on Compliance. Where the bot’s lines go is on Data flow.
  • Weaken or bypass a security or compliance control without an explicit yes from someone on your team.
  • Publish to your public Trust Center with nobody looking. Shared Trust Center content is public the moment it is shared. A person reviews what goes out first.
  • Act outside the permissions of the signed-in user. KC does not escalate past the team role you already have.
  • Answer general questions that have nothing to do with your Keldyn governance data.

​
Two reviews of your code

review-changes and review-codebase read your code in the editor, on your own model. That review stays in your environment. The PR Review Bot is the other review, and the one flow where code leaves your environment. It sends the changed lines of a pull request, the version identifiers, and the use case id to Keldyn for a verdict. Nothing of the changed lines is kept after the verdict. The path is on Data flow.

​
A human stays accountable for what ships

KC acts under your account and your team’s permissions. A control status, evidence text, a risk disposition, a published Trust Center page: if the agent saved it, it is attributed to you. Same as an edit in the web app. AI-suggested findings do not overwrite an accepted or human-authored finding unless a person accepts the change. Read what the agent wants to save before you let it, and before you ship against it.

​
If KC’s answer looks wrong

  • Open the record. KC reads and writes the same rows as the web app. Check the control, risk, or use case there before you act on the agent’s summary.
  • Correct a wrong status. If a finding looks off, do not ship against it. Fix it (update-control or update-risk-tracking) and write why. Leaving the bad answer in place is how it shows up in the next audit pack.
  • Report a tool or data bug. A one-off bad answer is one thing. A tool that stored the wrong row is another. Report a bug or security issue has the address. Use the security address if a control was bypassed or data was exposed. Include the tool call and the use case.