We build a defensive platform; we take reports of its weaknesses seriously. This page describes what is in scope, what is out of scope, how to reach us, the SLAs we hold ourselves to, and the safe-harbour clause for researchers acting in good faith.
Authentication, authorisation, tenant isolation, scan pipelines, the Marketplace, the API surface, the IDE extension, the CLI, the MCP server, and the public web properties on safeguard.sh and its subdomains.
Griffin, Eagle, Lino, and their hosted inference endpoints. Vulnerabilities in trace emission, attestation, refusal behaviour, or guardrail evaluation are in scope.
The air-gapped appliance and its update channel. If you are a sovereign customer with an Aegis deployment, vulnerabilities in the appliance itself are in scope under a separate co-ordinated channel — write to security@safeguard.sh for the appropriate path.
Compromise paths through our build, signing, or release pipeline. The SBOMs and attestations we publish for our own binaries are themselves in scope.
Missing security headers without an exploit chain, theoretical issues without a working proof of concept, or best-practice deviations that do not reduce to a CIA-triad impact.
Rate-limit testing, flood traffic, brute-force credential stuffing, or any test whose primary signal is volume. Coordinate with us before any load-style assessment.
Phishing, vishing, pretexting, or any test targeting people rather than systems. Out of scope without prior written authorisation from our security team.
Vulnerabilities in upstream cloud providers, open-source components, or third-party SaaS we use should be reported to the relevant maintainer or vendor first. We will help with co-ordinated disclosure where appropriate.
Email security@safeguard.sh with a clear description of the issue, the steps to reproduce, the impact, and any supporting artefacts. Use English where possible. A PGP key is available on request — ask in your first message and we will send the key and a fingerprint over a separate channel.
Please do not file security issues on the public forum or in GitHub issues. Use the inbox.
Critical issues are remediated as a fire-drill; lower-severity issues land on the next scheduled release train. We update you weekly until the fix ships.
We will not pursue civil or criminal action against researchers who, in good faith, comply with this policy. That includes: testing only against in-scope surfaces, avoiding privacy violations and service degradation, not exfiltrating data beyond what is needed to demonstrate impact, keeping the issue confidential until we have shipped a fix, and giving us a reasonable opportunity to remediate before public disclosure.
If you are unsure whether a planned test crosses a line, ask first. We are reachable, and we would rather have a five-minute conversation than retroactively read about it.
Researchers whose reports lead to a fix are acknowledged publicly on our security researchers page — unless they ask to remain anonymous, which we honour.
View the hall of fameThe wider surface area for security and the commitments we hold ourselves to.