Security

Updated September 8, 2026 · covers crinkle.dev and the Crinkle beta app

Reporting a vulnerability

Send the report to support@crinkle.dev. The machine-readable version of this page is at /.well-known/security.txt. A useful report usually has:

• what an attacker can actually do, and what they need to start (local access? a malicious website? a hostile prompt?)
• the steps to reproduce it, and the Crinkle version and operating system you saw it on
• anything that helps us confirm it — a minimal project, a log excerpt, a screenshot

We are a small team and this is beta software, so we would rather hear about something uncertain than not hear about it. If you are not sure whether a behavior is a bug or a design decision, ask.

What we ask

• Test against your own installation and your own accounts. Do not access anyone else's data.
• Do not run denial-of-service, spam, or social-engineering tests against us or our providers.
• Give us reasonable time to ship a fix before publishing. We will tell you when it lands and are happy to credit you.
• If a report exposes someone's personal data, stop, tell us, and do not keep a copy.

We have no paid bounty programme. What we can offer is a fast answer, credit if you want it, and a fix.

Where the interesting boundaries are

Crinkle is an autonomous coding agent, so it deliberately does things most apps do not: it writes files, runs developer commands, and drives a browser. Reports that land in these areas are the most valuable:

• Escaping the workspace. The Builder is supposed to write only inside its project workspaces. A path that escapes one is a real finding.
• Command approval. Commands outside the allowlist are meant to wait for you. Auto-approval is off until you enable it. Anything that runs an unapproved command is a real finding.
• The credential vault. API keys and site logins are stored encrypted and bound to the machine. They are meant to reach only the service they belong to — never a model prompt or a log.
• The local API. The app runs a localhost HTTP server for its own UI. It is meant to accept only local, same-origin requests; a web page that can reach it is a real finding.
• The Web operator. It browses with a separate profile and only sites you allow. Anything that widens that, or that gets a credential onto the wrong origin, is a real finding.

Out of scope: the security of code the AI generates for your project (review it before shipping, as the terms say), issues in third-party AI providers or sites you connect, and reports that require an attacker who already has full control of your user account on your machine.

How the app protects what you give it

• Secrets are encrypted at rest and bound to the machine that stored them, using the operating system's protection where available.
• Projects stay local. Prompts go directly from your machine to the AI provider you connected; they do not pass through our servers. See the privacy policy.
• Bug reports are generated locally as a ZIP you choose whether to send. The exporter excludes stored secrets and redacts, but redaction is not a guarantee — read an archive before sharing it.
• Releases are code-signed, and the Microsoft Store build is distributed through Microsoft's own signing and review.

Crinkle is beta software and has not had an independent security audit. We would rather say that plainly than imply otherwise.

Downloading Crinkle safely

Only two places are ours: the Microsoft Store listing, and the download links on crinkle.dev (which point at our GitHub releases). If you find Crinkle installers anywhere else, they are not from us — please tell us.

Contact

Security reports: support@crinkle.dev, subject line "SECURITY". Everything else: the same address, without the shouting.