Coordinated disclosure
Report a bypass.
Our published eval misses 255 of 263 labelled injections. We are not defensive about that, and we would rather hear about a bypass than discover it in a customer’s audit log. This is what happens when you send one.
What happens to your report
Acknowledged within 3 business days
A human reply confirming we have it and whether we can reproduce it yet. If we cannot reproduce it we will say so and ask for what is missing rather than closing it.
Reproduced as a test case
A confirmed bypass becomes a failing test before it becomes a fix. That is the same loop the product uses for QA sampling and release gates: the finding is encoded as something that fails, so the fix is verifiable and the regression is permanent.
Added to the eval corpus
The phrasing goes into evals/injection/corpus/, which means it counts against our published recall from that point on. A bypass you report makes our public number worse until we fix it, and the number is regenerated either way.
This is the part most disclosure policies leave out. Adding misses to the measurement is what stops the eval drifting into a set of things we already pass.
Fixed, or documented as not-fixed
Some bypasses are cheap to close. Some are the fundamental limit of pattern matching, and closing them would cost false positives — which in this product means blocking legitimate credit decisions. When that is the trade we will say so publicly rather than quietly leaving the gap.
Re-measured and republished
The eval page is regenerated with the new corpus and a new run date. If your report changed the numbers, the changed numbers are what gets published.
Credited, if you want to be
We will name you on the eval page, or keep you anonymous, entirely as you prefer. Ask and it is done either way.
What makes a report useful
- The exact input string. Copy-pasteable. Whitespace and unicode matter — the scanner normalises homoglyphs, so an evasion that relies on them is interesting and easy to lose in retyping.
- Which stage you believe it defeats. Injection scanning, PII redaction, toxicity, safety scoring, or the rule engine itself.
- What you expected versus what happened. A verdict that should have been BLOCK and came back APPROVE is the clearest form.
- Version or commit if you have it.
You do not need a working exploit chain. A phrasing that gets past the scanner is enough — that is the finding.
Scope
In scope: the Sentinel software and its published artefacts — the decision pipeline, the security stages, the rule engine, the audit chain and Proof-of-Agent construction, the evidence verifier, and this website.
Out of scope: a customer’s own self-hosted deployment and their configured policy. Sentinel enforces the rules you write; a rule that permits something it should not is a policy issue rather than a product vulnerability. We will still help you work out which one it is.
What we ask
Test against your own deployment or a local install, not against another institution’s. Do not access data that is not yours. Give us a reasonable window before publishing — we will not use that window to argue about whether it counts.
We have no bug bounty. We are one person pre-revenue and paying for findings is not currently honest to promise. If that changes, this page changes.
What we will not do
- Argue that a bypass is out of scope because it is “theoretical”. If it gets through, it gets through.
- Quietly fix it and leave the published numbers stale. The eval is regenerated with the corpus that includes your finding.
- Send legal correspondence to a good-faith researcher. No exceptions.
- Claim the problem is now solved. Pattern matching against known attack shapes has a ceiling, and the eval page says so in the headline.
Coordinated disclosure
Send it.
The input string and what you expected is enough to start. Acknowledgement within 3 business days, from the person who wrote the code.