> ## Documentation Index
> Fetch the complete documentation index at: https://docs.keldyn.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Cybersecurity

> The security frameworks Keldyn's own engineering practice aligns with, and how the service behind the Keldyn MCP server (KC) is tested for vulnerabilities.

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](/data-security); for compliance questions, see [Compliance](/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.

## Related

* [Data security](/data-security)
* [Data flow](/data-flow)
* [Compliance](/compliance)
* [Security & privacy](/security-and-privacy)
* [Report a bug or security issue](/report-a-problem)