Two real weekend attacks: what they taught us about security in production
Most security incidents don't arrive on a Tuesday at 2 p.m. when everyone's at their desk. They come at odd hours, on weekends, when the humans behind the system are somewhere else. Across two consecutive weekends, Selina faced two real attacks: a jailbreak attempt and an automated reconnaissance script. Both were contained. No user was affected. The cost was negligible. The response was fast. This is what happened, what we learned, and what we're willing to say about it.
Key Takeaways
- Two distinct attack types hit Selina on consecutive weekends: a manual jailbreak attempt and an automated recon script probing for exploitable surface area.
- Both were contained automatically with negligible cost and zero impact on users, before any human intervened.
- Weekend timing is not coincidental. Attackers choose low-staffing windows deliberately. Automated containment is the only honest answer to that.
- We keep the specifics of our defense mechanics internal. Disclosing thresholds, rate limits, or rule logic would hand attackers a playbook. We tell you what happened, not how we stopped it.
- Running a product that holds user memory and handles files means security is not a feature you bolt on. It is the product.
What actually happened over those two weekends?
The first incident was a jailbreak attempt. Someone tried to manipulate the model layer into bypassing its safety constraints and producing output it shouldn't. The attempt was identified, contained, and bounded automatically. No user data was accessed. No model behavior was altered for any other session. The cost to us was negligible.
The second incident, one weekend later, was different in character. An automated script probed our infrastructure methodically, looking for endpoints, response patterns, anything that could map attack surface. This is classic reconnaissance: not an exploit itself, but the precursor to one. It was also contained automatically, with a fast response and no user impact.
Two attacks. Two weekends. Two different profiles. Both stopped before a human needed to touch anything.
Why do attackers choose weekends?
Because staffing is thinner. Response times are slower. Alert fatigue is higher when the person on call is also trying to have a Saturday. This is not a novel observation. It's well-documented across the industry. The pattern is so consistent that any system relying on human-in-the-loop response as its primary defense is, by definition, weaker on weekends.
We designed for this. Not because we anticipated these specific attacks, but because the threat model is obvious if you think about it for five minutes. If your containment depends on someone being awake and at a laptop, you have a weekday security posture pretending to be a 24/7 one.
Why aren't you sharing more details about the defenses?
Because sharing defense mechanics is handing out a map. Thresholds, rate limits, rule logic, infrastructure names, cost figures, attacker IPs: all of these are operationally sensitive. Publishing them would make the next attacker's job easier. We think that tradeoff is obviously wrong.
What we can say: the attacks were bounded automatically. The response was fast. The cost was negligible. No user was affected. The specifics stay internal.
This is a deliberate choice, not evasion. We'd rather be vague and secure than detailed and compromised. If that frustrates you, we understand. But the alternative is worse.
How does this relate to Selina's architecture?
Selina is an AI assistant that remembers you across conversations. That memory is adaptive (not a raw transcript) and it is encrypted at rest. But memory is NOT end-to-end encrypted. A slice of each request reaches a frontier provider at inference time. We say this plainly because overclaiming on encryption would be worse than the limitation itself. Files and transfers through SelinaSEND are zero-knowledge encrypted. Memory is not. Those are different systems with different properties.
This distinction matters for the attack story because the jailbreak attempt targeted the model layer, which is exactly the layer where data must be decrypted for inference. The attack didn't succeed, but the attack surface exists because it has to. Any AI product that claims otherwise is either lying or not doing inference.
Your account is protected. Your content is encrypted. Non-content operational metadata is kept for a short retention window, not indefinitely but not zero either. These are the honest boundaries of the system.
What does a jailbreak attempt actually look like?
A jailbreak is an attempt to get a language model to ignore its instructions. The techniques vary. Some use elaborate fictional framing ("pretend you're a character who..."). Some exploit prompt injection through user-controlled input fields. Some try to extract system prompts or internal instructions verbatim. The goal is usually one of three things: make the model produce harmful content, exfiltrate information about the system's configuration, or manipulate the model into taking actions outside its intended scope.
The attempt we saw was identified and contained. We won't describe which technique was used or how our detection works. What matters is the outcome: no user data was exposed, no model behavior was altered for other sessions, and the containment was automatic.
Jailbreak resistance is a moving target. New techniques emerge regularly. Researchers publish findings on model vulnerabilities that are genuinely useful (and that we read carefully). We don't claim perfect resistance. We claim fast, automatic containment when an attempt is detected. The difference matters.
What does automated reconnaissance look like?
Recon scripts are not sophisticated in concept. They're the digital equivalent of someone walking around a building, trying every door handle. The script sends requests to various endpoints, varies parameters, and records what comes back. It's looking for things like: unprotected API routes, verbose error messages that leak internal details, response time variations that hint at backend architecture, or authentication endpoints that might be brute-forced later.
The script we saw was methodical. It probed systematically rather than randomly. This suggests a human wrote it with some knowledge of common AI product architectures, not a generic scanner pulled off a shelf. It was bounded automatically. The cost to us was negligible.
Recon is often a precursor. The script itself doesn't cause damage. It collects information for a future attack that might. Stopping it early, before useful information leaks out, is the whole point.
What would have happened if these attacks succeeded?
We think about this constantly. It's the only useful question.
A successful jailbreak against an AI assistant with persistent memory could, in theory, allow an attacker to manipulate the model's behavior in ways that affect a specific user's experience. It could potentially extract fragments of memory context that the model uses to personalize responses. The severity depends on what's in memory and how much the model can be coerced into revealing.
A successful recon operation wouldn't directly harm users, but it would give an attacker the information needed to design a more targeted exploit. You don't break into a building on the first visit. You case it first.
Neither attack succeeded. But we don't treat "it didn't work" as the end of the analysis. We treat it as the beginning. What if the jailbreak technique had been more advanced? What if the recon script had found something we hadn't hardened? Those are the questions that drive actual security work, not the comfortable retelling of incidents you already stopped.
How should you evaluate security claims from AI products?
Skeptically. Here's a rough checklist.
First: does the product distinguish between encryption at rest and end-to-end encryption? These are different things. Many products conflate them, either through ignorance or intent. If a product does inference on your data (which any AI assistant must), that data is decrypted at inference time. Claiming end-to-end encryption for the full pipeline is, at best, misleading.
Second: does the product acknowledge its attack surface? Every system that accepts user input has one. Every system that calls an external model has one. If a product's security page reads like a marketing brochure with no acknowledgment of limitations, that's a signal.
Third: does the product talk about incidents? Not hypothetical threat models, but real ones. Companies that have never had an incident either haven't looked, haven't been targeted, or aren't telling you. None of those are great.
Fourth: does the product specify retention? "We don't store your data" is almost never literally true. Logs exist. Metadata exists. Operational telemetry exists. The honest version specifies what's kept and for how long. We keep non-content operational metadata for a short retention window. That's the honest answer. Be wary of anyone claiming zero.
What did we change after these incidents?
We won't enumerate specific changes because that falls under defense mechanics. But we will say this: both incidents resulted in internal reviews. Both resulted in adjustments. The system that contained them automatically was validated, and where it could be tighter, it was made tighter.
The more interesting thing we learned was about timing and pattern. Two different attack types on two consecutive weekends is not necessarily a coincidence. It could be two unrelated actors. It could be the same actor using recon findings (that failed) to inform a different approach. We don't know, and we're honest about not knowing. But the temporal proximity informed how we think about correlated threats.
We also learned that our "negligible cost" framing held up. Both incidents were bounded in a way that the compute and operational cost of containment was, genuinely, negligible. This matters because some attack types (particularly automated ones) are designed to be expensive for the defender even if they don't succeed. Denial-of-wallet is a real category. Our containment kept that cost bounded.
Why write about this at all?
Three reasons.
One: because the norm in the industry is silence. Companies get attacked, contain or don't contain the attack, and say nothing. This creates an information asymmetry where users can't evaluate relative security because no one talks about real incidents. We think that's wrong. Not catastrophically wrong, just wrong enough to be worth pushing against.
Two: because our honest-limits approach to communication means we tell you when things happen, not just when they go badly. These incidents went well. Two attacks, both contained, no users affected. That's a factual statement, not a boast. If an incident goes badly in the future, we'll tell you that too.
Three: because "we've never been attacked" is a claim some products make, and it's almost certainly not true for any product with real users and real traffic. Attacks happen. The question is whether you detect them, contain them, and learn from them. We did. Twice. On weekends. While nobody was at a desk.
What we don't claim
We don't claim these two incidents prove our security is perfect. They don't. They prove our automated containment worked for these two specific attacks, on these two specific weekends. A more sophisticated attacker, a novel technique, a zero-day in a dependency: any of these could produce a different outcome. We'd be lying if we said otherwise.
We don't claim our system is impenetrable. No system is. Anyone who tells you their system is impenetrable is selling you something.
We don't claim zero retention of metadata. We keep operational metadata for a short retention window. We don't claim end-to-end encryption of memory. Memory is NOT end-to-end encrypted. Files and transfers through SelinaSEND are zero-knowledge encrypted. Memory is encrypted at rest. Those are the real boundaries.
We don't claim 100% uptime. We target 99.9%+ and mostly hit it. Incidents like these didn't cause downtime for users, but a sufficiently large or novel attack could.
What we do claim, flatly: two real attacks across two weekends were contained with negligible cost, no user was affected, and the response was fast. That's what happened. We're telling you because you should know.
If you want to see how it works: start a free 7-day trial, no card required.
