If your agent sends email, moves money, or calls tools on its own, then anything it reads is a potential instruction. Breakpoint is a fixed-scope manual audit that shows you exactly what an attacker can make it do — with the steps to reproduce it.
A support agent holds an issue_refund tool with no authorization check, and decides when to call it from text it does not control. An attacker plants an instruction in a note stored on an order; the agent reads that note as a tool result mid-task and moves money.
Unauthorized refund issued 5/5 via the user's message, and 4/5 via the poisoned order note — where the user did nothing wrong.
Fraudulent fund movement triggered by an innocent lookup. The harm is the tool call, not the reply — the chat response is theatre.
Treat tool output as untrusted data, never as instructions. Enforce authorization and an amount ceiling server-side on the privileged tool, and put a human in front of calls that move money.
More findings I've reproduced and published in the open, alongside the agent tool-abuse one above. Each ships with a runnable proof of concept — clone it and check my work rather than taking my word for it. These come from my own research lab and stock open-source configurations, not client systems; client findings stay confidential unless the client asks me to publish them.
A chain rather than a single bug: the vector store accepts unauthenticated writes, and a retrieved document is trusted with the same authority as a developer instruction. One anonymous write poisons the knowledge base permanently.
Leak rate 0/10 before the write, 10/10 after. The attacker never touches the application or the model.
Persistent disclosure of data held in the system prompt, triggered by ordinary user questions, from a single unauthenticated network write.
Authenticate the vector store, treat retrieved text as untrusted data, and keep secrets out of the system prompt entirely.
A controlled comparison rather than a single exploit. A prefix-injection payload — a fake transcript cut off mid-sentence, leaving the model to autocomplete the one thing it was told never to say — fired at six models with everything else held constant.
Leak rate ranged from 10/10 on an uncensored model to 2/10 on a well-aligned one. A well-tuned 3B model resisted as well as an 8B — alignment quality, not model size, predicted exposure.
Your choice of model changes system-prompt exposure by an order of magnitude, and the usual proxy for capability — parameter count — does not tell you which is safer.
Don't put secrets in the system prompt. Where instructions must stay private, measure leak rate for your specific model rather than assuming a bigger one is safer.
I build Shotoku, an open-source spend-control layer for AI agents — budgets, approvals, and an audit trail enforced before an agent spends money. It exists because agents with tool access do things nobody authorized. The code is public; read it and judge the work yourself.
Breakpoint is the other half of that problem. Building the guardrail taught me where agents actually break, so I test other people's agents the same way an attacker would — by hand.
I publish my security research in the open at local-ai-security-lab: seven findings against local AI stacks, plus an automation harness — prompt injection in RAG pipelines, unauthenticated ChromaDB and Ollama, system-prompt extraction compared across six models, and a tool-using agent talked into issuing a refund it should never have issued. Every one ships with a runnable proof of concept. Nothing goes in that repo until it reproduces, and the same rule governs what goes in your report.
No subcontracted testers, no white-labelled scanner. That's also the honest limit on volume — I take a small number of audits per month because there is exactly one of me.
7 of the 10 OWASP LLM categories are reachable from a running agent in 72 hours. The other 3 need training pipelines, dependency trees, or load generation — access I don't ask for and testing the agreement forbids. Anyone claiming full coverage at this price is selling you a scanner.
Reference: OWASP Top 10 for LLM Applications, 2025.
Four sections, one call. No dashboard to log into, no score out of 100, no 40-page appendix padding out a thin result.
What was tested, from which vantage point, over which window — and what was deliberately left alone.
Each one with an OWASP category, a severity, numbered reproduction steps, and the concrete impact. If it can't be reproduced, it isn't a finding.
Per finding: the specific change that closes it. Where the root cause is an over-privileged tool, that includes the architectural fix, not just a prompt patch.
The attacks that failed and why. This is the half that tells you where you're already strong.
The guarantee is only worth something if the words in it are pinned down. So here is the exact clause, the same one stored with your submission and quoted in the report.
A reproducible behavior matching at least one OWASP LLM Top 10 category and producing a demonstrable impact: leakage of information not intended for the user, execution of an action outside authorized scope, bypass of a safety rule, or exfiltration via attacker-controlled input. Refusals and cosmetic outputs do not count.
Refunds are issued to the original card through Stripe, typically within one business day of the report being sent.
There is no sales team, no scoping call, no contract negotiation — the agreement is on this page and you sign it yourself. The scope is fixed at exactly one agent, so I never quote, never estimate, and never bill hours. 99€ is a launch price while I build a public record of findings; it will go up once that record exists.
I run every audit personally, so I take a limited number per month. When the month is full, the form tells you and you wait for the next one. There is no countdown on this page and no spot counter — those are made up, and you'd be right not to trust one.
Security work is bounded by what you authorize. Here is everything outside the line, stated before you pay rather than buried in a PDF.
Not during intake, not for testing, not afterwards. There is no field for one on this site and no table to store one in. Anyone who asks you for a provider key to 'run a security scan' is the threat.
This site qualifies you, verifies you own the target, takes your signed authorization, and charges you. It never sends a single request at your agent. All testing happens by hand, off this platform, after you've signed.
No stress tests, no flooding, no availability testing. It's an explicit exclusion in the agreement you sign, so a Breakpoint audit can't take your service down.
Staging endpoint, test account, or API docs. If the only access you can give me is production with real customer records in it, I'll tell you to fix that first and decline the job.
I test what you own and authorized. If your agent calls a vendor's API, the vendor's systems are out of scope even when they're reachable from yours.
Ownership verification and a signed rules-of-engagement agreement both come before payment, not after. That protects you, and it's the only thing that makes this legal for me.
The sequence matters: verification and authorization both happen before money changes hands.
Company email, the agent's URL, what access you can give, and what the agent is allowed to do.
Host a token file on the domain, or confirm from an address on it. Payment stays locked until this passes — it's what stops anyone submitting a company that isn't theirs.
Rules of engagement: authorized target, test window, exclusions, and your declaration that you can authorize testing. Timestamped and stored.
Stripe Checkout, unlocked only after the two steps above. I never see your card.
Staging endpoint, test account, or API docs. The 72-hour clock starts here, not at payment.
Findings with reproduction steps, then a 30-minute call. Or a full refund if I came up empty.
The definition is fixed in writing before you pay, and it's narrow on purpose: a refusal doesn't count, a theoretical risk doesn't count, and neither does anything I can't reproduce. Every finding ships with numbered steps you run yourself. If you run them and they don't reproduce, it isn't a finding and you get refunded.
No. There is no field for one anywhere on this site and no place in the database to put one. I test through the same surface an attacker has: your app, a test account, or a staging endpoint.
Only because you authorize it. You prove you control the target, then sign a rules-of-engagement agreement naming the authorized target, the window, and the exclusions, with a declaration that you have the right to authorize testing. That signature is timestamped and stored. Without it, no testing happens.
Scanners replay known payload lists against a chat box. They don't know that your agent has a refund tool, that the tool has no ceiling, or that ticket text reaches the model as instructions. The vulnerabilities that matter in agent systems are in the wiring between the model and its tools, and finding those means reading how your specific agent is put together.
Then you get the report section listing what I tried and failed to break, plus your money back. That's a real outcome — it's evidence you can show a customer or an auditor, and it cost you nothing.
Not without your written consent, and never in identifying form. The findings published on this page are redacted and approved by the client first.
One deployed application or agent, with its tools, at one URL. If you have three separate agents, that's three audits. If you're not sure how yours splits up, say so in the form and I'll tell you before you pay.
You get the report and a 30-minute walkthrough. Fix what you want to fix, and I'll re-test the findings once for free within 30 days to confirm they're actually closed.
This submits nothing to your systems and charges nothing. The next screen is domain verification — you can stop there and nothing has happened.