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
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
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.
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