If you discover a security vulnerability in seal, please do NOT open a public GitHub issue. Email security@sealedsecurity.com instead.
Please include:
- A description of the vulnerability and its potential impact.
- Steps to reproduce, or a proof-of-concept if you have one.
- The seal version (
seal --version) and OS where you observed it. - Whether you'd like to be credited (and how) once it's fixed.
We aim to acknowledge reports within 3 business days and to ship a fix or mitigation within 30 days for high-severity issues. Severity is judged against the threat model in the project's security documentation.
Seal is pre-1.0. Security fixes are issued against the latest
released version on main. Older versions don't receive backports.
Once we tag a 1.0 release we'll publish a per-version support matrix
here.
In scope:
- Sandbox escapes (an agent reaching files, commands, or network destinations its grant set forbids).
- Manifest signature bypass or forgery.
- Permission-prompt bypass (a prompt that should fire but doesn't).
- Privilege escalation between agent and daemon.
- Credential exposure (API keys, OAuth tokens leaking to logs, session JSON, or untrusted code paths).
Out of scope:
- Misuse of seal where the user has already explicitly granted the capability being used. The threat model assumes the user makes informed grant decisions.
- Denial of service from a misbehaving local LLM provider — seal doesn't promise availability when an upstream provider misbehaves.
- Issues in third-party dependencies that don't affect seal's security boundary (report upstream).
We ask reporters to keep details private until a fix has shipped and been available long enough for users to upgrade (typically 14 days post-release). We'll credit you in the release notes unless you prefer otherwise.