Two sharp readers found security flaws in our product in the same week. We are grateful.

TrustLoop is an AI governance platform. The whole point is that it catches problems before they happen. So when two separate people found real security gaps in the product within the same week, the irony was not lost on us.

Both found the flaws by reading carefully and asking the obvious question we had not asked ourselves.

The first was on our n8n community forum post. A reader left a detailed technical comment pointing out that our human approval workflow had a fundamental vulnerability. When TrustLoop escalates a tool call for human approval, it sends the approver the full arguments — the specific action the agent wants to take. The approver clicks Approve. But we were not verifying that the arguments the agent submitted on the retry were identical to what the approver had seen. A misconfigured or malicious agent could surface a $5 transaction for approval and then execute a $500,000 one. The approval was real. The authorisation was not.

We wrote about that in detail in a previous post here. We shipped the fix — payload hash verification — within 48 hours.

The second was on that IndieHackers post itself. A reader named chalermpon left a single comment that cut straight to the next gap. His question was precise: binding the payload hash to the approval stops argument swaps, but what stops the same approval being used twice? If the agent retries with identical arguments, the hash clears both times. Was the approval being marked as consumed after first use?

It was not. He was right. One valid approval could theoretically be replayed multiple times against the same arguments and each retry would pass.

We fixed it the same day. After a successful approval verification, the approval status is immediately updated to consumed. Any subsequent retry with the same approval ID is rejected — even with a valid hash, even with identical arguments. One approval, one execution.

Two weeks, two gaps, two fixes. Both found not by a formal audit, not by a penetration tester, but by people who read something we wrote publicly and thought carefully about it.

The thing we keep returning to is that neither of these finds would have happened if we had not been writing and sharing openly. The first came from a forum post announcing our n8n node. The second came from a post about the first fix. The transparency created the surface that invited the scrutiny.

For a small team building a security product without the budget for a formal audit, that scrutiny is genuinely valuable. We are not suggesting this replaces proper security review — it does not, and we know a penetration test and SOC 2 audit are on the roadmap. But building in public and engaging honestly with technical readers has produced more concrete security improvements this month than anything else we have done.

If you are building something and someone in the comments asks the obvious question you did not ask, read it twice before you move on.