A Network Anomaly Observed in May 2025 and the Design Decisions That Followed — A Public Record of the So-Called “May Incident” Introduction This article documents a network anomaly that occurred in my personal environment in May 2025, based on confirmed facts, decisions made at the time, and the background behind the current architecture that followed. There is no intention to accuse or definitively attribute responsibility to any individual or organization. This is published purely as a technical and operational incident record, from a practitioner’s perspective. ⸻

1. Overview of the Incident (Confirmed Facts) In mid-May 2025, a series of non-standard behaviors were intermittently observed across my home network and related cloud environments. These included: • Suspicious access attempts from external IP addresses • Traces suggesting partial log loss or possible modification • Unexpected access paths to management-related services • Discrepancies between observed network behavior and perceived performance A key characteristic was that these events were not isolated, but occurred over time and from multiple directions. ⸻

2. Network Assumptions at the Time At that point, the environment was close to a typical home or small-scale setup: • An always-on router • Direct connections to cloud services • Some management functions exposed externally In other words, it was a convenience-first configuration, prior to security optimization. This is a realistic baseline shared by many individuals and small organizations. ⸻

3. What Triggered Concern The decisive factors were: • Mismatches between network logs and actual usage • Access patterns by time and region that would not normally occur • Behavioral changes despite no intentional configuration updates Each of these alone could be dismissed as noise. However, their overlap made coincidence unlikely. ⸻

4. Decisions and Response at the Time At that stage, I deliberately chose to: • Avoid rushing to identify the root cause • Prioritize minimizing potential impact • Preserve logs and configuration states This can be summarized as a “do not chase, do not provoke” approach. As a result: • No direct escalation of damage was observed • Logs and evidence remained available for later review ⸻

5. Why It Did Not Escalate In retrospect, several factors likely contributed: • Many management functions were not used continuously • The environment was personal, with relatively simple privilege separation • Anomalies were not dismissed as mere intuition More than specific tools, the critical factor was whether one can stop and reassess when something feels off. ⸻

6. Design Decisions That Followed This experience led to a fundamental shift in design philosophy: • Moving away from perimeter-based assumptions • Eliminating direct external exposure • Favoring architectures that are understandable at a glance over constant monitoring The current setup has transitioned to: • A Cloudflare-centered Zero Trust architecture • Clear role separation across devices • Operations designed around the assumption that logs must reliably remain In this sense, this incident became the starting point for what I later came to describe as a “Guardian Worker”-style design philosophy. ⸻

7. Closing Thoughts The term “May Incident” is simply my own internal label. It was neither a major breach nor a newsworthy event. However, many people are operating under the same assumptions and making the same decisions. I hope this record serves as a reminder that moments when “nothing seems to be happening” are often the best time to pause and reassess. ⸻ This article is a public version. Technical details, raw logs, and a full chronological record are maintained privately. ⸻ This record marks the point at which my network design shifted from reactive defense to intentional architecture.