Maestro asks users to paste an API key — a bearer credential that can spend their money — into a web form. We take that seriously, and we would rather be believed than impressive.

Maestro is pre-1.0 and under active development. Only the main branch receives security fixes. There are no maintained release branches, and no backports to tagged versions.

Do not open a public issue, discussion, or pull request for a security vulnerability.

Report it privately, one of two ways:

1. GitHub private vulnerability reporting — use the Report a vulnerability button under the repository's Security tab. This is the preferred channel.
2. Email — yigiterdogan023@gmail.com, with enough detail to reproduce the issue.

Please include the affected component, reproduction steps, the impact you believe it has, and any proof-of-concept you have. If you can, tell us which commit you tested against.

Maestro is maintained by one person in their own time, so please calibrate accordingly:

• We aim to acknowledge a report within 7 days.
• We aim to give you an assessment and a remediation plan within 30 days.
• We will tell you when a fix ships, and credit you in the release notes unless you would rather stay anonymous.

Please give us a reasonable chance to fix the issue before disclosing it publicly.

We will not pursue legal action against anyone who researches in good faith, stays within their own account, avoids degrading the service for others, and does not access or destroy another user's data.

So that no one reports a bug expecting something we do not offer:

• We hold no security certification — no SOC 2, no ISO 27001. We are not audited.
• We have not commissioned an external penetration test.
• We run no bug bounty programme. There is no payment for a report.
• Billing currently runs through a mock payment provider (BILLING_LIVE = false). Do not enter a real card number, in production or in development. Card-handling code is not yet PCI-scoped, and a real PAN entered against the mock provider is a real risk you take on yourself — not a vulnerability to report.

No system is perfectly secure, and a small project is no exception.

The following are known, documented, and not vulnerabilities:

• Missing rate limiting on non-authentication endpoints (Redis-based limiting is on the roadmap).
• The mock payment provider accepting any Luhn-valid card number. That is what a mock does.
• Findings from automated scanners with no demonstrated exploit path.
• Reports that require a compromised host, a compromised database, or physical access.
• Social engineering of the maintainer.

The short version:

• BYOK API keys are encrypted with AES-256-GCM before they touch a disk, never returned to the browser, never written to a log — not even at debug level — and never exposed to Marketplace agents.
• Passwords are hashed with Argon2. Sessions use short-lived JWT access tokens with separate refresh tokens. The refresh token is delivered as an HttpOnly, Secure, SameSite cookie and never appears in a response body; the access token is held in memory by the page and never persisted. Neither reaches localStorage, so an XSS foothold cannot exfiltrate a durable session. WebSocket connections require the same authentication as the HTTP API.
• User data is isolated by user id at the query layer in all three stores: PostgreSQL, MongoDB, and Qdrant. A retrieval cannot surface another account's memories, by construction rather than by convention.
• Agents are contained by iteration ceilings, review-loop ceilings, and a per-task wall-clock timeout. Untrusted content fetched from the web or read from a document is delimited and marked as data. Marketplace submissions are scanned for prompt-injection patterns before they go live — treat that as a safety net, not a guarantee.
• Card PANs are never stored, logged, or returned. Only brand, last four digits, and expiry persist.

The full policy lives in CLAUDE.md §9, and the user-facing version — with the reasoning behind each decision — is on the platform's /security page.

If you are auditing this repository rather than using it, you will want to know how much the commit history can be trusted. Precisely this much:

• History is not squashed or collapsed. Squash merging is disabled repository-wide, so a pull request lands as its own commits and none are rewritten into a single one. merge and rebase are the only merge methods main accepts.
• main has been protected since 2026-07-12. Force-pushes and branch deletion are blocked, and every change lands through a pull request with required review and status checks. Commits dated before 2026-07-12 were made on an unprotected branch — nothing attests that they were not rewritten before that date, so treat them as the maintainer's word rather than as evidence.
• The repository administrator can bypass every rule above. The ruleset grants the admin role an unconditional bypass, so a direct push, a force-push or a branch deletion on main is technically possible for that one account — the rules bind contributors, not the owner. This is the honest ceiling on everything in this section: what protects the history against the maintainer is the signature chain below and GitHub's own audit log, not the branch rules.
• Commits from 28e456c (2026-07-29) onward are SSH-signed and show as Verified on GitHub; release tags from v0.1.3 onward are signed too. Everything before that commit is unsigned — including the commit that first added this section — which means the author name on those commits is asserted, not proven. Verify for yourself with git log --show-signature.
• Signatures are not yet enforced by a branch rule. An unsigned commit on main is therefore still possible; check rather than assume. Requiring signatures is on the roadmap and will be announced here when it lands.

We would rather write this down than let a clean-looking log imply a guarantee it does not carry.