Pitwall is pre-1.0. The API may change in backwards-incompatible ways between minor releases. When a release reaches end-of-life, its security advisories are archived but not backported.

Please do not open public GitHub issues for security vulnerabilities.

Private disclosure is preferred and expected. You can report vulnerabilities through:

• GitHub Private Vulnerability Reporting — use the Security tab on the repository, then "Report a vulnerability". This routes directly to the maintainers without exposing the details publicly.
• Email — no public security mailbox has been approved yet; use GitHub Private Vulnerability Reporting until one is listed here

The project targets acknowledgement within 72 hours and a substantive update within 14 days. These are best-effort targets, not an SLA.

For non-sensitive security questions or process questions, open a regular GitHub Discussion.

This policy covers the following Pitwall components and their security boundaries:

Pitwall has two operational modes with fundamentally different trust requirements:

Pitwall has one operator, one RunPod account, and one shared budget; it is not a multi-tenant authorization system. Bearer scopes limit what a credential can do but do not add tenant ownership or row-level isolation.

Production deployments must:

1. Set PITWALL_API_TOKEN and PITWALL_ADMIN_SECRET; non-loopback API startup refuses to proceed without both.
2. Set PITWALL_WEBHOOK_SECRET; non-loopback webhook startup refuses to proceed without it.
3. Use scoped bearer tokens for delegated callers and reserve the all-scopes token for operators.
4. Bind published ports to loopback or a private interface and terminate TLS at a trusted proxy.

See the full trust model and security controls in:

• README — Security and trust model
• docs/sdlc/14-security.md

The alpha MCP server is supported over local stdio only. Every network transport is rejected because HTTP authentication is not implemented. Local process access is therefore the MCP trust boundary.

Agent Routing delegates work to locally installed provider CLIs. Those children inherit the operator's filesystem, process, credential, and network authority subject to each provider's own sandbox. The default SUBAGENT_MODEL_ROUTING_UNRESTRICTED=1 profile permits unattended child execution and can bypass interactive approval prompts; set it to 0 when the selected harness can operate under its restricted policy. Treat prompts, generated patches, provider output, lifecycle hooks, route files, and workflow definitions as untrusted input.

Run records and output are private local state, but can contain source or secrets printed by a child. Prompt bodies are retained only when explicitly requested. No automatic retention period is imposed; inspect and remove records with the documented model-routing runs commands. Plugins and the source installer expose the same local execution boundary as direct shims. Optional provider installation is an explicit, confirmed mutation surface and never performs provider login.

Custom and self-hosted endpoints remain operator-supplied. API keys stay in named environment variables; route JSON stores the variable name, never the value. The optional Pitwall event receiver binds only to loopback and writes a user service only when explicitly requested; enabling that service is a separate action.

Credential roles are deliberately separate:

• PITWALL_API_TOKEN is the broker's all-scope server credential and a legacy Agent Routing fallback.
• PITWALL_AGENT_ROUTING_API_TOKEN is the preferred read/spend client token for route metadata and proxy traffic.
• PITWALL_AGENT_ROUTING_SUBSCRIPTION_TOKEN is the preferred webhook:admin token used only to create a receiver subscription.
• PITWALL_WEBHOOK_SECRET signs inbound broker webhooks and is only a legacy receiver fallback.
• PITWALL_AGENT_ROUTING_WEBHOOK_SECRET is the preferred receiver verification secret; PITWALL_WEBHOOK_SECRET_ENV may explicitly name a different environment variable.

The detailed component threat model is maintained in packages/agent-routing/SECURITY.md, but disclosure and advisory coordination remain here under one Pitwall security home.

• Multi-tenant ownership isolation is not provided; report authorization bypasses against the documented bearer scopes, but not the absence of tenant-specific row ownership.
• Third-party services that Pitwall calls (RunPod API, Tailscale, Redis, PostgreSQL). Report issues with those services to their respective vendors.
• Social-engineering attacks against operators.
• Provider-model behavior, provider subscription policies, and documented unrestricted local execution are out of scope unless Agent Routing broadens authority beyond the documented boundary or mishandles arguments, credentials, state, or installer verification.