Security

Myna runs on Railway: the application, a managed PostgreSQL database, and S3-compatible object storage for assets. All public domains (myna.sh, app.myna.sh, and api.myna.sh) are served over HTTPS. Database backups and provider-managed storage follow Railway’s configured security and retention controls.

The full list of infrastructure providers is on the Subprocessors page.

• There are no Myna passwords: sign-in is GitHub OAuth only, with CSRF-protected, state-validated redirects.
• Browser sessions use opaque random tokens stored server-side only as SHA-256 hashes, in cookies that are HttpOnly, Secure, and SameSite=Lax, expiring after 30 days. You can list and revoke sessions, individually or all at once, from the dashboard.
• API keys are scoped (by permission and by project), optionally expiring, revocable, and attributed. The secret is displayed once at creation; only its hash is stored, so keys cannot be recovered — only rotated.
• Preview links use the same hashed-token scheme and are revocable and expiring.
• The CLI stores its credentials in the operating system keychain where available, falling back to a file readable only by your user.

• GitHub OAuth tokens and webhook signing secrets are encrypted at rest with AES-256-GCM under a master key held only in the server environment.
• Authorization headers, cookies, tokens, and request bodies are redacted from server logs; audit metadata passes through an explicit redaction list.
• IP addresses in audit records are stored only as keyed one-way hashes — raw IPs are not persisted there.
• Every repository query is scoped to the requesting tenant, and cross-tenant isolation is covered by tests.

• State-changing, cookie-authenticated requests require an allow-listed Origin header; CORS uses an exact-origin allowlist with credentials.
• Rate limits are enforced independently for authentication, the public content API, previews, sessions, and API keys.
• Uploads are validated for size and MIME type; executable files and SVG images are blocked, and assets are served with safe response headers.
• Outbound webhooks are signed with per-endpoint HMAC-SHA256 secrets and timestamped headers so receivers can verify authenticity, and webhook delivery is protected against SSRF (no redirects, internal addresses blocked, 10-second timeout).
• Rendered Markdown is sanitized and raw HTML is disabled.
• Security-relevant actions — sign-ins, key changes, schema, content, asset, publish, webhook, member, and billing mutations — are recorded in an audit log.

• Protect the GitHub account you sign in with; enable two-factor authentication. A passkey is a faster way into Myna, not a replacement for that — GitHub remains a valid way in, so your account is only ever as secure as it is.
• Create one API key per agent or integration, scope it minimally, rotate it periodically, and revoke unused keys.
• Treat MCP configuration files and CI secrets containing myna_sk_… tokens as sensitive.
• Verify webhook signatures at your receiving endpoints, and keep those endpoints patched and private.
• Review your organization’s members and roles periodically, and review agent-produced change sets before publishing.

If you believe you have found a vulnerability in Myna, we want to hear about it. Email [email protected] with a description of the issue, steps to reproduce, and any relevant URLs, request IDs, or proof-of-concept material. We will acknowledge your report within 3 business days and keep you informed as we investigate and fix.

While researching, we ask that you:

• Only test against accounts and organizations you own.
• Never access, modify, or delete other customers’ data — if you encounter it, stop and report immediately.
• Avoid denial-of-service testing, spam, and social engineering of our team or users.
• Give us reasonable time to fix the issue before public disclosure.

We will not pursue legal action against good-faith security research that follows these rules, avoids privacy violations and service disruption, and gives us reasonable time to investigate and remediate. This safe harbor does not authorize access to other users’ data or conduct prohibited by law. We do not currently run a paid bug bounty program.

If a security incident affects your data, we will notify affected customers without undue delay and within the periods required by applicable law, with what we know, what we are doing, and what you should do.

Security reports and questions: [email protected]. For privacy matters, see the Privacy Policy.