Bounded damage by design: the security model that assumes the wall already fell

Most security architectures are perimeter stories. Firewall here, WAF there, rate limiter at the gate. The implicit promise is that if the outer wall holds, everything inside stays safe. We built Selina on the opposite assumption: the wall has already fallen, and the system's job is to bound the damage automatically and fast. This piece explains why, and what that looks like in practice.

Key Takeaways

• Selina's security model does not depend on the perimeter holding. Even if every front-door defense fails simultaneously, damage is bounded automatically and quickly by design.
• Perimeter-only architectures create a binary outcome: either the attacker is fully outside or fully inside. Bounded-damage design turns a binary into a gradient, where the worst case is still small.
• This is not a claim of perfection. Memory is NOT end-to-end encrypted (a slice of each request reaches a frontier provider at inference). Files and transfers via SelinaSEND are zero-knowledge encrypted. We state both facts because honesty about limits is the only credible posture.
• The approach borrows from structural engineering (crumple zones, bulkheads) more than from traditional infosec playbooks, and it changes the economics of attack.

What does "bounded damage" actually mean?

It means the architecture caps the blast radius of any single compromise, regardless of how that compromise happened. The perimeter can fail. Auth can fail. An upstream dependency can misbehave. In each scenario, the amount of data exposed, the cost incurred, and the time window of exposure are bounded automatically, not by a human noticing something in a dashboard at 3 a.m.

Think of it less like a castle wall and more like a ship's hull. A ship doesn't rely on never hitting anything. It has bulkheads. Water enters one compartment, not the whole vessel. The ship stays afloat with several compartments flooded. The Titanic famously had bulkheads too, but they didn't extend high enough. Design details matter. So we are careful about which details we share publicly (we keep exact thresholds and internal mechanics private for obvious reasons) and which ones we state plainly.

Here is one thing we state plainly: the system is built so that even if every front-door defense fails, damage is bounded automatically and quickly. That is the core claim. We do not claim zero damage. We claim bounded damage.

Why do perimeter-only models fail?

Perimeter-only models fail because they create a single binary: in or out. Once an attacker is "in," the implicit contract with the user is void. Everything behind the wall was designed for trusted actors, and now an untrusted actor is inside.

This failure mode is not theoretical. It is the structure of most breaches you have read about. An API key leaked. A dependency was compromised. A session token was stolen. The interesting part is never how they got in. It is what happened next, and why "what happened next" was so catastrophic. The answer is almost always: because nothing inside was designed to limit the blast.

A few specific patterns we see repeatedly:

• Flat internal networks where lateral movement after initial access is trivial.
• Shared secrets or tokens that, once obtained, grant access to the full dataset rather than a narrow slice.
• Cost structures where a compromised account can rack up unbounded spend against inference APIs or storage before anyone notices.
• Logging and alerting that depends on the same perimeter the attacker already bypassed.

Each of these is a design choice, usually made implicitly by not choosing otherwise. Bounded-damage design is the practice of choosing otherwise, explicitly, at every layer.

How does Selina bound damage in practice?

We keep the specific mechanics internal. This is deliberate. Publishing exact thresholds, rate-limit numbers, or cost caps would hand an attacker a precise optimization target. What we can describe is the philosophy and its observable properties.

The system enforces limits automatically. No human has to be awake. No alert has to fire and be acknowledged. If a front-door defense fails, subsequent layers constrain what can happen next, how much of it can happen, and for how long. These constraints apply to data exposure, cost, and time. They are structural, not procedural.

"Structural, not procedural" is an important distinction. A procedural control is a runbook: "If X happens, do Y." A structural control is a physical (or logical) property of the system: "X cannot produce more than Y regardless of what anyone does or fails to do." We prefer the latter because procedural controls depend on people and processes that degrade under pressure, at 3 a.m., over holidays, and during exactly the moments when they matter most.

What about the inference layer?

