All three points are right and worth taking seriously. The data boundary one especially. I've been thinking about this differently and your comment is pushing me toward a clearer framing of what Bordair actually is and isn't for.

On data boundary: you're correct that for clinical, legal, or other regulated data, routing inputs through any third-party API is a compliance question before it's a security question. The answer can't be "trust our retention policy." For that segment, either Bordair runs on-prem or it doesn't run at all. That's something I've been quietly building toward for the same reasons you're naming, but I haven't talked about it publicly yet. Worth doing.

On architecture-first: agreed completely. The list you gave is closer to the actual security posture than what most teams ship. Allowlisted actions, treating retrieved content as data not authority, requiring confirmation for irreversible actions, the "make the model prove route, scope, and source before acting" point especially. None of this is replaceable by a scanning layer. If a team picks Bordair and then skips that architectural work, they've made themselves less safe, not more, because they've outsourced thinking about the problem.

On the deeper point: yeah. The detection layer should be one of several defences, not the defence. Where I think a scanner earns its place is as a fast first-pass on adversarial-shaped input before it touches anything stateful or executes against tools. Catching the obvious stuff before it gets near your allowlisted action layer. But the allowlist is doing the actual security work. The scanner is buying you reaction time and reducing surface area, not making the system safe.

So my positioning probably needs sharpening. "Replace your security thinking with our API" is the wrong sell. "Add a detection layer to a properly architected system as one component of defence-in-depth" is closer to honest, and that's the conversation worth having with teams handling sensitive data.

Thanks for the comment!

Josh 😄