How AI Platforms Should Protect Advisors and Their Clients: A Q&A with Jordy Jacob

On Wednesday, the cloud platform Railway disclosed that an unauthorized party had accessed customers’ encrypted environment variables, the place most apps keep their API keys and passwords, and had decrypted some of them. Railway paused every deployment on its platform and told customers to rotate all of their keys.

Most advisors have never heard of Railway. But plenty of them now use AI tools that hold keys to their CRM, their inbox, and their clients’ files. So we sat down with Jordy Jacob, Continuum’s founding engineer, to talk about what this kind of breach means for a wealth practice, and what an AI platform built for advisors should be doing to make sure it never becomes their problem.

Before Continuum, Jordy worked on a serverless compute team at Amazon Web Services. His answers have been edited for length and clarity.

What happened at Railway, and why should advisors care?

What actually happened this week?

Railway is a smaller cloud company that a lot of developers use to run their apps. They noticed someone had gained access to production servers holding customer secrets: API keys, credentials, exactly the things you never want to leak. The attackers managed to decrypt some of those values and started using them. So if you ran something on Railway, someone may have taken your keys to other services and started spending on your account.

How does that reach an advisor’s practice?

If you’re using Claude or OpenAI directly, and especially if you’ve vibe-coded a tool yourself, those keys often aren’t stored securely. Running it on your own laptop might be fine. But once it’s spun up somewhere on the internet and the secrets aren’t handled properly, that’s a very easy way to get your keys compromised.

With an OpenAI key, the damage is mostly the bill. Now say you’ve connected that tool to your CRM, set up an API key for it, and stored the key somewhere. If that key gets stolen, someone has unrestricted access to everything in your CRM that the key was allowed to see. That’s your clients’ names, accounts, notes, and family details.

So what should an AI platform for advisors be doing about it?

We take a multi-layered approach at Continuum. No single control is enough on its own, so you stack them. Here are the seven steps I’d expect from any platform that touches client data.

Step 1: Give every key only the access it needs

Where does that layered approach start?

With permissions. Any API key, or any permission given to any piece of compute, should be the minimum that job needs. When you connect your CRM to Continuum, the credential we hold is there to write your notes, tasks, and follow-ups back. It doesn’t need the power to do anything else.

That way, if a key were ever stolen, the risk is contained. It can only do what that one service was allowed to do. The flip side is that this only works if you’re disciplined about it. A service that’s allowed to do everything is still a big target, so we keep scopes tight from the start.

Step 2: Always encrypt secrets

The secrets in this week’s breach were encrypted, and some were still decrypted. How do you guard against that?

Encryption is only as strong as where you keep the key that undoes it. At Continuum, the credentials we store are encrypted with a key that sits outside the services deployment, in our cloud platform’s key management, with only our service having read permission to use it. So even if someone walked away with a copy of our stored data, they wouldn’t be walking away with the means to read it. That’s part of our zero trust principle.

Step 3: Assume every service could be compromised

You’ve mentioned zero trust. What does that mean in practice?

Zero trust is a security principle. Between our services, you design under the assumption that every one of them is a potential threat. It sounds pessimistic, but it changes how you build. It forces you to think hard about the boundary between services and to put a strong barrier there: isolated networks, separate resources, and no inbound access from the outside. If one piece ever has a problem, it stays with that piece.

Step 4: Protect the client data itself

Keys are one thing. How do you secure the actual client data advisors put into Continuum?

The same zero-trust thinking applies, in layers.

• Everything potentially sensitive is encrypted in the database. If someone did get in, they’d see garbled information; reading it takes a separate key, stored securely in our cloud platform.

• Our services sit in a private isolated network with no inbound access.

• Everything is private by default. Your meetings, notes, transcripts, and emails are visible only to you until you choose, in settings, to share them with specific people or your whole firm.

• Client data stays in Canada. Continuum is SOC 2 Type II certified, and client consent to capture is audit-logged.

Step 5: Don’t keep what you don’t need

You always say Continuum “captures” a meeting. Is that deliberate?

Very. We transcribe the content of meetings, instead of storing audio forever. After a meeting, the only thing stored is the text of what was said, stored securely and encrypted. The safest data is data you don’t store forever.

Step 6: Threat-model every feature, and be willing to cancel it

What did you bring to Continuum from your time at AWS?

At AWS I worked on a serverless compute team, and every major feature went through a pretty involved security review with dedicated security teams. As the engineer, you’re part of that process. You write out the threat model for the new feature, then work with the security team to find where the potential issues are and how big each risk is. If you find something critical or high severity, it gets fixed before the feature launches. Lower-severity items get planned.

Did that ever stop a feature?

Yes, and that’s the part people don’t hear about. There were features customers wanted where the security risk was too high, and we cancelled them. It wasn’t worth the risk to customers.

We bring the same thinking to Continuum. Every feature we build goes through the same kind of review. That matters even more right now, because AI agents are starting to take real actions, and the security and identity layers around them are still maturing. If something would be too big a risk given where those layers are today, we wait until there are better measures in place to lock it down. Advisors trust us with their clients’ financial lives. A feature has to be worth that.

Step 7: Rehearse failure before it happens

Continuum is often the face of an advisor to their clients: the follow-up note, the page they open, the questions they ask afterward. What if that disappeared overnight?

It’s the right question to ask any vendor, and it’s something we exercise at least once a year. We’ve completed our 2026 round. We have three written plans: disaster recovery, business continuity, and incident response. Between them they cover any kind of situation, whether that’s a vendor issue that puts us at risk of not meeting our own policies, a security issue, or something in the backend that makes us unavailable or puts data out of reach for a period of time.

What does one of those exercises look like?

We run a simulated failure for each type of scenario, and the goal is to find the gaps in our process and our security model that would let something like that happen, or make it hard to recover from.

Here’s a real example. Permission to perform certain sensitive actions is restricted to a very small number of people on the team. Day to day, that’s exactly what you want. But what if those two people happen to be out at the same time? So you need an auditable break-glass process: in a serious situation, someone else can be granted the permissions they need, and we keep a record of who did what and why.

We also look at how long recovery takes. If a scenario caused an outage, what are our options to bring back the affected feature, or Continuum as a whole, as quickly as possible with as little disruption as possible? And how do we communicate with advisors while it’s happening? Incident management and legal obligations are part of the same drill.

Did this year’s exercise turn anything up?

It always does, and that’s the point. Whatever scenario you simulate, you’ll find something. We make the adjustments right away and keep narrowing our risk.

What should advisors ask their AI vendors?

If an advisor takes one thing from this conversation, what should it be?

Ask your vendors these questions, and expect clear answers:

1. What can the key you hold to my CRM actually do, and is that the minimum you need?

2. Where is the key that decrypts my data kept, and who can reach it?

3. If one of your services were compromised, what else could the attacker get to?

4. Who in my firm can see my meetings and notes by default?

5. Do you store audio recordings of my client conversations?

6. When did you last threat-model a feature, and have you ever decided not to ship one?

7. When did you last rehearse an outage or a breach, and what did you change afterward?

And if you’ve built something yourself with an AI API key this year, take ten minutes this week. Find where the keys live, rotate any that sat on a server you don’t control, and cut each connection back to what it actually uses.

Experimenting with AI is how practices find out what’s worth keeping. The key to your CRM is a copy of your client file. Store it like one.

Want to see how Continuum protects your practice? Visit our Security page or book a demo.