Security

The short version#

What we don't claim#

Solar has no SOC 2 report, no ISO 27001 certificate, no HIPAA attestation, and no PCI certification. Nobody has audited us. We are not going to imply otherwise with a badge.

If your procurement process needs an audited attestation, we do not have one today. Current position on getting one: [COMPLIANCE ROADMAP — or say there isn't one]. We would rather tell you that now than in month three of a deployment.

What we can give you is this page, a straight answer to a security questionnaire, and access to the people who wrote the code.

Signing in#

Accounts use an email address and a password. Passwords are hashed with bcrypt before they are stored. The plaintext password is never written to the database, never logged, and cannot be recovered by us — a reset issues a single-use, expiring token instead.

A successful sign-in issues a JWT session token to your browser or app. Deleting your account invalidates your sessions.

Two-factor authentication and SSO/SAML: [2FA AND SSO STATUS — state plainly whether they exist today]. Password strength requirements: [PASSWORD POLICY].

Who can see what#

Access is scoped by organisation and by project membership. You see the projects you are a member of. Being in one organisation gives you nothing in another.

Clients are deliberately narrower. A client invited to a project sees only the issues explicitly marked client-facing for that project, plus the portal sections the project owner enabled — dashboard, board, tickets, hours, knowledge base and so on are individually switchable. Internal issues, internal comments, and time notes not posted to the client are not returned to a client session at all.

Client invitations are single-use tokens with an expiry.

Internal access to production data by our own team is governed by [INTERNAL ACCESS POLICY — who can reach prod, and how it is approved].

Agent and MCP tokens#

The most important security property in Solar: an agent never gets more than the human it belongs to.

• MCP tokens are issued per user. An agent holding a token acts with exactly that user's permissions.
• Tokens are stored as hashes, not in plaintext. The value is shown to you once, at creation.
• Each token carries an explicit permission set, so you can issue one that reads but cannot write.
• Every token records when it was last used, which makes an unused or stale token obvious.
• Revoking a token cuts access immediately. Deleting your account revokes all of them.
• MCP requests are logged, so you can see what an agent actually did rather than guessing.

Outbound webhooks are logged the same way, with their request and response recorded per project.

In transit and at rest#

All traffic to Solar — web app, mobile apps, API and MCP — runs over HTTPS. Connections from the application to the database are encrypted.

Encryption at rest is provided by the platforms we run on rather than implemented by us. The exact guarantees are theirs to state: [LINK NEON + VERCEL ENCRYPTION-AT-REST STATEMENTS]. We are not going to paraphrase another company's security posture as though it were ours.

Where it runs#

The full processor list, and what each one receives, is in the Privacy Policy.

Third-party credentials#

If you connect GitHub, we store the OAuth access token, its refresh token, its expiry, and the scopes you granted, so Solar can act on the repositories you allowed. Connecting is optional, and disconnecting revokes it on our side.

Encryption of stored OAuth tokens: [CONFIRM GITHUB TOKEN ENCRYPTION IS LIVE, NOT PLANNED]. Flagging this explicitly rather than asserting it — the schema notes encryption at runtime, and that claim should be verified against the running code before this page goes out.

Our own secrets — database URLs, API keys, signing keys — are held as environment variables in the hosting platform and are not committed to the repository. Key rotation cadence: [KEY ROTATION POLICY].

File attachments#

Attachments go to Vercel Blob. We record the filename, size, MIME type, storage path, uploader and project, and whether the file was explicitly marked public. Attachments are scoped to the project they were uploaded to.

Anything marked public is reachable by anyone with the URL — that is the point of the flag, and it is worth knowing before you tick it. Virus scanning of uploads: [UPLOAD SCANNING STATUS]. Maximum upload size: [UPLOAD SIZE LIMIT].

Audit trail#

Solar keeps a lot of history, and it is as useful for security as it is for project management:

• An activity log and per-issue history recording who changed what and when.
• Status transition history for every issue.
• MCP request logs, per token — what an agent called, and when.
• Webhook request and response logs, per project.
• A record of AI generations: which action ran, for which project and user.
• Revision history on knowledge base articles.

Retention of these logs: [LOG RETENTION WINDOW]. Whether an organisation admin can export them: [AUDIT EXPORT AVAILABILITY].

Analytics posture#

Product analytics is PostHog on its EU cloud. It is configured conservatively on purpose:

• Autocapture is off — we do not hoover up every click and input on the page.
• Session replay is off — there is no recording of your screen.
• URL query strings are stripped before an event is sent, so search terms and other free text in a URL never leave the client.
• What is captured: the page or screen path, your user id, email, name, and your organisation id and name.

No advertising SDKs and no cross-site or cross-app tracking are present in the web app or the mobile apps.

How we build and ship#

Changes land through pull requests on GitHub and deploy through Vercel, so every production change is traceable to a commit. Database changes go through migrations rather than ad-hoc SQL against production.

Dependency and vulnerability scanning: [DEPENDENCY SCANNING SETUP]. Required code review before merge: [REVIEW POLICY]. Penetration testing: [PEN TEST STATUS — say none if none].

Backups and recovery#

The database is backed up by Neon. Backup frequency and retention: [BACKUP FREQUENCY] / [BACKUP RETENTION WINDOW]. Recovery objectives: [RTO / RPO]. Last restore test: [RESTORE TEST DATE — or say untested].

Backups are our disaster recovery, not your archive. Export anything you cannot afford to lose.

If something goes wrong#

If we suffer a breach that affects your data, we will tell you what happened, what data was involved, what we did about it, and what you should do — in plain language, without waiting for it to become a press problem.

Notification target: [BREACH NOTIFICATION WINDOW — e.g. 72 hours]. Where regulators must be told, we tell them within the statutory window. Status page: [STATUS PAGE URL].

Reporting a vulnerability#

Found something? Tell us before you tell anyone else, and we will not come after you for looking.

Email [SECURITY CONTACT EMAIL] with enough detail to reproduce it. We acknowledge within [ACKNOWLEDGEMENT TARGET] and give you a first assessment within [TRIAGE TARGET].

Ground rules, so we can say yes:

• Test against your own workspace, not someone else's data.
• No denial of service, no spam, no social engineering of our staff or customers.
• Do not exfiltrate data. If you can prove the bug with one record, stop there.
• Give us [DISCLOSURE WINDOW] before publishing.

Bug bounty: [BOUNTY POLICY — say none if none]. We credit reporters who want the credit.

Your part#

Most incidents in a tool like this are not exotic. They are a shared password, a token left in a script, or a client accidentally given the wrong view. Things worth doing:

• Use a unique password and a password manager.
• Issue one MCP token per tool, with the narrowest permissions that work, and revoke the ones you stopped using.
• Check what your client portal actually shows before you invite a client to it.
• Remove people from the organisation the day they leave, not the month after.
• Think before you mark an attachment public.

What we do with your data is on the privacy page. The agreement itself is on the terms page.