Trust is not a feature.
It is the precondition.
A lawyer cannot adopt a tool that puts privilege or professional liability at risk. We engineered those constraints into the architecture before we wrote a line of product.
Built into the
architecture, not bolted on.
Confidentiality, data residency, a grounding in Turkish law and source-based discipline. Four structural protections, enforced by the system itself rather than by a policy document.
AES-256-GCM at rest,
not selectively.
The database, knowledge base, documents and workspace are all encrypted at rest with AES-256-GCM. Personal data is masked at the gateway before any cross-border model call.
When in doubt,
access is denied.
A three-role RBAC for client, lawyer and admin; two-factor authentication over SMS and email OTP; a fail-closed session store, with access authorised per request.
The sign-off gate
cannot be bypassed.
Attorneys Act m.36 is enforced by a bypass-proof sign-off state machine, not by convention. The system prepares, drafts and flags risk; the final assessment and signature stay with the attorney.
The record of who
did what survives.
A Citation Gate and an independent Verifier sit between the model and the page; uncertain references are not presented as fact. The append-only audit log cannot be silently rewritten.
We do not
overstate.
We state plainly what is in production today. If a capability is not yet available, we will not bill you as though it were.
Request a Free Trial →VAULT DESCENT
We descend toward what protects client data. Each layer is a guarantee enforced by the system itself, not a promise on paper.
STRUCTURAL MOATS
A confidentiality gate, data residency at the architecture level, a grounding in Turkish law and source-based discipline. Each closes a failure mode that makes generic AI unsuitable for regulated legal work.
ENCRYPTION
AES-256-GCM at rest applies across the stores. The masking table that reverses the masking never leaves the jurisdiction; only masked data reaches a cross-border call.
ACCESS
Three-role RBAC checks permissions at the boundary. Two-factor authentication, a fail-closed session store and per-request authorisation close the class of flaw where an identifier alone grants access.
SOVEREIGNTY
The Av.K. m.36 sign-off gate cannot be bypassed. The system prepares, drafts and flags risk; the final assessment and signature stay with the attorney.
AUDITABILITY
The Citation Gate and an independent Verifier check every reference; uncertain ones are marked rather than asserted. The append-only audit log preserves the record.
HONEST MATURITY
We do not overstate; we state plainly what is in production today. We draw the line clearly and we do not sell a capability that does not yet exist.
Trust & Security
Built to be trusted by people who are paid to be skeptical.
Security and confidentiality are not a feature on this platform. They are the precondition. A lawyer cannot adopt a tool that puts privilege, personal data or professional liability at risk, so we engineered those constraints into the architecture before we wrote a line of product.
What follows is an exact account of what protects client data, what is live today, and what is still on the roadmap. We do not overstate.
Structural moats
Four protections built into the architecture, not bolted on.
Each addresses a failure mode that makes generic AI inadmissible for regulated legal work. They are structural, enforced by the system, not by a policy document or good intentions.
Confidentiality & the sign-off firewall
Professional confidentiality (Attorneys Act m.36) is enforced by a bypass-proof attorney sign-off state machine, not by convention. Client data is compartmentalised by matter, and nothing reaches a client until a qualified attorney has signed it off.
- Bypass-proof sign-off state machine, output cannot skip the attorney gate
- Client data compartmentalised by matter; no cross-matter leakage
- Nothing reaches a client unsigned (Av.K. m.36)
- The human attorney is the partner who signs; the system is the associate
Data residency at the architecture level
Personal data is masked at the gateway before any cross-border model call is made. The masking table, the key that reverses the masking, never leaves the jurisdiction. Data is encrypted at rest with AES-256-GCM, and embeddings can be routed to the EU.
- PII masked at the gateway before any cross-border call
- Masking table never leaves the jurisdiction
- AES-256-GCM encryption at rest
- Embeddings routable to EU infrastructure
Localization, not translation
The system is grounded in Turkish law, not a foreign model with a Turkish skin. Identifiers are checksum-validated, jurisdiction is grounded against the actual statutory framework, and the work product reads like it was written by a Turkish lawyer.
- TCKN / VKN checksum validation
- TTK and jurisdiction grounding against the live statutory framework
- Turkish-law work-product quality, not machine translation
- Correct register and terminology for Turkish practice
Source-based discipline
A Citation Gate and an independent Verifier sit between the model and the page. Uncertain references are marked "[verification required]" rather than presented as fact, and the system will not invent a docket number, a case name, or a citation that does not exist.
- Citation Gate + independent Verifier on every reference
- Uncertain references marked "[verification required]"
- Never invents a docket number or case citation
- Designed to hold up under cross-examination
Data security architecture
The controls underneath the product.
The guarantees above rest on a concrete set of engineering controls. These are implemented; they are not aspirations.
Three-role RBAC
Client, lawyer and admin roles with separated authority. Permissions are checked at the boundary, not assumed.
Two-factor authentication
SMS and email one-time-password (OTP) factors on account access.
AES-256-GCM at rest
Encryption across the database, knowledge base, documents and workspace, not selectively.
Encrypted backups with rotation
Backups are encrypted and rotated on a schedule, so a single point of failure does not become a single point of loss.
Fail-closed session store
A persistent session store that fails closed: when in doubt, access is denied rather than granted.
Conversation access authority
Access to a conversation is authorised per request, closing the IDOR class of vulnerability where an ID alone grants access.
KVKK-compliant observability
Errors are observable for operations without writing personal data into logs, no PII in telemetry.
Append-only audit log
An audit trail that can be added to but not silently rewritten, so the record of who did what survives.
Compliance posture
Where we stand against the frameworks that matter.
This is a statement of compliance posture and readiness, not a claim of third-party certification. We name what is operational and what is on the roadmap, and we draw the line clearly.
A Data Processing Agreement (DPA) is available on request.
Honest maturity
What is live today, and what is still on the roadmap.
Counter-intuitively, this is the part that builds trust. A vendor who will not tell you what is unfinished is a vendor you cannot plan around. Our product principle, AMENTÜ, is honesty: we mark what ships versus what is in progress, and we never sell a capability that does not yet exist.
If a capability is not on the "live" side of this line, we will not bill you as though it were.
- Live m.36 attorney sign-off firewall, enforced
- Live KVKK PII masking before cross-border calls
- Live AES-256-GCM encryption at rest across stores
- Live Citation Gate + Verifier against fabricated references
- Live Three-role RBAC, 2FA and append-only audit log
- Roadmap EU data-residency routing for embeddings
- Roadmap Off-host encrypted backup for Enterprise
- Roadmap Firm-RAG isolated precedent memory
- Roadmap SOC 2 / ISO 27001 independent attestation
See the controls, not just the claims.
The most credible thing we can do is show you. Book a demo and we will walk through the sign-off firewall, the masking pipeline and the audit trail on a real matter.