Security Is a Moving Target: The Shared Reality of Building — and Using — AI

There is a sentence I've learned to distrust in this industry, and it's a short one: "It's secure."

Not because the people saying it are careless — usually they mean it, and on the day they say it, it's often true. I distrust it because of the tense. "It's secure" describes a state, a finished condition, a box that got checked. And nothing about building or using AI is a finished condition. The ground moves. It moves for the people building the tools, and it moves — quietly, invisibly — for the people using them.

I want to write plainly about that, because it's the part most product marketing is built to hide. Security in AI is not a destination you arrive at. It's a target that keeps moving, and the honest thing is to design for that instead of pretending you've stood still long enough to nail it down.

The surface expands faster than the playbook.

Every new capability opens a new way to be exposed, and it does it faster than anyone can write the guidance for it. That isn't pessimism — it's just the shape of a field moving this quickly. The manual is always being written after the fact.

Anyone who has actually built on this stack has felt it. A dependency you trusted last month ships a change that becomes a liability this month. A permission granted once, for a good reason, and never revisited. A credential created during setup that does exactly nothing useful and sits there anyway, a key under a mat everyone forgot was there. A model your product leans on that was available on Tuesday and — by an order nobody published — switched off worldwide by Friday. We wrote about exactly that happening a few weeks ago, and the lesson wasn't "pick a different model." It was that the ground under you can move for reasons that have nothing to do with your own code.

None of this is a reason not to build. It's a reason to build differently — to assume that something, somewhere, will shift, and to design so that when it does, the damage is small, the exposure is visible, and the recovery is fast. That's a very different posture from "it's secure," and it's a far more honest one.

It cuts both ways — and the user's side is the one nobody shows them.

Here's the part I think about most, because it's the part that doesn't get said out loud. When you use an AI product, you are not just trusting the product. You are trusting the entire chain behind it — the model provider, the cloud it runs on, the dependencies its builders pulled in, the humans who hold the keys, and every decision any of them makes after you clicked "agree."

The builder at least gets to see their exposure. They can read their own logs, audit their own keys, watch their own dependencies. The user inherits an exposure they can't see at all. Where does my data actually go? Who, or what, can read it? Is it being used to train something that outlives my relationship with this company? What happens on the day the vendor's own security shifts — and will I ever even find out?

In most consumer AI, the honest answer to those questions is: you can't know, and you're not meant to. The exposure is real, it's just not yours to inspect. That asymmetry is fine when the stakes are a summarized email. It is not fine when the data is a patient's medical history.

Why "we're secure" is the wrong promise.

If security is a moving target, then any promise phrased as a finished state is a promise with a shelf life. "We passed the audit." "We're certified." "We're secure." Each of those is true on a date, and every one of them starts expiring the moment it's said. They aren't lies. They're snapshots, quietly presented as though they were permanent.

The promises that actually hold up are the ones about architecture, not status — the structural choices that stay true even after the surface shifts again. There are three I'd stake a healthcare product on, and they're the three ARAGS is built around.

Notice what those three have in common: not one of them claims nothing will ever go wrong. They assume the opposite. Identity means there's no dormant secret to leak. Containment means a bad day stays small. Auditability means you find out. That's what designing for a moving target actually looks like — you stop promising the target will hold still, and you start making sure a hit doesn't take the whole system with it.

If you're the one using AI, this is what to ask.

I'd rather hand you a way to judge for yourself than ask you to take my word, because "trust me" is exactly the sentence this whole post is arguing against. So if you're a clinic, an administrator, or anyone weighing an AI product that will touch information you're responsible for, here is what I'd want you to press on — of us, and of everyone else:

• Where does my data physically live, and is it mixed with anyone else's? "In the cloud" is not an answer. Isolation is either a design fact or it isn't.
• Is my data used to train anything? If the answer needs a paragraph, it's a yes.
• Can you show me what the system did? Not what it's allowed to do in principle — what it actually did, on a real record, after the fact.
• What happens on your worst day? Not whether one can happen — it can — but how far it reaches, how fast you'd know, and how you'd tell me.

A vendor who is comfortable being asked those questions is telling you something. So is one who isn't. You are not being difficult by asking; you are doing the exact job the moving target requires of the person at the receiving end of it.

Security as a practice, not a finish line.

I'll be honest about where this leaves a young company like ours: it leaves us doing the work continuously, because the alternative doesn't exist. There is no version of this where we secure the thing once and move on. The surface will move again. A dependency will surprise us. A norm we build on today will be revised. Treating security as an ongoing practice — auditing what we don't need, closing what we're not using, designing so a bad day stays a small day — isn't a burden we've accepted. It's the only posture that survives contact with how fast this field actually moves.

That's also, I think, the most trustworthy thing a builder can say to the people who use what they make. Not "it's secure." That sentence has a shelf life. The durable one is quieter: we assume it will be tested, we built so that a hit stays small, and we made it so you can see for yourself. In a field where the target never stops moving, that's the promise worth making — and the only one worth believing.