Built safe, from the ground up.

How we protect your information

You're handing Dandelion the practical center of your life — where your important documents are kept, which brokerage holds your retirement account and who to contact there, your insurance policies, the details your family would need if something happened. We're deliberate about what we store: we don't keep your Social Security number or your financial account numbers, for instance — just enough to point your family in the right direction. But plenty of what you trust us with is genuinely sensitive, and we don't treat that lightly.

A lot of companies answer the security question with a few comfortable phrases. “Bank-level encryption.” “Hosted on AWS.” Those words are easy to say and hard to verify, and they tend to describe the building rather than the safe inside it. So this page is the longer answer: what we actually do, where we're early and honest about it, and what's on the roadmap. Some of it is technical. We've tried to explain the why alongside the what.

It also helps to know who's building this. Our CTO spent five years at NerdWallet — alongside our CEO and Head of Design — building their personal finance app, the one that handled money transfers and credit-score integration, where he ran the backend and frontend teams responsible for doing that securely and with real defense in depth. He then spent five years at Vouch in the highly regulated insurance and legal space, learning firsthand how to build and stay compliant inside tightly controlled environments. This isn't our first time protecting people's financial lives.

Encryption

Every piece of personal information you give us is encrypted before it's ever written to our database. We don't rely on the database or the disk to do this for us after the fact — the data is already unreadable by the time it lands.

We use a layered key system through AWS Key Management Service: a data key that encrypts your information, and a separate key that protects that data key. The encryption happens at the application level, which means even direct access to the raw database doesn't surface anything legible.

Here's what that means in practice. Only our CTO can reach the service that controls those keys. If someone stole our entire database tomorrow, they couldn't read a word of it — not without also having our CTO's work laptop, his face to unlock it, and his password and email, both of which are themselves protected by passkeys and two-factor authentication. The stolen data would be a locked box with the key nowhere near it.

Today, those keys are scoped per environment. We're migrating to a model where each user has their own dedicated key. That change does something specific and important: when you ask us to delete your data, we can destroy your key, which renders your information permanently unrecoverable — a clean break rather than a promise that we got every row. That migration lands as we move from beta into general availability.

Traffic between you and Dandelion is encrypted in transit as well, with TLS certificates managed through Cloudflare.

Where your data lives, and who it can talk to

Dandelion runs on Render. The app you use is the only part of our system exposed to the public internet. Everything behind it — the database, the background workers, the cache — has no public gateway at all. Those services can only talk to each other inside Render's private network, and the only thing the public-facing app is permitted to reach internally is the specific set of services it needs.

When we do reach outward — for example, to the AI models that power Dandie — that happens through controlled, credentialed connections, never an open door.

Everything sits behind Cloudflare, which gives us a web application firewall and protection against denial-of-service attacks before traffic ever reaches us. Our endpoints that do anything sensitive or destructive are rate-limited per user and per IP address, so a single source can't hammer them. We don't operate a public API; the only way in is the app itself, governed by a strict policy that allows connections to a short, named list of services and nothing else.

One honest note about all of this. You'll often see companies point to the certifications held by the big platforms they run on — AWS, Cloudflare, and the like. Those certifications are real, but they describe how those companies secure their own infrastructure, not how we built Dandelion on top of it. They're the floor, not the proof. The work that actually protects you is the work in this document: how we encrypt, who can decrypt, how we isolate your data, what our own code does and refuses to do. That's ours, and that's what we're accountable for.

Your data is yours alone

In a service that holds many families' information, one of the most important questions is also one of the least visible: can one person ever see another person's records? A bug in how an app checks permissions — an attacker changing a number in a web address to pull up someone else's file — is among the most common serious flaws in software, and it's our top priority to protect against.

Every request for data is checked against who's making it. We've built automated tests — both at the level of individual pieces of code and across the system as a whole — that verify this on every single change we ship. If a code change would ever let one user reach another user's information, those tests fail and the change doesn't go out. It isn't left to careful coding; it's enforced.

Signing in

Authentication runs through Auth0, a dedicated identity platform — we never store your password ourselves. You can sign in with Google or with an email and password.

Inside the app, there are three levels of access: regular users, admins, and super admins. Admin access is granted only to people with a Dandelion email address, and only through Google sign-in. Super admin access can't be granted through any screen or button — it requires approval from our CEO and CTO and direct access to our infrastructure, which is itself locked behind single sign-on and two-factor authentication and reachable only by approved Dandelion employees. There is no interface anywhere that lets someone escalate their own role. The two narrow paths above are the only paths.

