An approval gate enforced server-side
The gate that decides whether an agent action proceeds cannot be bypassed from the client. It is checked where the action actually executes.
We have no customers yet, so we cannot show you case studies. What we can show you is a real report on our own system, and a running system built the way we say systems should be built.
The published report
The method we deliver, run against the multi-tenant AI agent platform we built. Twelve findings, published in full, including the two we would least like to have found. We have no clients yet, so this is our own system — which is also why we can publish every word of it. A client engagement follows the same report structure, but the evidence, failure scenarios, priorities, and remediation estimates come from your system, under NDA.
Two were Critical. Slack endpoints where request signature verification failed open, in three separate places — including one path where the check ran only if certain headers were present at all, and another where an unset signing secret verified every request as authentic. One of these let an unauthenticated caller execute agents belonging to another organisation and read the output back in the HTTP response.
The report also contains a visible correction. An earlier draft misjudged one finding — it said a handler rejected every request when it actually failed silently in a different way. We recorded the correction in place rather than quietly editing it out. A practice that quietly fixes its own mistakes cannot be trusted to report yours honestly.
Both Critical findings are fixed, along with the three Highs. The remaining Medium and Low findings are tracked openly rather than quietly closed.
The running system
This is not a product on offer. It is the system the report above was run against, and it demonstrates the engineering we bring to a review.
The gate that decides whether an agent action proceeds cannot be bypassed from the client. It is checked where the action actually executes.
Decision latency, whether the reviewer opened the reasoning behind an action, and the override rate are all recorded — not just that a button was clicked.
If an external action is interrupted mid-flight, the workflow marks it for review instead of guessing and repeating it against a system that may have already received it.
Deletion is not a manual step someone might forget. It runs on a schedule, and the audit window is held longer than the operational one, so evidence outlives the working data it describes.
Integration credentials are encrypted with the owning organisation bound into the encryption, so ciphertext from one tenant cannot be decrypted in the context of another.
A test asserts that every table holding organisation data is reachable from the erasure path. Add a table and forget to wire it in, and the build fails, not a future audit.
Working knowledge
We have working knowledge of EU AI Act Articles 12, 14 and 26 — provisions that apply to particular roles in relation to high-risk systems, not every system — and of the EU Cyber Resilience Act's vulnerability-handling obligations. We use this to tell you what your system does and does not do today.
This is engineering knowledge, applied to code and configuration. It is not legal advice, and a review from us is not a substitute for advice from a qualified lawyer on your specific obligations.