Team Suzie is pre-1.0. Security fixes are applied to the latest main. There are no back-ported patches at this stage.

Please do not file security vulnerabilities as public GitHub issues.

Email: security@teamsuzie.com (or the contact listed on the repo maintainer's profile if that address is unavailable).

Include:

• A description of the vulnerability and its impact.
• Steps to reproduce.
• The affected version or commit SHA.
• Any suggested mitigation.

You can expect an initial response within 72 hours. We will coordinate a disclosure timeline with you before publishing any fix.

In scope:

• Auth bypass, privilege escalation, tenant data leakage across scopes.
• Injection vulnerabilities (SQL, Cypher, command, prompt injection in skill templates).
• Secrets accidentally committed to the repo.
• Supply-chain risks in declared dependencies.

Out of scope:

• Vulnerabilities in downstream agent runtimes (OpenClaw, LangGraph, etc.) — report those upstream.
• Denial of service from unthrottled self-hosted deployments (configure your own rate limits).
• Issues that require physical access to the host.

When deploying Team Suzie, at minimum:

• Set COOKIE_SECRET and CONFIG_ENCRYPTION_KEY to strong random values.
• Do not run with the default Postgres / Neo4j passwords from .env.example.
• Put the admin app behind authentication; it exposes privileged config operations.
• Keep the LLM proxy internal — do not expose it to the public internet without an auth layer.
• Set INTERNAL_SERVICE_KEY to a strong random value in any deployment that runs more than one OSS service, and treat it as tier-0 — anyone with this key can invoke internal-only endpoints.

For anyone writing or reviewing code:

• docs/SECURITY_MODEL.md — the three auth lanes (browser session, user bearer, agent/service bearer), when to pick each, and how request-id / actor / org attribution works end-to-end.
• docs/UPLOADS.md — rules and shared helpers for any file-upload endpoints (OSS ships with none today; this is what you follow when you add one).