We'll be honest about one thing here: two-factor authentication is currently not available. For data this sensitive, we think it should be required, and we're making it mandatory for all users within the next month. (It's already mandatory for our own team — every Dandelion employee uses two-factor authentication on Google, Slack, and the other internal services that touch your information.) If you've given us a phone number, we already verify it with a one-time code.

A record of every meaningful action

Every change made to your information is written to an append-only audit log — a record that can be added to but never quietly edited or erased. It's encrypted with the same key protection as the rest of your data.

When an admin views your information to help with a support request, that's logged too, to the same trail: who did it, when, from what device, and from what IP address. Admins can read your data to help you — they can't edit it. And because Dandie handles a lot of the work conversationally, any action taken through chat records the message that prompted it and links to the underlying conversation, so there's a complete picture of what happened and why.

How we keep Dandie safe to talk to

Dandie is an AI companion, and AI raises real, specific questions when sensitive information is involved. We've designed her with hard limits, not hopeful ones.

Dandie cannot reach your data directly, and she cannot change it directly. That's not a policy — it's the architecture. The system is built in distinct layers: one that interprets what you're asking, a deterministic core that decides what's actually allowed to happen, and a final layer that writes Dandie's reply. We never simply hand your information to an AI and let it act. Every change to your data is made by the system itself, under fixed rules, not by the model. This is also why Dandie sometimes can't do exactly what you ask in the moment — we've deliberately fenced in what she's able to do, with guardrails that are tested and can't be talked around. We'd rather she say “I can't do that here” than improvise something wrong on documents this important.

We also test Dandie adversarially — we actively try to trick her into acting without your say-so, and confirm she won't. Every message sent to the AI is screened for prompt-injection attacks, the trick where hidden instructions are buried in text to hijack a model. We screen uploaded documents the same way, so that if you paste in text or upload a file with a hidden instruction tucked inside it, that instruction never gets carried out. The hidden text simply doesn't run.

No serious product runs entirely on its own. We use a handful of outside services — for sending you texts and emails, for understanding how the product is used, for the AI itself. We choose vendors that are the established standard for what they do, and we share as little with each one as the job allows.

Before information leaves our system, we strip out personal details. Our analytics tools receive a hashed identifier, not your name or email. Our notification service receives your name, email, and phone number, because it can't send you an actual message without them — but nothing personal beyond that. On-screen session tools are configured to skip over anything sensitive entirely. When we receive information back from a service, we verify cryptographically that it really came from them and wasn't forged.

That same scrubbing runs inside our own walls, too. All of our internal logs pass through a single filter that masks personal information, and the system is built so that nothing can write a log entry without going through it first.

Keeping your information, and letting it go

Dandelion exists to hold your information for the long haul — the whole point is that it's there when your family needs it, which could be many years from now. So we retain your information for as long as you're with us. Day-to-day conversation history is kept for 30 days to make the product work; the audit log is kept indefinitely, by design.

When you want your data gone, you have the right to that, and we honor it under California privacy law within the required timeframe. We're also building deeper, automated coordination of deletion requests across our vendors, working with our legal counsel, so that “delete my information” reaches every corner it needs to.

When something goes wrong

No one who's honest about security promises it will never be tested. What matters is what happens next.

Our team has substantial hands-on experience designing and running incident response programs — it's practiced muscle, not theory. The substance behind our incident response plan is already in place: our legal counsel has direct experience with security breaches, and we carry cyber insurance that includes breach-response coaching and a hotline. If something happened, we wouldn't be figuring out who to call. We'd be calling them.

Your data is backed up automatically every six hours, with instant restore available. If anything were ever lost or corrupted, we can bring it back to a recent, intact state quickly — and those backups carry the same encryption as everything else.

Finding the holes before anyone else does

We're preparing for a week-long penetration test in July — an independent team paid to attack Dandelion and surface any security gaps or vulnerabilities before anyone else finds them — and we'll define a periodic schedule for future tests from there. Alongside it, we're standing up a vulnerability disclosure program so that security researchers have a clear, welcome path to report anything they find.

On dependencies — the outside code every modern app is built from — we've pinned every package to a fixed version, so nothing updates itself silently into something compromised. We've audited every version we currently run against known vulnerabilities, and we're clean.