This is where we are honest about a real limit. Selina routes requests through a stack of frontier models, routed per task. At inference time, a slice of each request reaches an external provider. This means memory is NOT end-to-end encrypted and is NOT zero-knowledge encrypted. Content is encrypted at rest, and the account is protected, but the inference path inherently involves a third party seeing some data.

We do not try to paper over this. It is a constraint of the current state of frontier AI infrastructure. Anyone who tells you they run frontier-class models with zero-knowledge inference is either running their own models (with the capability trade-offs that implies) or not being forthright about their architecture.

Files and transfers sent through SelinaSEND are a different story. Those are zero-knowledge, end-to-end encrypted. We can and do make that claim for that specific feature. We do not extend it to memory, because it would not be true.

Non-content operational metadata is retained for a short retention window, not indefinitely, but also not zero. Again, honest statement of fact.

Why is the economics of attack the right frame?

Because most attackers are rational. Not all, but most. They optimize for yield over effort. If your architecture makes the yield of a successful breach enormous (full database, unbounded API spend, persistent access), you are an attractive target regardless of how strong your perimeter looks. If your architecture makes the yield of a successful breach small (a narrow slice of data, negligible cost, fast automated response), you become a less interesting target.

This is not security through obscurity. It is security through genuinely reduced payoff. The attacker can know your philosophy, can know that damage is bounded, and that knowledge itself is a deterrent. Contrast this with a perimeter model, where the attacker knowing your architecture is almost always bad news.

We think about this in terms of three quantities:

1. The maximum data exposure from any single compromise path.
2. The maximum cost an attacker can impose before automated limits engage.
3. The maximum time window before the system self-limits, independent of human intervention.

Each of these has an upper bound in our system. We do not publish the bounds, but they exist as design parameters, not aspirations.

How does this compare to a traditional defense-in-depth approach?

Defense in depth is the right instinct, wrong execution, most of the time. The canonical version stacks concentric perimeters: network firewall, then application firewall, then auth layer, then access control, then encryption at rest. Each layer is a wall. The theory is that an attacker has to breach all of them.

The problem is that the layers are often not independent. A credential that bypasses the auth layer frequently also bypasses access control, because both layers trust the same token. A vulnerability in the application layer often renders the network-layer controls irrelevant, because the traffic looks legitimate. The "depth" is sometimes illusory, several walls that all have the same door.

Bounded-damage design is compatible with defense in depth but adds a different question at each layer. The traditional question is "can this layer stop the attacker?" The bounded-damage question is "if this layer fails, what is the maximum blast radius?" If you can answer the second question with a specific, small number, you have a bounded system. If the honest answer is "everything," you have a perimeter system with extra steps.

What does this look like from the user's side?

Ideally, invisible. The constraints are designed to be high enough that legitimate use never hits them and low enough that illegitimate use is capped before it matters. You should not experience bounded-damage design as friction. You should experience it as the absence of catastrophe.

There are a few user-facing manifestations worth mentioning:

• Delete means gone. Actually gone. When you delete data in Selina, that is a structural operation, not a soft flag in a database that might be reversed by an attacker with write access. This limits the window of exposure for any data you decide to remove.
• Your account is protected with controls that do not depend solely on your password. Even a compromised credential does not produce unbounded access.
• SelinaSEND files are zero-knowledge encrypted, meaning neither we nor an attacker who compromises our infrastructure can read them in transit or at rest.

What we do not claim: we do not claim unlimited anything. Credits are finite. Memory is adaptive, not a verbatim transcript of every interaction. Uptime is 99.9%+, not 100%. These are real-world systems with real-world constraints, and stating the constraints is part of the design philosophy, not a footnote.

Why does this matter for AI assistants specifically?

AI assistants with memory create a new category of risk that traditional web applications do not face. A stateless API processes a request and forgets it. An assistant that remembers you accumulates context over time. That context, your preferences, your patterns, the things you have told it, becomes a high-value target precisely because it is useful.

