This page summarizes the controls Kodus uses to protect accounts, data, and release binaries, and explains how to report a security issue. It is informational and does not create any additional contractual obligations beyond those set out in the Terms of Service and Data Processing Agreement.
1. Transport Security
All traffic between the Kodus CLI, the relay backend, and the web Dashboard is served over TLS. The Dashboard is served from https://kodus.ai with HSTS, and the CLI pins its relay connection to HTTPS endpoints. Requests to AI Model Providers are made over the providers' HTTPS API endpoints.
2. Storage Security
Databases backing the Dashboard are stored on encrypted filesystems. Sensitive fields, including password hashes, invite tokens, and bearer-token secrets, are hashed or encrypted at rest. Backups are encrypted.
3. Authentication and Session Handling
- Passwords are stored only as salted hashes using bcrypt or argon2; cleartext passwords are never logged or persisted.
- Session cookies (
kodus_session,kodus_remember) areHttpOnly,Secure, andSameSite=Strictto limit CSRF and session-theft risk. - CSRF tokens (
kodus_csrf) protect state-changing Dashboard and API requests. - Relay connections from the CLI authenticate using bearer tokens scoped to a specific account and revocable from the Dashboard.
- Signup is invite-only, which limits the exposure of account-creation endpoints.
4. Web Application Hardening
The Dashboard serves a Content Security Policy (CSP) that restricts script origins and disallows inline script except where explicitly required. HTTP responses set X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and appropriate framing controls. Inputs crossing trust boundaries are validated server-side.
5. Release Binary Integrity
Official release binaries of the Kodus CLI are published at https://kodus.ai/releases/latest/ for macOS (amd64, arm64), Linux (amd64, arm64), and Windows (amd64). Each release is accompanied by a SHA256SUMS file that lists the expected hash of every artifact. Users and package managers should verify the hash of any downloaded binary against the published SHA256SUMS before execution. Releases are built from tagged commits in our internal build infrastructure.
6. Safety Layer for Agent Execution
The agent includes a safety layer that inspects proposed tool calls before execution. High-risk operations (for example, file deletion, destructive git commands, and bash commands matching sensitive patterns) are surfaced to the user for approval and can be deferred, denied, or reviewed. Users should configure the safety layer and approval policy appropriate to their environment; safety-layer controls are a defense in depth, not a substitute for reviewing agent actions.
7. Vendor and Subprocessor Security
We engage third-party subprocessors (as enumerated in the Data Processing Agreement) for AI model inference, payments, error reporting, and content delivery. We select vendors with documented security programs, and we transmit only the data necessary for each vendor's service.
8. Incident Response
We maintain internal incident-response procedures covering triage, containment, remediation, and notification. Where a personal-data breach triggers statutory notification requirements, we will notify affected customers and competent authorities within the timeframes required by applicable law.
9. Responsible Disclosure
We welcome reports of security vulnerabilities in the Kodus CLI, relay, Dashboard, or infrastructure. Please email security@kodus.ai with a clear description of the issue, reproduction steps, and any proof-of-concept material. We ask that you:
- Give us a reasonable opportunity to investigate and remediate before any public disclosure; our standard disclosure window is ninety (90) days from the date we acknowledge your report, subject to extension by mutual agreement for complex issues;
- Avoid accessing, modifying, or exfiltrating data beyond what is strictly necessary to demonstrate the issue;
- Avoid denial-of-service testing, social-engineering of our staff, and physical attacks;
- Comply with all applicable law.
10. Bounty and Recognition
We do not currently operate a paid bug-bounty program. We appreciate good-faith reports and are happy to credit reporters publicly (with their consent) for valid findings that result in a fix. We will not pursue civil or criminal action against researchers who act in good faith and within the scope of this policy.
11. Changes to This Policy
We may update this Security page from time to time to reflect changes in our controls or processes. The date above indicates when the page was last updated.
Security Contact
To report a vulnerability or ask a security question, please contact:
Kodus
Email: security@kodus.ai
Website: https://kodus.ai