Security

1. Scope

This policy covers Choro-authored desktop code, the Choro landing pages, official packaged builds, the Choro-operated Design deployment and provisioner, and the Choro Remote relay. It does not authorise testing of Penpot or Kaleidos systems, Anthropic, OpenAI, GitHub, Google, Apple, Render, or any other third party.

Choro does not currently operate a paid bug-bounty programme. This policy describes permitted good-faith research and coordinated disclosure; it does not promise payment.

2. Report a vulnerability

Email security@choro.dev with a neutral subject such as “Choro security report”. Do not include live credentials, unnecessary personal information, or exploit details in a public issue. If ordinary email is unsuitable, request an encrypted reporting method before sending sensitive proof.

Include what helps reproduce it

• The affected Choro version, macOS version, and component.
• A clear description of the impact and the conditions needed to trigger it.
• Minimal reproduction steps, proof-of-concept material, or logs with secrets removed.
• Whether the issue affects local data, command execution, provider credentials, remote pairing, relay admission, or release integrity.
• How you would like to be credited, or whether you prefer to remain anonymous.

3. Research guidelines

Use only your own devices, repositories, Design profile and files, accounts, rooms, and data. Stop if you encounter information belonging to someone else. Use the smallest proof needed to demonstrate the problem, avoid persistence, and do not degrade the website, Design service, or relay.

Do not use social engineering, phishing, physical attacks, denial of service, automated high-volume scanning, credential stuffing, destructive commands, or testing against third-party provider infrastructure. Give the project a reasonable opportunity to investigate and fix a confirmed issue before publishing technical details.

4. Intended safe harbor

Choro intends to treat research performed in good faith, within this policy, as authorised testing and not to pursue legal action for accidental, good-faith violations. If you are unsure whether a test is in scope, ask security@choro.dev before continuing.

This statement cannot bind third parties and does not excuse violations of law, privacy rights, provider terms, or access restrictions on systems outside Choro’s control. The final public policy should be reviewed for the jurisdictions in which Choro will be offered.

5. Current security architecture

• Local-first storage. Projects, documents, Git state, conversations, and workspace configuration are handled on the user’s Mac unless the user selects an external action.
• Local secrets. Remote transport keys and managed Design installation, API, MCP, and browser-session credentials use the macOS or iOS Keychain. Database connection URIs and issue-tracker API tokens are currently stored in Choro’s local application database, so the Mac account and Choro data directory must be protected as sensitive.
• User-selected tools. Choro runs coding-agent CLIs and developer tools configured by the user rather than issuing a shared Choro model credential.
• Visible project scope. Users select the workspaces and services an agent can work with, but they remain responsible for reviewing the actual permissions of each local process.
• Open-source review. Choro-authored source is distributed under Apache-2.0, with third-party licence notices tracked separately.
• Dependency boundaries. Bundled and vendored components retain their own licences and security update responsibilities.

6. Hosted Design security

Choro Design runs a self-hosted Penpot deployment with public registration, ordinary onboarding, and Penpot telemetry disabled. A narrow Choro provisioner creates a private profile for a random installation identity and returns separate API, MCP, and browser-session credentials. Raw managed credentials are stored in the user’s platform credential store; the provisioner persists hashes of installation and session credentials rather than those raw values.

Design content is still hosted data. Choro’s service database and object storage contain profiles, projects, files, assets, and related metadata, and the infrastructure host can process network and operational logs. Access controls, TLS, database and volume isolation, encrypted backups where used, security updates, least-privilege administration, and tested deletion are therefore part of the production security boundary.

A compromised Mac, Design credential, service administrator account, dependency, or hosting layer may expose hosted designs. Keep credentials out of prompts and repositories, report suspected exposure promptly, and do not use a design file for secrets.

7. Choro Remote security

Remote is an optional bridge to a running Desktop instance, not a hosted cloud agent. The relay receives application-encrypted envelopes and routes them without interpreting the plaintext. It stores active room state in memory and has no application database.

The Desktop proves room ownership by signing a fresh challenge with its private key. A paired device sends its relay admission token over TLS; the relay hashes it before comparing it with hashes supplied by the Desktop. Device bearer tokens and transport keys remain at the endpoints. Device access can be revoked, pairing is available only while the Desktop opens a pairing window, and connection and message ceilings limit resource exhaustion.

Encryption does not remove endpoint risk. A compromised Mac, paired device, provider CLI, browser, or local project can expose data before encryption or after decryption. Revoke lost devices and stop remote access when it is not needed.

8. Third-party agents and services

Choro cannot guarantee the security, availability, or data handling of a coding-agent provider, Git host, issue tracker, database, package, website host, or CLI you connect. Keep those tools updated, use multi-factor authentication where available, review their permissions, and follow their security guidance.

Do not paste secrets into prompts. Prefer short-lived, least-privilege credentials and separate development from production. Treat model output and generated commands as untrusted until reviewed.

9. Release integrity

Official public builds are distributed through links on choro.dev, signed with an Apple Developer ID, and notarised by Apple. Choro publishes a checksum with direct-download releases. Do not install a build from an unexpected source or bypass a macOS security warning for a build that cannot be verified.

The release process includes a protected signing identity, repeatable packaging, dependency and licence review, and a documented update path.

10. User responsibilities

• Keep macOS, Choro, provider CLIs, and project dependencies updated.
• Use Git, backups, and review checkpoints before allowing broad file changes.
• Inspect plans, diffs, commands, network actions, and permission prompts.
• Prefer development credentials and avoid unnecessary sensitive personal data.
• Protect the Mac account, provider sessions, SSH keys, tokens, and paired devices.
• Do not place secrets or unauthorised personal data in hosted Design files.
• Report suspected credential exposure or unexpected remote access immediately.

11. Response process

Choro aims to acknowledge a valid report within three business days and provide an initial assessment or status update within ten business days. Remediation and disclosure timing depend on severity, complexity, user impact, and third-party involvement.

Reports may be closed as duplicates, expected behaviour, third-party issues, or low-risk hardening suggestions. Credit will be given only with the reporter’s permission.

12. Security limits

No software can promise absolute security. Local-first architecture reduces some central data-collection risks, but Choro intentionally gives powerful local tools access to projects and terminals, and Design files are stored on a hosted service. The security boundary includes OS permissions, provider authentication, hosted-service controls, project isolation, human review, and safe operating habits.

This page describes current design and intent; it is not a warranty, certification, penetration-test report, SOC 2 claim, or guarantee that every control is free from defects.

13. Updates and contact

This policy will be updated as Choro’s architecture and release process change. Contact security@choro.dev for security matters and legal@choro.dev for legal questions about this policy.

Choro publishes a standards-compatible /.well-known/security.txt file pointing to this reporting channel and policy.