Skip to main content
This page is for a client security team assessing Keldyn ahead of adopting the Keldyn MCP server (KC): what security frameworks Keldyn’s own engineering practice is built on, and how the service behind KC is tested for vulnerabilities. For encryption, access control, and retention, see Data security; for compliance questions, see Compliance. Keldyn secures its own service the same way it helps customers secure theirs: our engineering security program tracks itself against the same control catalog — spanning general application security and AI-specific security — that ships in the product.

​
Security frameworks we align with

Application security
  • OWASP Top 10
  • OWASP ASVS (Application Security Verification Standard)
  • OWASP WSTG (Web Security Testing Guide)
  • App Defense Alliance CASA (Cloud Application Security Assessment)
  • MITRE ATT&CK
  • OAuth 2.0 Security Best Current Practice (RFC 9700)
  • PCI DSS (for payment-adjacent controls)
AI-specific security — applied to Keldyn’s own AI-assisted features, not just the frameworks we help customers track:
  • MITRE ATLAS (Adversarial Threat Landscape for AI Systems)
  • NIST AI RMF (AI Risk Management Framework)
  • NIST AI 600-1 (Generative AI Profile)
  • OWASP LLM Top 10
  • OWASP ML Top 10
  • OWASP Agentic Top 10 (Agentic Security Initiative)
  • CSA AI Controls Matrix (Cloud Security Alliance)
Individual controls also draw on supporting guidance from bodies including ENISA and industry AI-security research alongside the frameworks above.

​
How we test for vulnerabilities, and how often

  • Every pull request runs an automated gate before it can merge: linting, unit tests, integration tests, and end-to-end tests (API and web), plus a dependency vulnerability scan — any package with a known vulnerability blocks the merge. A person reviews every pull request for authorization, secrets handling, and AI-control impact before it ships.
  • Architecture-level threat modeling runs automatically against Keldyn’s own service architecture (the same Threagile-based analysis the product runs for customer use cases) and again whenever that architecture changes.
  • Manual red-team and adversarial testing of AI surfaces (prompt injection, jailbreak attempts, agentic-coordination abuse) runs during feature development and on a recurring cycle roughly every six to eight weeks thereafter.