Independent Security Research

AI Safety Vulnerability Disclosure

A coordinated disclosure to a major LLM chat platform's security team, covering prompt-injection techniques that bypass safety-policy enforcement.

What this page deliberately does not contain: exploit templates, reproduction steps, or one sensitive secondary finding reported separately to the vendor's Trust & Safety team. The full technical report was submitted under TLP:AMBER (restricted distribution) and remains unpublished while the finding is unpatched and unacknowledged. What follows is the process, not the payload.

Scope

Target: a major LLM chat platform's production web interface. Approach: black-box testing with no privileged access or special tooling — everything reproducible through the normal chat UI a real user has. Focus: whether adversarial framing of a single user message could get the model to override its own safety-policy enforcement.

Findings, at the level I can responsibly publish

2independently-worded prompt-injection technique families, each a policy-enforcement bypass

1message

8documented test sessions, each backed by the platform's own share links as reproducibility evidence

0prohibited content requested or generated during any test

Both technique families reproduce with a single ordinary user message and no elevated access — no jailbroken client, no API-level tricks, nothing outside what any user of the product could type. A separate, more sensitive finding concerning the platform's classification of a specific safety-policy category was reported through the same channel and flagged for direct review by the vendor's Trust & Safety team; it is intentionally omitted here in full, including from this summary, regardless of the embargo status of the rest of the report.

Why I'm not publishing more

A responsible disclosure report that leaks its own payload isn't responsible — it's a public jailbreak with a cover letter. The report was marked TLP:AMBER precisely because I intended it for the vendor's security team, not for general distribution, and an unacknowledged, unpatched finding stays that way until the vendor has had a real chance to fix it. Some categories of finding — this includes the secondary safety-classification issue above — don't get published even after a fix ships; the sensitivity is in the category, not the patch status.

How the report was built

Full technical writeup: reproduction steps, impact analysis, root-cause hypothesis, and mitigation recommendations
Explicit separation between directly-evidenced findings and observations that would need independent validation — so the vendor's triage team could tell at a glance what was proven versus suspected
A severity assessment for each technique, not just a single overall rating
An offer to assist reproduction or answer technical questions during the vendor's review

Timeline

Testing conductedIndependent, self-directed testing of the platform's safety-policy enforcement — no bug bounty program prompted this; I went looking on my own.
July 20, 2026Full report submitted to the vendor's security team via their published security contact, marked TLP:AMBER.
July 27, 2026Followed up after one week with no response, requesting confirmation of receipt and asking whether the report had reached the right triage team.
Current statusAwaiting vendor acknowledgment. No public advisory exists yet; this page will be updated if that changes.

Ownership

Nobody assigned this to me — I found the target, scoped the testing, and decided what was worth reporting. Writing the finding was maybe a third of the work: the rest was judgment calls that don't show up in a bug report — what's safe to publish and what isn't, how to word a disclosure so a triage team can act on it fast, when to follow up versus when following up looks like pressure, and where to draw the line on a sensitive finding regardless of how impressive the full details would look on a portfolio. That last part is the actual point of this page.

← Back to projects Get in touch