Tulgra's security posture in plain language. Architecture, controls, compliance posture — written for partners and IT leads evaluating the product against a real threat model, not for a marketing checklist.
Tulgra's security is an architectural property, not a feature list. The data does not leave the firm because there is no path for it to leave.
Most legal SaaS products treat security as a control layer applied on top of a cloud-first architecture. Encryption, access controls, audit logging — necessary in their own right, but secondary to the architectural decision to host client material in a multi-tenant environment the firm does not control.
Tulgra's architecture starts from the opposite premise. The application is native to the firm's own hardware. The model runs locally. The index is local. The audit log is local. The controls below are the engineering work that makes that architecture defensible — but the architecture is the security claim.
Four architectural commitments.
The data-flow decisions that shape every other security claim in this document.
No outbound data path.
Tulgra runs as a native desktop application on macOS and Windows. Client material — matter files, drafted documents, prompts to the local model, completions from the local model, retrieval context — has no path out of the application to a cloud service Karakor or any third party operates. The privilege boundary is the firm's own hardware.
Local model inference.
The AI surface runs on the user's device, GPU-accelerated where available, with CPU fallback. The model weights are open-weight, shipped with the application, and never reach out to a model API. A practitioner working with the model is not sending prompts to a third party.
Matter-aware retrieval.
When the model is asked a question, the retrieval system that selects documents to give it operates against the firm's local index. The index enforces matter scope and ethical-wall boundaries at the index layer — not at the prompt layer — so the model is never shown documents it should not see.
Optional integrations on the firm's terms.
Tulgra can integrate with QuickBooks, Outlook, court systems, and other firm-controlled services. Each integration is opt-in, audited, and sends data out of Tulgra on terms the firm sets. Integrations do not pull case files into someone else's cloud.
Six controls that hold up under inspection.
The engineering controls that make the architecture defensible — at rest, in use, and on the auditor's report.
AES-256 encryption at rest.
The application's local database is encrypted with AES-256 via SQLCipher. The key is derived from the user's authentication and is never written to disk in plaintext.
Role-based access control.
Users are scoped to matters, document sets, and edit rights through a role model the firm administers. The application enforces RBAC at every data access path; there is no UI-only gate. Optional TOTP multi-factor authentication is available for sensitive actions.
Immutable audit logs.
Every action that touches client material — opening a document, generating a completion, modifying a record, exporting a file — writes an append-only audit entry with the actor, the matter, and the timestamp. The log is queryable for compliance review and is preserved even when records are deleted from the active store.
Ethical-wall enforcement.
Ethical walls are enforced at the index layer. A practitioner walled off from a matter cannot retrieve, view, search, or have the model surface material from that matter. The wall is configured by the firm and audited the same way every other access decision is.
Hallucination detection on AI output.
When the local model produces output that cites a source, the application verifies that each citation resolves to a paragraph in a document the retrieval system actually returned. Unresolvable citations are flagged with a confidence indicator. The model is configured to refuse to answer when the retrieval system cannot produce a relevant source.
Verified backup with point-in-time recovery.
Backups are encrypted, written to firm-controlled storage on a schedule the firm sets, and verified on a recurring cadence. Recovery is documented in a runbook the firm's IT lead can execute unattended.
How Tulgra reads in the regulatory frame.
Specific compliance certifications are scoped to the firm's deployment. The posture below is what Tulgra's architecture and controls are designed to support.
Tulgra's data-handling posture is HIPAA-aligned for organisations operating under HIPAA or HITECH. Specific scope is reviewed during onboarding.
Data subject rights — access, correction, deletion, portability — are supported by the application's standard export and deletion features. Data does not cross firm boundaries by default, simplifying the legal basis analysis.
The privilege boundary and audit posture are designed to support a firm's competence-of-technology obligation under ABA Model Rule 1.6 and the corresponding state ethics opinions.
The audit log and posture documentation are designed to be defensible during enterprise client diligence, regulatory inquiry, or third-party security review.
Found something? Write to us.
If you have identified a security issue in Tulgra — through independent research, during an engagement, or as a user of the application — we want to hear from you. We will acknowledge a credible report within two business days and share a remediation plan within ten business days, or explain why a longer timeline is needed.
Send disclosures to security@karakorconsulting.com. We do not require an NDA to receive a report. We do not retaliate against good-faith security research.
A detailed security whitepaper, including architecture diagrams, threat models, sub-processor lists, and the full control descriptions, is available to firms under evaluation. Request it via the contact page.
We respond within two business days. Scoping calls are obligation-free and run thirty minutes.