Security: how your code and account are protected

The model in one page

• Least capability, by construction. Signoos reads your repository. The one thing it can write is a finished solver patch, through a single code path, as a commit on a branch with a pull request — never a merge, never a force-push over work that moved, and not at all where a team leader has switched pushing off. It leaves no comment on your repository.
• Least data, by consent. Code is read only inside the folders you granted, and every read path enforces the same grant, failing closed.
• Least credential, by design. No GitHub token is stored; provider keys are sealed and never returned; the sandbox runs with no credentials at all.
• Untrusted means untrusted. Repository content, review text and sandbox output are treated as data everywhere they are processed — never as instructions to the system handling them.

Code is read only with consent

Code access is off until a project explicitly turns it on, folder by folder. The grant is enforced in one choke point that the search index, the localizer, the repository mirror and the file browser all pass through; matching is per path segment, so frontend/ never implies frontend2/. When the check cannot be evaluated, the answer is no. AI jobs see the filtered view only, and a diff with files withheld says how many — the AI processing page lists every payload.

No stored GitHub credential

Repository access goes through the Signoos GitHub App. No token, password or key for your repository is ever stored: each installation is exchanged for a token that is scoped to the repositories you chose and expires within the hour, minted at the moment of use. Uninstalling the App severs access immediately, on GitHub's side as well as ours.

Accounts and sessions

• Sessions are httpOnly, __Host--prefixed cookies — never readable by page scripts, never sent cross-site, never stored in localStorage. The full cookie inventory is in the Privacy Policy, and all seven are strictly necessary.
• Two-factor authentication is supported, with recovery codes; the enrolment QR is rendered locally in your browser, so the shared secret never leaves it.
• Privileged actions — changing a password, revoking devices — require recently re-proven identity, not just a live session.
• State-changing requests carry a CSRF token in a header; sign-in flows are rate-limited and bot-protected; sessions can be listed and revoked individually from your account.

Tenancy and data access

All data access flows through the API, which checks project membership on every request — client applications have no direct database access at all, enforced by deny-by-default rules rather than convention. What a member can see is decided by their role, down to a files-only role that reaches the repository browser and nothing else. Provider API keys a team brings are sealed with envelope encryption and are never returned by any endpoint, in any form.

The execution sandbox

Where a team configures test execution for the solver, the repository's own declared commands run against the patched copy in an ephemeral container that holds no credentials — no GitHub token, no provider key, no service identity with roles to abuse. Everything the sandbox returns is treated as data: test output cannot instruct the system that reads it. Without a sandbox configured, nothing is executed, and the product says so rather than implying otherwise.

Transport and content security

• signoos.com is served exclusively through our edge, which stamps a nonce-based Content-Security-Policy on every response; the origin answers only through it.
• The application ships zero inline scripts — enforced by a build-time guard, and by the CSP that would refuse them anyway.
• The client renders untrusted text — code, markdown, AI output — through tokenising renderers with raw HTML disabled; external URLs from third-party systems are validated before they can become links.

Device credentials

The @signoos/cli and @signoos/mcp clients authenticate with a per-machine rotating refresh token, hardened to your OS user; access tokens live in process memory only. The credential carries task-read scope — settings, consent, team and billing are unreachable from a device regardless of what any prompt says. Devices are listed and revocable from your account, effective on the next request, and a credential ever used twice revokes itself and emails you.

Reporting a vulnerability

If you believe you have found a security issue in Signoos — the web application, the API, the CLI or the MCP server — write to [email protected]. The disclosure policy, including what helps us act quickly and what is out of scope, is published at /.well-known/security.txt. We acknowledge reports, tell you what we find — including when we conclude an issue is not exploitable, and why — and ask for reasonable time to remediate before public disclosure.