We don't askfor trust.
Isolation, data minimisation and outcome traceability are how the system is built, not features bolted to it. The questions below are the ones a security review opens with, and each answer is a mechanism you can test rather than an assurance you have to accept.
Two things in.Two things out.
This is the diagram a reviewer draws on a whiteboard within the first ten minutes, so it may as well be the one on the page. Two things cross inward, two cross outward, and two never cross at all — the last pair being what the question is usually really about.
Six questions,answered as mechanisms.
“Fail-closed” is a behaviour you can test. “Enterprise-grade” is not a claim about anything. Every answer below is written so your team can check it rather than believe it.
Attribute-based permissions scoped per tenant, per surface and per decision. The default is deny: an unscoped request resolves to no access rather than to a best guess.
Evidence is read at decision time and retained only as the lineage a decision needs to remain auditable. Retention windows are set per tenant, not per vendor default.
Only the signals a bound question declares. A decision that does not need a field does not receive it, which is enforced by the signal contract rather than by policy.
The readiness gate caps what may be claimed and names the gap. It does not estimate around absent evidence to keep a surface looking complete.
Anything authorized carries an explicit reversal window, and the ledger records the reversal as its own event rather than editing the original.
Architecture documentation, isolation boundaries, data-handling protocols and the deployment model, reviewed with your team under NDA.
What the architecture refuses to do — and where it stands on the autonomy ladder — is set out on governance.
Bring yoursecurity team.
Architecture documentation, isolation boundaries, data-handling protocols and the deployment model, walked through with your reviewers rather than sent as a PDF.