Security policy

KMS is security-sensitive software. Please report suspected vulnerabilities privately.

Supported versions

Only the latest patch release in the current minor series receives security fixes.

Reporting a vulnerability

Email hello@parlant.co with the subject KMS security report.

Do not open a public issue with exploit details, secret material, or production incident data. We will acknowledge the report, coordinate investigation and remediation privately, and agree on disclosure timing with the reporter.

A good report includes:

• affected version/commit;
• deployment mode: crypto-only, embedded, standalone, or remote;
• database backend: SQLite or PostgreSQL;
• RMK provider: local, StackIT, AWS, or GCP;
• whether HTTP API/session/factors are involved;
• minimal reproduction steps;
• impact and preconditions;
• logs only after removing secrets.

Never include:

• plaintext secrets;
• ciphertext from production data;
• bearer tokens/session secrets/API tokens;
• passwords/passphrases/factor codes;
• RMK key files/cloud credentials;
• fallback private keys.

Security-sensitive defaults

Production deployments should:

• set KMS_SESSION_HASH_KEY to a high-entropy secret;
• disable crash dumps with ERL_CRASH_DUMP_BYTES=0 or ERL_CRASH_DUMP_SECONDS=0;
• use explicit RMK config;
• protect SQLite DB/WAL/SHM files or PostgreSQL credentials;
• disable request-body logging for KMS HTTP routes;
• serve remote KMS only behind TLS or trusted private networking.

See Security docs.