Early in my career, I built systems for state government agencies. The kind of systems where if something went wrong, it didn't just cost money. It ended up in a public records request, a legislative hearing, or the evening news. That experience shaped how I think about data.
Later, I built legal technology, including a tool that searches and monitors intellectual property filings, and fintech systems for Fortune 500 companies. Every one of those environments had the same lesson: the organizations that treat security as a feature they'll "add later" are the ones that end up in the headlines.
When my wife Stewanna and I started building Alira, I knew the security architecture had to come first, not last. Because Alira handles the most sensitive information a law firm touches: names, phone numbers, case details, incident descriptions, financial information. And it handles that data at the exact moment when clients are most vulnerable.
The "We'll Add Security Later" Trap
Most startups build the product first and bolt on security later. I understand the impulse. You want to ship fast. You want to prove the concept. Security feels like a tax on velocity.
But in legal technology, that approach is reckless. The data flowing through a legal intake system is protected by attorney-client privilege, bar ethics rules, and an increasing patchwork of state privacy laws. A breach doesn't just trigger a notification requirement. It can trigger bar complaints, malpractice claims, and the kind of reputational damage a small firm cannot survive.
So we didn't bolt security on. We built the product around it.
Encrypt Everything, Trust Nothing
Every piece of personal information in Alira is encrypted at rest. Not the database. Not the disk. The individual fields.
Names, phone numbers, email addresses, case descriptions. Each one is encrypted with AES-256-GCM before it touches the database. That means even if someone gained access to the database directly, they would see encrypted values, not readable data.
But encryption creates a problem: how do you search encrypted data? If a phone number is encrypted, how does the system match an incoming call to an existing client?
We solved this with blind indexes, HMAC-SHA256 hashes that allow exact-match lookups without ever decrypting the underlying data. The system can find a client by phone number without the database ever seeing that phone number in plaintext. The search key and the encryption key are separate, so compromising one doesn't compromise the other.
This is not the easy way to build a system. It adds complexity to every query, every migration, every feature. But it means the data is protected at the layer that matters most: the storage layer.
Sessions, Not Just Passwords
Alira uses passwordless authentication. No passwords to steal, no credentials to phish. Members log in via magic links sent to verified email. Clients access the portal via SMS verification codes sent to their phone.
But authentication is only half the problem. The other half is what happens after login.
Every user in Alira can only have one active session at a time. When you log in on a new device, all previous sessions are automatically invalidated. This isn't just a convenience feature. It enforces seat-based licensing and prevents credential sharing. If someone shares their login, the original user gets logged out. That's by design.
Sessions are scoped by role and context. A member session is tied to their account. A client portal session is tied to a specific matter. An admin session has platform-wide access but a separate authentication path. There is no way to escalate from one context to another without re-authenticating.
Rate Limiting and Bot Protection
Every public endpoint in Alira is rate-limited by IP address. Login attempts, contact forms, API calls, all throttled to prevent brute force attacks and automated abuse.
On top of that, public-facing forms use Cloudflare Turnstile for bot detection. Not a CAPTCHA that frustrates real users, but a silent challenge that blocks automated scripts while letting humans through without friction.
These aren't exotic security measures. They're the baseline. But a surprising number of legal tech tools skip them because "we're not a target." Every system is a target. The question is whether you've built defenses before or after someone proves it.
What Attorneys Should Ask Any Legal Tech Vendor
If you're evaluating any technology that handles client data, here are the questions I'd want answered:
Is personal data encrypted at rest, at the field level? Disk encryption and database encryption are not enough. If a database query returns readable names and phone numbers, the data isn't truly protected.
How are searches performed on encrypted data? If the answer is "we decrypt to search," that means plaintext data exists in memory during every query. Blind indexes avoid this entirely.
What happens when a session is compromised? Single active session enforcement means a stolen token becomes useless the moment the real user logs in again.
Are encryption keys separate from the application? If the app server and the encryption keys live in the same place, a single breach exposes everything.
Is there an audit trail? Every action in Alira is logged: who did what, when, and from where. Not for compliance theater. For real accountability.
Security Is Not a Feature
I've heard founders describe security as a competitive advantage. I don't see it that way. Security is a responsibility. The data flowing through Alira belongs to the clients who shared it and the attorneys who are ethically bound to protect it. Our job is to make sure that trust is never violated.
That's not a feature. That's the foundation everything else is built on.
Alira AI is an AI-powered client intake and triage platform for law firms. Learn more at getalira.com.