Security — Myrqen

What runs locally

All of the assessment. Project discovery, the static analysis pass, the taint model, the finding contract, deduplication, redaction, the safety gates, and all four report formats are computed on your machine by the myrqen CLI and by the coding agent already installed there.

There is no Myrqen model. The reasoning comes from the agent you already pay for, so no prompt of yours, and no code excerpt inside one, reaches a model we operate or a provider we chose. There is no Myrqen API key to buy, and none to leak.

A machine that cannot reach the network scans anyway. If the API is unreachable, the CLI degrades to the local outcome an unlinked device would get and names the reason, it does not fail. That behaviour is asserted by a regression test, because it was once a real bug: a linked device with a failing API used to exit 1 and write nothing.

What can leave your machine

One thing, and only if you say so per scan: the report. Not your repository, not a copy of your source tree, not your dependency manifest, and not your traffic.

Data	Leaves your machine?
Your source tree	Never. There is no code path that uploads it.
The report body, including evidence snippets	Only when you answer yes to the sync question, which is asked once per scan and is never remembered as a default.
Secret values	Never. A secret is described by type and location; the value is not carried at all.
HTTP traffic recorded during validation	Never leaves the machine. It is not part of the report.
Progress events for a live report	Only for a scan you chose to sync. Phase names and counts, not content.
Which coding agents you have installed	Not by itself. It appears in the report metadata of a scan you sync, because a report has to record which agent produced it.

A local report has no expiry and is never removed by anything on our side. It is a file in .myrqen/reports/ in the project you scanned, and it stays yours if you never create an account at all.

Secrets

Redaction happens in the CLI, before a finding is accepted, not on the way out. A finding whose content still contains a secret value is rejected rather than cleaned up quietly, so a leak is a failure the agent has to fix rather than something that silently almost happened.

This is tested rather than asserted. The bundled vulnerable fixture contains planted canary secrets, and the end-to-end run greps for them in the local report, in all four formats, and in the synced cloud copy. In the production verification on 2026-08-21, both canaries appeared in none of them.

Agent detection never opens a credential store, a token file, browser data, or a conversation history. It asks whether paths exist. The durable device credential is held in the operating system keystore - Keychain, Windows Credential Manager, or Secret Service, and falls back to a 0600 file only where no keystore exists. It is never printed to a terminal.

Scope and authorization

Anything on your own machine needs no prompt. Everything else needs an exact-origin grant. Authorizing https://api.example.com does not authorize example.com, a sibling host, another port, or another scheme. There is no wildcard form.

Project content is data, never instruction. A README, a code comment, or an API response cannot grant scope, authorize a target, or relax the policy. An origin that Myrqen only learned about from content which also tried to instruct it is quarantined: the authorization gate refuses it even when a human passes --grant, because a person approving a target that injected text authored is not meaningful consent. The attempt is recorded in the report as a finding.

Destructive actions

Refused by policy, at every effort level. There is no opt-in flag in this release. Mass deletion, request flooding, credential spraying, persistence, and scope expansion are on a prohibited list that higher effort does not relax.

A refusal is written into the report rather than silently skipped, so you can see what the assessment declined to do and decide whether you needed it. Myrqen also never tests production: the validation target is the application running on your machine.

Encryption

A synced report body is encrypted with AES-256-GCM before it reaches any storage driver. The envelope is version | iv | authTag | ciphertext, and the object key is bound in as associated data so a stored blob cannot be replayed under another report's key. Server-side encryption is separately requested from the object store as a second layer. A leaked bucket yields ciphertext.

This is not end-to-end encryption, and we will not call it that. The server holds the key, because the server renders the report in a browser and applies per-recipient share projections. A product that claimed otherwise while doing this would be lying.

In transit: HTTPS only, with HSTS including subdomains. The application and the retention worker run in the EU, europe-west4. See what we have not solved for what is not verified about that.

Support access to a synced report

Support cannot read a synced report body by default. Access requires a time-boxed grant that is written to an audit trail, and a request made without one fails with SUPPORT_GRANT_REQUIRED rather than succeeding quietly. The grant is an operator action against a named report, not a standing capability.

Sharing is projected on the server, never filtered in the browser. A recipient receives only the findings and fields their share grants, the withheld ones are not sent and then hidden, they are not sent. In the production check, an outsider on a principal-scoped share received exactly 2 of 14 findings with nothing withheld present in the response, and a non-member requesting a report got a 404 rather than a 403, so they do not learn that it exists.

What we have not solved

This section exists because the alternative is you finding these out later.

Detection recall is 0.441 against our own gate of 0.90. The only corpus written by somebody who had never read the engine, scored once, gave 0.294. Precision is 1.000 and no correct code has produced a finding on any corpus, so what Myrqen reports is trustworthy, but a report with no findings is not evidence that an application is secure, and we would rather say so here than let a clean report imply it. The full methodology and every number.
The report encryption key is a deployment secret, not a KMS-held key. It is documented in our own architecture decision record as something that must move to a key management service. It has not yet.
EU residency is verified for the application and the worker, not end to end. Both run in europe-west4, which is pinned in configuration. The object storage region and each sub-processor's own support tooling have not been independently verified, so we do not claim a complete EU data boundary.
No third party has audited Myrqen. There is no penetration test report, no certification, and no compliance attestation. If you need one, we do not have it.
Only JavaScript and TypeScript are parsed. Python, Java, Ruby, Go, templates, and infrastructure definitions are not analysed at all. Data flow is followed within a single function.
Scanning this repository reports nine candidates of its own, two open redirects, four path traversals, and three verbose error responses. They predate the current release and each one is either being fixed or argued against in writing. We are not going to pretend our own scanner finds nothing in our own code.
Myrqen is a working codename that has passed a preliminary name-collision screen only, and the source is published under a source-available licence rather than an open-source one.

Reporting a vulnerability

Email security@myrqen.cc, or open a private advisory on the repository. Please not a public issue.

Acknowledgement within 3 working days, an initial assessment within 10. Credit is offered by default and declined on request. There is no bug bounty, and there is no legal threat: act in good faith, stay in scope, and give us a chance to fix it first.

The full policy, scope, out of scope, and what not to do against the hosted service, is in SECURITY.md, and the machine-readable version is at /.well-known/security.txt.

A missed or spurious finding is not a vulnerability in Myrqen, and it is the most useful report we can receive. Open a public issue with the Detection defect form, a reproducible case becomes a permanent corpus case.

What leaves your machine, and what does not.