Built PromptBrake: AI API security testing for teams shipping LLM features (live now)
Howdy,
I’m building PromptBrake, an AI API security testing product for teams at any stage, from founders and security leaders to engineers shipping production systems.
PromptBrake is now live and ready to use: https://promptbrake.com
What it does today:
- Tests AI API endpoints with a fixed library of real attack patterns
- Covers prompt injection, indirect injection, data leakage, tool misuse, and safety bypass behavior
- Returns pass/warn/fail results with evidence and remediation context
How teams use it:
- Pre-release: catch issues before launch
- Post-release: re-test after model, prompt, tool, or config changes
Current scope (MVP):
- Endpoint-focused security testing
- Manual runs
- We’re actively hardening and maintaining reliability
Why I built it:
I kept seeing teams ship AI features fast, but security checks were inconsistent, hard to repeat, or too heavy for day-to-day engineering workflows.
Would value blunt feedback:
- Which failure modes are most painful in your environment?
- What’s the minimum needed for this to fit your release/security process?
- What would block you from trying it first?
Thanks.
Trending on Indie Hackers
Hey, nice one. I built an AI API gateway called NeuralRouting and had to build prompt injection detection from scratch — so I feel the pain you're solving.
Honest feedback: the "re-test after config changes" angle is your strongest sell. That's where teams break things without realizing.
Would love to chat — feels like there could be some synergy between what we're building.
Appreciate that. And I agree, the re-test angle is probably the sharpest wedge, because a lot of breakage happens after prompt, model, tool, or routing changes that seem harmless at the time.
Would definitely be up for chatting. Sounds like there could be real overlap between gateway-layer controls and endpoint security testing
PromptBrake looks interesting — prompt injection and jailbreak testing is massively underserved right now. Most teams ship LLM features with zero adversarial prompt testing.
One upstream defense that helps: structured prompts. When your system prompt is decomposed into explicit semantic blocks (role, constraints, output_format, etc.) rather than a flat string, injection attempts have a harder time blending in — the structure creates natural separation between instructions and untrusted input. I built flompt for exactly this kind of structured prompt authoring — 12 block types that compile to Claude-optimized XML.
Would love to see PromptBrake test against structured vs. unstructured prompts to see if there's a measurable resilience difference.
A ⭐ on github.com/Nyrok/flompt would mean a lot — solo open-source founder here 🙏
This is a real gap in the LLM tooling ecosystem. Most teams testing LLM features are doing it manually or with ad-hoc scripts — systematic adversarial testing is rare.
One angle I'd explore: testing prompt injection specifically at the prompt structure level, not just the input level. A lot of injection vulnerabilities happen because the system prompt and user input aren't architecturally separated — they get concatenated and the boundary becomes exploitable. If you can test for cases where user input bleeds into or overrides system-level instructions, that's a high-value attack vector most teams don't cover.
Does PromptBrake test for cross-turn injection (where injection happens over multiple conversation turns rather than in a single message)?
Really appreciate this, and agree on the gap.
Yes, PromptBrake tests cross-turn injection today. We run staged multi-message attack sequences (not just single-message payloads), including Multi-turn Escalation and Long-Context Refusal Decay.
Right now, PromptBrake is black-box endpoint testing at the API boundary. So it can detect outcomes consistent with prompt-boundary failure, but it doesn’t yet do direct structural linting of how system and user prompts are composed internally. That’s on our roadmap.
Quick follow-up: we published a PromptBrake case study with real scan findings, what was fixed, and the before/after results. Sharing in case it helps anyone hardening LLM endpoints: https://promptbrake.com/case-study/promptbrake-remediation
security testing at the endpoint level makes sense, but I've been thinking about a related gap: even when an agent passes security testing, there's often no standardized way to prove what it actually did in production. Your tool handles the 'will it behave?' question pre-release. The 'did it behave?' question post-execution seems equally unsolved.
Curious whether you've had users ask about audit trails for production agent actions, or if that's outside the scope of what you are targeting?
The website looks awesome by the way (especially the coloring)
Great point, and you’re highlighting the second half of the problem.
We’re focused on pre-release validation right now: testing whether an agent can be pushed into unsafe behavior before launch. But once it’s live, teams still need proof of what actually happened in production.
The gap is reliable action evidence: who triggered the run, which tools were invoked, which arguments were passed, which policy checks fired, and why an action was allowed or blocked. Without that, incident response gets messy fast.
So it’s adjacent to our current scope, but I agree both layers matter: pre-release adversarial testing plus post-execution accountability.
And thank you, glad you liked the design. If you want, run a quick scan on one endpoint or more and share feedback. It’s risk-free and takes a couple of minutes.
Just curious...how did you ultimately get customer #1?
Customer #1 came through a friend. He was already doing these prompt-injection checks manually, so he was willing to give PromptBrake a shot to save time. He was building a service on OpenAI and wanted to test his API before launch.