Responsible disclosure

How to report

Email [email protected] with as much detail as you can — ideally a clear reproduction. We aim to acknowledge every report within one business day and to give you a substantive technical reply within seven days.

If the issue is severe and being actively exploited, write URGENT in the subject and we will escalate. If you want to encrypt your report, ask us for a current PGP key in your first message and we will send it back to you.

What we commit to

• Acknowledgement within 1 business day. A real human, not a bot.
• Substantive technical response within 7 days. Either a fix in flight, or a clear explanation of why we believe the report is not actionable.
• Resolution within 30 days for confirmed vulnerabilities of medium severity or higher. Lower-severity issues may take longer; we will tell you the timeline either way.
• Safe harbor. If you are acting in good faith under this policy, we will not pursue or support legal action against you. See the safe-harbor section below.
• Credit, if you want it. We will name you in the release notes for the fix and on this page's hall of recognition once we have one — only if you'd like to be named.

What's in scope

• joinsigil.com and all subdomains
• The Sigil platform application at app.joinsigil.com
• The Sigil MCP gateway at gateway.joinsigil.com
• The Sigil CLI (@sigil/cli npm package + install.sh script)
• Any cryptographic flaw in how we store, wrap, or use credentials
• Any authentication or authorization bypass
• Any way to make an agent take an action its grants do not permit
• Any way to escalate access between agents, between users, or between scopes

What's out of scope

We won't action reports that fall into these categories — but please tell us anyway if you think you've found something genuinely impactful that happens to match a pattern below; we'd rather hear it than miss it.

• Issues in upstream services we depend on — Auth0, Stripe, Azure, Resend, Slack, Google, GitHub, Notion. Report those to the upstream vendor. If a Sigil-specific composition of those services creates a flaw, that is in scope.
• Social engineering of Sigil staff, customers, or vendors.
• Physical attacks against Sigil's offices or property. We don't have offices yet, but the principle stands.
• Denial-of-service that requires sustained high-rate traffic. We rate-limit endpoints aggressively; surfacing a single oversight is in scope, sustained load testing is not.
• Missing security headers on the marketing site that have no concrete exploitation path.
• Self-XSS requiring the victim to paste arbitrary content into their own DevTools.
• Reports generated by automated scanners without a clear demonstration of impact.
• Reports of weak password policies, MFA prompts, or any UX-as-vulnerability framing without an actual security boundary breach.

Rules of engagement

• Test only against your own Sigil account. If you need a second account to demonstrate isolation, create one and use it; don't probe other people's data.
• Never access, modify, or destroy data that isn't yours. If you accidentally see someone else's data, stop, delete any copy you have, and include that fact in your report.
• Don't run sustained load. Demonstrate the issue with the minimum traffic that proves it.
• Don't publicly disclose until we've had a reasonable window to fix the issue — at least 90 days, or sooner if we've shipped a public fix.
• Don't extort or threaten. This isn't bug bounty; it's responsible disclosure. We don't pay for reports today (see "On bug bounty" below), and that's not negotiable.

On bug bounty

We don't currently run a paid bug-bounty programme. We're a small team in private beta. Once the user base and revenue justify it, we will — most likely on HackerOne or Intigriti — and we will honour reports submitted before that programme exists when we set the rules. Until then, we offer credit, a sincere thank-you, and the satisfaction of having protected real people's keys.

How we handle credentials

For context on what's actually at stake when you find a flaw:

• OAuth tokens and integration secrets are stored encrypted under a per-user data-encryption key (AES-256-GCM envelope). That per-user key is itself wrapped by a master key in Azure Key Vault (RSA-OAEP-256). Neither key ever leaves its secure store unwrapped.
• Agent client secrets are stored as SHA-256 hashes only. The plaintext is shown once at agent creation and never recoverable.
• OAuth access tokens from agents are sender-constrained via DPoP (RFC 9449). A leaked token alone is not enough to make an API call; the leaker also needs the agent's private key.
• Recovery codes are stored as SHA-256 hashes. The plaintext is shown once at signup.
• Every state change generates an audit event. Audit logs are append-only and accessible to the user in real time.

If you find a flaw that breaks any of the above invariants, that is exactly the kind of report we want.

Past advisories

We have not issued any security advisories yet. When we do, they will appear here with date, severity, what was affected, what we fixed, and credit to the reporter (if they wanted it).

Hall of recognition

This section will list researchers who have responsibly disclosed issues to us. It is empty today.