The value of the memory store grows with use. This is good for the user (the assistant becomes more helpful) and simultaneously increases the stakes of a breach. A perimeter model says "we will keep attackers out of your memory." A bounded-damage model says "even if an attacker reaches your memory, here is the maximum slice they can access, and here is how quickly the system responds."

We built Selina to remember you. That is the product. But building a product that accumulates sensitive context and then protecting it only with a perimeter would be, frankly, negligent. The bounded-damage model is not a feature we added. It is the architectural response to the specific risk that a memory-bearing AI assistant creates.

What are the limits of this approach?

Several, and we should name them.

First, bounding damage is not preventing damage. A bounded breach is still a breach. The claim is that the worst case is small, not that the worst case is zero. If your threat model requires zero breach probability, no system satisfies it, and anyone who says otherwise is selling you something.

Second, the bounds themselves are design parameters. We set them based on our judgment of the trade-off between usability and safety. A tighter bound means more safety but potentially more friction for legitimate heavy users. We think we have the balance right, but "right" is a judgment call, not a mathematical proof.

Third, the inference-layer exposure is real. Memory is NOT zero-knowledge encrypted. A frontier provider processes a slice of your data. We mitigate this (content is encrypted at rest, operational metadata has a short retention window, routing is designed to minimize exposure), but we do not eliminate it. Eliminating it entirely with current frontier models is not feasible without running your own models, which introduces a different set of trade-offs around capability and maintenance.

Fourth, this model works best against rational, economically motivated attackers. A state-level actor with unlimited resources and a specific target is a different threat model. We do not claim to solve that. We claim to make the economics of attack unfavorable for the vast majority of threat actors, which is most of them.

How did we arrive at this design?

By watching what actually goes wrong. Not in abstract threat modeling sessions (though we do those too), but in real incidents across the industry. The pattern is remarkably consistent: the initial access vector is rarely exotic. It is a leaked key, a misconfigured permission, a dependency with a vulnerability. The catastrophe comes from what happens after initial access, specifically, from the absence of internal limits.

We asked ourselves a simple question early on: if we assume the attacker is already inside, what do we want the system to do? The answer was not "alert someone" (though it does that too). The answer was "cap the damage structurally, before anyone has to respond." That question shaped the architecture from the start. It was not retrofitted.

This is the difference between a system that happens to have rate limits and a system that is designed around the assumption of breach. The rate limits in the first system are tuned for cost management. The bounds in the second system are tuned for damage containment. Same mechanism, different intent, different design altitude.

What should you look for in any system that stores your context?

If you use any AI assistant (ours or otherwise), here are questions worth asking:

1. If my credentials are compromised, what is the maximum data an attacker can extract before the system responds? If the vendor cannot give you a specific, bounded answer, the answer is "all of it."
2. Is damage containment structural (built into the system's architecture) or procedural (dependent on an ops team noticing and responding)? Structural is better. Procedural fails at 3 a.m. on a holiday.
3. What specific data reaches third parties at inference time? Any vendor using frontier models sends some data to a provider. The honest ones tell you what and how much.
4. What happens when I delete data? Is it a soft delete (flagged, not removed) or a hard delete? Can an attacker with database access reverse it?
5. What is the retention policy for operational metadata? "Zero retention" is almost certainly not true for any production system. "Short retention window" is honest. Ask how short.

These are not gotcha questions. They are structural questions about how the system behaves under adversarial conditions. The answers tell you whether the vendor has thought about breach as a design constraint or merely as a thing to prevent.

The bottom line

We built Selina to remember you. That creates a security obligation we take literally. The bounded-damage model is our answer: assume the wall falls, and engineer the interior so the worst case is still small. Memory is encrypted at rest but is NOT end-to-end encrypted, because inference requires a frontier provider to see a slice of the data. Files via SelinaSEND are zero-knowledge encrypted. Delete means gone. Damage is bounded automatically, quickly, structurally.

We do not claim this makes the system invulnerable. We claim it makes the system's worst case dramatically smaller than architectures that rely on the perimeter holding. That is a more modest claim and, we think, a more honest one.

If you want to see how this feels in practice: start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io