Security

Architecture

The service has three parts, and the boundary between them is the security model:

• The server is a pure state store. It owns suites, cases, plans, runs and results. It never executes customer code — there is no code path that could.
• The desktop Runner executes your repository's scripts locally and posts results back. It holds no source of truth and stores no credentials of ours.
• The web app handles sign-in, authoring, planning and reading history.

Data protection

• All traffic is encrypted in transit with TLS.
• Data is encrypted at rest by our infrastructure providers.
• Everything runs in AWS eu-west-1 (Ireland). Service data does not leave that region except to the subprocessors listed on our Subprocessors page.
• Uploaded run artifacts — screenshots, logs, reports — are stored privately. Nothing is served from that store directly; access goes through short-lived presigned URLs, so a link that leaks expires rather than standing open.

Access control

• Every request is authorised the same way: project, then organization, then membership. There is one rule, applied in one place, rather than a per-route judgement call.
• Roles are enforced server-side. A client that asks for something its role does not permit is refused by the server, not merely hidden from in the UI.
• Removing a member revokes access immediately. Their past verdicts stay in the organization's history, because deleting them would falsify the record.
• Sign-in is by Google or your own enterprise SSO. We never see or store a password, because we do not have one to store.

Deletion and recovery

Deleting a suite or a case is reversible for 90 days, then an automated job destroys it permanently. That window exists because the most common data loss in a test management tool is someone deleting the right thing for the wrong reason.

The desktop app

• macOS builds are not yet notarized, so macOS will warn you on first launch. Apple Developer certification is in progress. We would rather say this than have you discover it.
• Updates are delivered over HTTPS and verified before installation. Only our release pipeline can publish to the update feed.
• The app runs the scripts your repository declares, and nothing else. It has no mechanism for us to push code to your machine outside of a signed application update.
• Crash reports are rebuilt, not scrubbed. The Runner reports its own crashes to Better Stack, and the event is reconstructed from a fixed allowlist: file paths become opaque build identifiers, the error message is replaced with a fixed string, and source lines, local variables and function names are dropped. A field nobody allowed cannot be sent. There is no usage analytics, no session replay and no native crash dump. What a report contains is listed in full on our Subprocessors page.

Server errors

Errors on our own servers go to the same provider, rebuilt from the same kind of allowlist. The message and stack are kept because that is our code, but the request that caused the error is never attached — no body, no headers, no query string, no cookies, and no user or organization identifier — and messages are scrubbed for credentials, email addresses and the values a database quotes back in a constraint error.

AI features

Plan review and bug drafting invoke a coding agent CLI that is already installed on the user's machine, under that user's own account with the provider. Requests go from that machine to that provider directly. They do not pass through our infrastructure, and we never see them. Adding an AI provider to your approved vendor list is a conversation between you and them; we are not in the path.

What we do not claim

We are a small company and we would rather be accurate than impressive. We do not currently hold SOC 2 or ISO 27001 certification, and we have not commissioned an external penetration test. If either is a requirement for your organization, tell us — knowing that it blocks a deal is how it gets prioritised.

Reporting a vulnerability

Email security@enyon.dev. Include enough detail to reproduce the issue, and give us a reasonable chance to fix it before disclosing it publicly.

We read every report and we will reply to yours. We are deliberately not quoting a response time: we are a small team, and a clock we might miss is worth less to you than one we do not set. What we will do is keep you posted while we work on it, and agree a disclosure timeline with you rather than impose one.

We will not pursue legal action against anyone acting in good faith under this policy. We do not run a paid bounty programme, but we will credit you if you would like us to.

Breach notification

If a personal data breach affects your organization's data, we will tell you within 72 hours of becoming aware — with what we know at the time, rather than waiting until the picture is complete. The full commitment is in our Data Processing Agreement.