Stele

Security and Responsible Disclosure

Last updated May 27, 2026.

Stele is a single-operator, beta-stage service. We take security seriously and welcome reports from independent researchers. This page explains how to report a vulnerability, what is in scope, what to expect from us in return, and the safe-harbor commitments that apply if you follow this policy in good faith.

How to report

Email security@stele-ai.dev with:

  • a description of the issue and the impact you believe it has;
  • the URL, endpoint, or component affected (for example, app.stele-ai.dev, the stele CLI, or the Claude Code plugin);
  • a minimal reproduction (steps, request payload, or proof-of-concept);
  • your name or handle, if you would like credit.

You may encrypt sensitive reports with our PGP public key (fingerprint: F8D0 A410 AB07 E235 DF43 5F60 34A3 BECC 2EA4 25BC). Plain email is also fine.

We prefer not to use issue trackers, social media, or chat for initial disclosure.

What we commit to

  • Acknowledge your report within 3 business days.
  • Triage and confirm or deny the issue within 10 business days of acknowledgement.
  • Fix critical issues (remote code execution, authentication bypass, data exposure across tenants) within 30 days of confirmation, or sooner where reasonably practical.
  • Fix high-severity issues within 60 days of confirmation.
  • Keep you informed of progress and let you know when a fix has shipped.
  • Credit you in a public acknowledgements list, if you want credit and the report is in scope.

In scope

  • stele-ai.dev, www.stele-ai.dev, and app.stele-ai.dev.
  • The Stele command-line interface and its installer.
  • The Stele Claude Code plugin and its MCP server.
  • Stele's Supabase configuration: row-level security policies, database functions, storage access rules.

Out of scope

The following are generally not in scope and will not be eligible for credit:

  • vulnerabilities in third-party services we use (report directly to Supabase, Vercel, GitHub, Google, Stripe, or Resend);
  • automated scanner output without a working proof of concept;
  • denial-of-service through high request volume or resource exhaustion;
  • physical attacks, social engineering of Stele staff, or attacks on our personal devices;
  • email security findings (SPF, DKIM, DMARC) that do not lead to a concrete impersonation or takeover scenario;
  • best-practice notices that do not have a demonstrable security impact (missing security headers, cookie flags on non-sensitive cookies, etc.);
  • vulnerabilities that require a victim to install malicious software or grant unusual OS-level access.

Rules of engagement

If you are testing Stele in good faith, please:

  • only access accounts and projects that you own or have explicit permission to test;
  • do not modify or destroy other users' data, and do not exfiltrate more data than is necessary to demonstrate impact;
  • do not run automated scans that materially degrade availability for other users;
  • give us a reasonable opportunity to remediate before any public disclosure (90 days is the default; we will discuss a longer or shorter window with you when warranted).

Safe harbor

Stele will not pursue civil action or refer good-faith security research that complies with this policy to law enforcement. We consider activity that follows this policy to be authorized under the U.S. Computer Fraud and Abuse Act and similar laws.

If a third party initiates legal action against you for research conducted in compliance with this policy, we will make our authorization clear to them.

Bounty

Stele does not currently offer monetary bounties. We do offer public credit for unique, in-scope reports, and we genuinely appreciate the help.

Contact

Vulnerability reports: security@stele-ai.dev. General questions about this policy: legal@stele-ai.dev.