Your meeting AI vendor shouldn’t be able to read your transcripts — so we made that a hard architectural constraint
Most “encrypted meeting / AI transcription” products mean TLS in transit or server-side encryption: once data hits the cloud, the vendor still holds the keys.
AegisMeetings takes a different path: a zero-knowledge pipeline.
This isn’t a slogan. It’s a set of hard constraints:
- Keys are generated in the browser and never sent to our servers
- Audio, transcripts, summaries, and vocabularies — at rest, only ciphertext remains; the DB doesn’t even store vocabulary content
- AI transcription must briefly “hear” the audio once — we call this the Honest Processing Window, keep exposure in memory, and wipe when done
- Even if someone steals the servers, the database, and cloud storage together, they still get ciphertext they can’t decrypt
Algorithms, key hierarchy, trust boundaries, and network defense-in-depth are all documented in the public whitepaper (no internal addresses or operational secrets):
https://aegismeetings.com/whitepaper
Engineers and security folks: please poke holes. We’d rather get challenged than sell privacy on “trust us.”
Trending on Indie Hackers
The most valuable thing in this thread is buried in your reply downthread: the "what we claim / what we explicitly don't claim yet" table. That belongs on the landing page, not page 14 of a whitepaper. Here's why: your buyers cannot verify cryptography. A DPO or legal-ops lead evaluating meeting AI has no way to check your key wrapping, so they fall back on the only signal available to non-cryptographers, which vendor sounds like they're lying. Every competitor says "end-to-end encrypted" unconditionally; the vendor who voluntarily enumerates his own residual attack surface (crash dumps, privileged operators, the processing window) is making a statement no liar would make. Honesty asymmetry is the moat here, because it cannot be faked without paying the same architectural cost you paid.
One nuance from building browser-side tools: there's a hard line between claims a prospect can verify themselves in devtools (nothing leaves the client) and claims they must take on faith (your server-side window discipline). Anything in the second category converts better when it arrives pre-hedged, exactly like your table does. Selling honesty only works if you never once round it up.
I run a security and compliance company, and here's the pattern in every security-led sale: the buyer isn't the engineer who appreciates the architecture, it's the legal or compliance person who needs something to hand an auditor. Get the zero-knowledge claims validated by a third party (pen test report, SOC 2 scope note) and lead with that document. Architecture wins the demo, paperwork wins the contract.
This is gold — thank you.
I’ve been optimizing for the engineer who gets the architecture. You’re reminding me the person who actually signs is often legal/compliance, and what they need is something they can hand an auditor — not a beautiful threat model.
So: architecture wins the demo; paperwork wins the contract. Noted.
We’re aligned on the destination — pen test / third-party validation of the ZK claims, and eventually something auditor-friendly like a SOC 2 scope note. Right now we’re pre-budget for that; once we have enough funding to pay for a real review (not a checkbox PDF), that’s one of the first things we’ll buy. Until then we’ll keep the trust model public and keep inviting scrutiny — but I won’t pretend a founder whitepaper replaces a third-party report.
Really appreciate you spelling out how these deals actually close.
Justin
This is the kind of privacy-first AI architecture more vendors should be building. Documenting the trust model and inviting public scrutiny adds far more credibility than simply claiming to be "secure." The real test will be independent security reviews and audits.
Thanks — that’s exactly what we’re aiming for.
Claims are cheap. Publishing the trust model and letting people poke holes in it is the only way this is worth anything. Independent review / audit is the real test, and we’re treating that as a milestone, not a marketing checkbox.
Appreciate you saying it plainly.
Justin
I really like that you treated privacy as an architectural decision instead of a marketing feature I think thats a much harder approach to take because it limits what you can do later I'm curious did making zero knowledge a requirement force you to give up any features that would have been much easier with a traditional architecture
Yeah — once you make ZK a hard requirement, a bunch of “obvious” SaaS features get painful or just disappear.
The big ones we had to accept:
Server-side magic is mostly off the table. We can’t quietly re-summarize, search, or “just fix” a past meeting for you. If the keys aren’t on an unlocked device, we’re stuck by design.
Recovery isn’t a support ticket. Lose the device / keys and we can’t decrypt your vault for you. That’s the product, not a bug — but it’s a brutal sell compared to “reset password, we restore everything.”
Sharing / collab / admin oversight get harder. Anything that assumes the vendor (or an org admin) can open the transcript later fights the architecture.
Cross-meeting AI is constrained. “Ask anything across all my meetings” is easy when the server can read plaintext. With sealed artifacts, that intelligence has to stay client-side or carefully scoped — we can’t just run a backend brain over your history.
Even ops is constrained. We intentionally don’t keep long-lived decrypt power after the Honest Processing Window. That means fewer “we’ll reprocess it from our side” escape hatches.
So yes: ZK forced us to give up a lot of the easy path. What we kept is the guarantee that finished artifacts stay undecryptable even if someone steals the DB — and that tradeoff is the whole point.
Curious which of those tradeoffs feels like a dealbreaker to you vs. an acceptable cost?
Justin
the architecture sounds solid, the harder problem is usually selling it. two things: 1) for most buyers privacy is a vitamin not a painkiller, they nod at "zero knowledge" and still pick the tool their team already uses. it closes deals only where confidentiality is a hard requirement: legal, healthcare, therapists, M&A, board/exec meetings. id aim the whole go-to-market at one of those where "the vendor can read your transcripts" is genuinely a dealbreaker, instead of pitching privacy to everyone. 2) nobody believes security claims on faith (every tool says "encrypted"). the line that lands is the one you already have, "steal our servers and you get ciphertext you cant decrypt," backed by the public whitepaper or a third-party audit. make the guarantee provable, not just stated. the moat isnt the crypto, its being the obvious choice for people who literally cant use a tool that reads their calls.
Yeah, this lands. You’re naming the part I’ve been circling without saying it cleanly.
On (1): privacy-as-vitamin is exactly the trap. A lot of people nod at “zero knowledge,” then go back to whatever their team already opened. The deal closes when “vendor can read the transcript” is an actual non-starter — legal, therapy, healthcare, M&A, board/exec. I’m going to stop pitching privacy to everyone and aim GTM at one of those first.
On (2): totally agree. “Encrypted” is table stakes noise. The line that actually cuts is the one we already use — steal the servers, you still only get ciphertext you can’t decrypt — and it only works if it’s checkable, not just claimed. We’ve got a public whitepaper for that; a third-party audit is the next credibility step when we can fund it.
So yeah: the crypto isn’t the moat. Being the obvious pick for people who literally can’t use a tool that reads their calls is.
Appreciate you sharpening this. If you’ve seen a vertical where that “dealbreaker” pitch converts fastest in practice, I’d love the pointer.
Justin
Doubling down on a segment is advice people nod at and ignore.
The hard part is killing the near-miss customers. I keep a short kill list of who I will not sell to this quarter. Without that, every polite maybe steals focus from the yeses.
Respect the honesty of naming an Honest Processing Window — most vendors bury that part under "encrypted."
The sales question I'd keep pressure-testing: for enterprise buyers, is "we can't read your archive" enough, or do they still need attestation / measured images before procurement will treat it as a real trust boundary? The whitepaper helps engineers; buyers often need a one-pager threat model that says what root on the ASR host still gets them.
Curious which objection comes up most in demos — crypto depth, or "who holds the keys if an employee leaves."
Thanks — that’s the sales question I’m pressure-testing too.
For a lot of buyers, “we can’t read your archive after the job” is already a different category than “encrypted at rest.” For enterprise procurement, I agree some teams will still want attestation / measured images before they treat the live ASR host as a closed trust boundary. We don’t ship attestation yet — that’s a real upgrade path, not something we pretend to have today. A one-pager on “what root mid-job still gets you vs what it doesn’t” is probably more useful for buyers than another algorithm dump.
On the other objection: “who holds the keys if an employee leaves” comes up as much as crypto depth. Device-bound vault keys make offboarding a product problem, not a “vendor still has a copy” problem — which is the point, and also why enterprises ask about admin / multi-seat control.
We’ve reserved flexibility for enterprise-style accounts (one org seat managing multiple users). Not open yet — when someone’s serious, we can talk scope.
If you want to keep poking the framing in public, the launch thread is here:
https://www.producthunt.com/products/aegismeetings?utm_source=other&utm_medium=social
The attestation thread covers the server side well, so I'll poke at the other end: key generation in the browser is only as strong as the code delivery channel. Every page load, your server ships the JS that generates and handles those keys — a compromised or coerced deploy could silently push a build that exfiltrates them, and no user would notice. That's the classic web-crypto delivery problem, and it's what I'd expect a reviewer to raise right after the processing window. Worth documenting in the whitepaper: reproducible client builds with published hashes, subresource integrity, an update transparency log, or moving key custody into an extension so updates are at least user-visible. Curious whether you treat the deploy pipeline as inside or outside the trust boundary today.
The attestation thread covers the server side well, so I'll poke at the other end: key generation in the browser is only as strong as the code delivery channel. Every page load, your server ships the JS that generates and handles those keys — a compromised or coerced deploy could silently push a build that exfiltrates them, and no user would notice. That's the classic web-crypto delivery problem, and it's what I'd expect a reviewer to raise right after the processing window. Worth documenting in the whitepaper: reproducible client builds with published hashes, subresource integrity, an update transparency log, or moving key custody into an extension so updates are at least user-visible. Curious whether you treat the deploy pipeline as inside or outside the trust boundary today.
You’re pointing at the other classic boundary — and you’re right: browser-held keys are only as trustworthy as the JS delivery channel. A compromised or coerced deploy that ships a build to exfiltrate keys is outside what “keys never leave the device” alone can defend against.
How we treat that boundary today:
The deploy pipeline is inside the trust boundary for client crypto. We don’t claim users can independently verify every page load against a transparency log yet.
What we do ship: public whitepaper on constraints + algorithms; CSP / same-origin delivery for the app crypto; we don’t ask users to paste private keys into random forms.
What’s a real upgrade path (not pretending we already have it): published client build hashes / SRI where it fits, update transparency, or moving key custody into an extension so updates are user-visible. Those are on the critique list for the same reason you raised them.
So: ZK protects at-rest archives against “steal our DB/Blob”; it does not by itself solve “malicious web deploy swaps the crypto JS.” Thanks for pressure-testing that end.
If you want to keep poking — including UX / how clearly we spell that limit — the Product Hunt launch thread is open too:
https://www.producthunt.com/products/aegismeetings?launch=aegismeetings
Happy to take holes there or here.
The interesting opportunity isn't offering encrypted meeting transcripts—it's making vendor access itself something customers no longer have to trust. I'd keep validating whether organizations choose AegisMeetings because of stronger privacy features or because the zero-knowledge architecture removes an entire category of trust concerns from the buying decision.
Agreed — the product story isn’t “we encrypt transcripts,” it’s “vendor read-access stops being something you have to take on faith.”
Early signal so far: the people who dig in care less about a feature checklist and more about whether we can still read the archive after the job. The Honest Processing Window is usually the first thing they pressure-test — which is exactly the trust category we’re trying to remove, not paper over.
Still validating the buying reason in the wild. If you’ve got a take on how that lands for org buyers vs indie users, I’d love the pushback — here or on the Product Hunt launch thread:
https://www.producthunt.com/products/aegismeetings?launch=aegismeetings
I appreciate the context.
Your question about org buyers vs indie users is actually where the interesting tradeoffs start. I have a few thoughts on how the trust concern may translate differently across those groups, but I don't think I'd explain it properly in a thread.
I'd rather discuss it in the context of AegisMeetings.
If you're open to it, what's the best email to reach you on?
Thanks — happy to go deeper over email.
We're mid–Product Hunt launch and every upvote helps more than you'd think. If you're open to it, would you mind giving us an upvote on the PH page first, and we can continue part of the conversation there?
https://www.producthunt.com/products/aegismeetings?utm_source=other&utm_medium=social
For the more detailed / technical tradeoffs (org buyers vs indie users, Honest Processing Window, etc.), once the launch day settles down, feel free to email us and we can dig in properly:
[email protected]
Really appreciate the thoughtful questions.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
The Honest Processing Window is the boundary I'd pressure-test hardest. Browser-held keys protect storage, but the inference host still sees plaintext in memory. What prevents crash dumps, debug traces, swap, or a privileged operator from capturing that window? A short lifetime helps, but an attested isolated runtime would make the claim materially stronger.
You're pointing at the right boundary. The Honest Processing Window is exactly where we refuse to paper over the physics: ASR has to see audio once, so the inference host briefly holds plaintext in memory. Browser-held keys protect at rest and outside that window — they don't make the host "blind" while the job is running.
What we claim today (and what we don't):
What we do claim
At rest (Blob/DB): ciphertext only. We don't hold the user's vault private key, so a DB+Blob snapshot still doesn't yield readable meetings.
The window is job-scoped: the audio key is delivered in the Service Bus job (wrapped to the transcription host's key), not persisted in the DB. When the job ends, that host keeps no lasting ability to decrypt that meeting's audio again.
Outputs (transcript/summary) are sealed under the user's key before they become durable state. After the window, "we can still read your archive" is what we're designed not to be able to do.
Transcription is a separate trust domain from the public web app (separate duties/MI). Compromising the web tier shouldn't equal "decrypt every historical meeting."
What we do on the host to shrink the window (operational, not cryptographic magic)
Swap is disabled on transcription hosts so plaintext is less likely to get paged to disk.
Plaintext workspaces are constrained to RAM-backed paths (tmpfs / shm whitelist), not "decrypt onto the OS disk and hope."
Egress from the transcription cluster is allow-listed (no open internet exfil path by default). That doesn't stop a privileged operator who already owns the box, but it does raise the bar for opportunistic RCE → random C2.
What we explicitly don't claim yet
We are not saying a privileged operator, crash dump, debug attach, or cloud-admin path can't observe that window. Short lifetime + wipe-after-job reduces exposure duration and persistence; it does not equal an attested isolated runtime.
An enclave / Nitro-style attested environment would make the claim materially stronger for exactly the reasons you listed. That's a real upgrade path, not something I'm going to pretend we already ship.
So I'd frame it as:
ZK for storage + honest, minimized processing window with host isolation — not "plaintext never exists on infrastructure we operate."
If you've got a specific threat model you care about most (malicious root on the VM vs. Azure insider vs. crash-dump forensics vs. supply-chain on the image), I'm happy to walk that one through in more detail — including where we'd still need TEE/attestation before I'd call it closed.
Whitepaper section on the window is here for anyone following along: https://aegismeetings.com/whitepaper
Malicious root or cloud-admin is the threat model I'd prioritize, because it can enable debug attach, force dumps, or tamper with the image; fixing crash dumps alone is narrower. The clean upgrade is per-job key release only after remote attestation of a measured image, then destroy the wrapping key when the job closes. That makes the processing window auditable instead of merely short.
Fair — and I want to be precise about what root actually gets you in our design.
Even if someone has root (or cloud-admin) on a transcription host while a job is running, what they can observe is still scoped to that job’s in-memory plaintext — the audio (and related material) being processed in the Honest Processing Window.
What they still should not get:
past meetings at rest (Blob/DB stay ciphertext)
the user’s vault private key (we never hold it)
a durable “re-open this meeting later” capability after the job ends — the audio key is job-scoped via the Service Bus payload (not persisted in the DB), and sealed outputs are under the user’s key
So root on the inference host is serious for the current window; it is not “walk away with the whole archive.”
That said, your upgrade path is still the right one for the threat you care about: per-job key release only after remote attestation of a measured image, then destroy wrapping material when the job closes — so that live window becomes auditable, not merely short. We don’t ship that yet; today is ZK-at-rest + job-scoped keys + host isolation ops.
If you want to keep pressure-testing how clearly we draw that line for buyers, the Product Hunt thread is open too:
https://www.producthunt.com/products/aegismeetings?launch=aegismeetings