The reason I finally had to was Wazuh.

My Proxmox host, lab0, was sitting on 32GB of RAM. I restarted it fresh, and it climbed right back to 63% memory utilization; on a normal day when I’m not touching anything, it drifts up to 70% or 71%. Almost all of that is one node. Wazuh was pulling around 18GB immediately after boot and creeping toward 30GB the longer it stayed up.

That’s what finally pushed me. It wasn’t that anything was broken; it’s that nothing new could ever get built. Every time I thought about spinning up another VM for a project, the math said no before I even got to the fun part. So I had to upgrade the memory.

Two G.SKILL Ripjaws V DDR4 sticks, 16GB each, to take the host from 32GB to 64GB. $239, which stung a little. If you’ve priced memory recently, you already know why: AI demand has RAM in a strange place right now, and DDR4 didn’t get a pass. Not an outrageous number for 32GB, but definitely a premium over what I paid for the original build.

Before I pulled power on anything, I did one small thing that I’d recommend to anybody about to do the same job. I went into the Wazuh VM options in Proxmox and turned on start at boot. It takes thirty seconds, and it means that when the host comes back, your important VMs come back with it. Then I shut the node down cleanly, powered off the machine, and unplugged it.

Where it started going wrong

Two open DIMM slots, two new sticks. I had this pegged as a fifteen-minute job.

The first one went in fine. Lined up the notch, pressed down, heard the click, felt pretty good about myself. I flipped the lever on the second slot, slid that stick in, and it felt locked, so I closed everything up, plugged the machine back in, and hit power.

Yellow light.

I gave it time, because I didn’t expect it to post instantly, and I kept refreshing the Proxmox page like that would help. It stayed yellow. Then, on a later attempt, it went red, and red is what actually worried me. So I looked both up, and it turns out the board had been telling me exactly what was wrong the entire time.

Solid yellow or amber on the DRAM light means memory failed the power-on self-test. Red means the system can’t detect a component at all.

Fine. Something’s loose. I powered down, opened it back up, and started reseating.

The thing I didn’t know about DDR4

This is where I burned most of the evening, and where the actual lesson lies.

I pulled the sticks and pushed them back in, and nothing changed. Did it again; still yellow. I was being careful, because these things are expensive and they feel fragile, and I kept thinking I was going to crack something. At one point I caught myself wondering if I was the problem, doing this on my office floor, in bad light, wearing jewelry, not grounded, which is a pretty complete list of what you’re not supposed to do.

I was the problem, just not in the way I assumed.

Read more

But 2026 isn’t the environment I came up in, and if I were 18 again walking into my first semester, I’d do this very differently.

Three things changed. More people hold a degree and a Security+ than there are entry-level seats for them. AI is already doing a chunk of what used to be somebody’s first job: summarizing logs, writing basic scripts, drafting first-pass triage. And the biggest threat to actually building skill now isn’t a lack of resources. It’s your attention.

Also, my goal wouldn’t be to graduate with a degree. It would be to graduate with four years of evidence, starting week one, that I belong in this industry.

I wouldn’t assume I need a cybersecurity degree

I’d be choosing one of three degrees: Computer Science, IT or Information Systems, and Cybersecurity. All three get you here. The real question is what foundation you want underneath security.

CS goes deeper on programming, algorithms, data structures, and computing theory. IT puts you on the systems side: networking, operating systems, infrastructure, cloud, server administration. Cybersecurity programs give you a security-focused curriculum from day one.

I did IT, and that systems foundation has been immensely useful because security engineering is still engineering. You can’t investigate a Linux server without understanding Linux. You can’t analyze network traffic without understanding networking. You can’t secure AWS if you’ve never deployed anything to it. However, I had to learn to code on my own.

There’s a newer wrinkle too. AI writes code, generates configs, and explains concepts faster than almost any professor. Genuinely useful. It also means the value isn’t in memorizing syntax anymore. It’s in understanding systems well enough to know when the AI system is wrong. In security and compliance work, being confidently wrong about a control is how you get breached, not just how you get a bad grade.

So I wouldn’t ask whether the degree says cybersecurity. I’d ask what I’ll actually know how to do when I finish it.

I’d weigh the boring stuff seriously, too: cost, flexibility, the real curriculum, and whether the school is thinking about what happens after graduation or just during it.

Freshman year: apply before you feel ready

This is the one part of my own story I’d repeat exactly, and lean into harder.

I got my first internship freshman year at a company called BenefitMall. Not by applying to Amazon or Google. I got it by applying to smaller local companies after getting turned down everywhere else. By sophomore year, I had a cybersecurity engineering internship offer from Intel in June, two months before the start date, after people told me it was already too late to try.

Most advice says spend years one and two getting ready, then chase internships junior year. In 2026, I think that’s dangerous. If the entry-level market is already tight and AI is already absorbing the easiest first-job tasks, waiting two years to build verifiable experience means starting the race two years behind.

So freshman year I’d do two things at once, not in sequence.

• Learn fundamentals. Networking, Linux, Windows, basic programming, Git. How operating systems work. What DNS actually does. What happens when two computers talk to each other. Processes, permissions, authentication.

• Apply that same semester. Help desk, sysadmin, cloud, networking, anything that puts me around real infrastructure. You are never going to feel ready. I didn’t. You get the internship first, and the readiness catches up.

And alongside both, a homelab. VirtualBox, VMware, Proxmox if I have spare hardware. A Linux box, a Windows machine, maybe a Windows Server. I’d break things on my own time and figure out how to fix them.

I broke down the full internship strategy (resume, technical prep, timing, target companies, interviews) here:

Sophomore year: the lab becomes cyber-focused

Ideally, I’m interning again with more responsibility, and layering security onto that IT base. How Active Directory works and how attackers abuse it. What an EDR actually sees. What gets logged when someone authenticates. What malicious PowerShell looks like next to normal PowerShell.

That’s when the IT lab turns into a real security lab. Deploy Wazuh, Splunk, or Security Onion. Collect Windows logs with Sysmon and Linux logs alongside. Generate telemetry, attack your own environment, then go look at it from the defender’s chair.

This is also where I’d use AI deliberately: explain a concept I’m stuck on, debug a script, quiz me on what I just learned. Not generate a detection rule without understanding.

If you can’t explain what the AI gave you, you haven’t learned anything. You’ve outsourced the exact part of the job that was supposed to make you employable.

Certifications, with receipts attached

Somewhere in year one or two: Security+, maybe Network+ if networking is shaky, maybe a cloud cert.

I made this mistake myself. It’s easy to get addicted to collecting them. Every “congratulations, you passed” screen feels like progress, and it is. But passing an exam proves you can pass that exam. AI has made cramming multiple-choice easier than ever, so a cert alone tells an employer less than it did five years ago.

Certs support learning; they don’t replace it. Security+? Put a project next to it. AWS cert? Show me what you built in AWS.

The fight that runs all four years

When I was in school, there were distractions, but they weren’t engineered against me the way they are now. Short-form video, endless feeds, notifications, all designed to fragment your attention into smaller pieces.

The skills that matter here require the opposite. Reading logs carefully. Following a chain of reasoning through an investigation. Sitting with a problem you don’t understand yet. Sustained, boring, uninterrupted focus.

So I’d treat homelab time like a class I can’t skip. Phone in another room, one task, a timer if needed. And I’d be honest about the difference between learning and consuming content about learning. A two-hour video on AD attacks feels productive. Two hours building and attacking your own AD, getting it wrong four times before it works, is productive.

Everyone has the same tutorials and the same AI now. The differentiator isn’t access to information. It’s who can sit still long enough to use it.

Years two and three: pick a direction

Cybersecurity isn’t one job. Detection engineering, cloud security, AppSec, pentesting, security engineering, incident response, threat intel, GRC, identity. At some point you have to go deeper.

I didn’t start in detection engineering. I started in a SOC on tier-one alerts and worked my way in. Picking a direction doesn’t mean landing there day one. It means having a target instead of drifting.

Then build toward it. Detection engineering: write detections, generate telemetry, learn Sigma, learn how logs get parsed and normalized, learn Python. Cloud security: build environments, learn IAM, Terraform, containers, Kubernetes, cloud logging. AppSec: write a lot more code, learn CI/CD, learn how applications actually get built.

The goal is walking into an interview with something you built, broke, and fixed, not a summary of a course you watched.

Senior year should be boring

If the earlier years went right, I’m not scrambling for a first internship. I’ve had two or three, probably with a return offer or at least a team that knows my work. Degree nearly done, a couple certs, real projects, a homelab, a clear direction.

Now I document properly. GitHub. Writing about what I’m learning. Talking to people already doing the job I want. That’s literally what became Cyberwox for me. Documenting my own journey publicly turned into a body of work that speaks for itself in a way a resume never could.

And I’m applying for full-time roles before graduation, not after somebody hands me the degree.

What I’m Taking Away From This

The shift is timing, not credentials. Not which degree or which certs. It’s refusing to split college into two years of preparing and two years of doing.

Every piece has one job. Classes give structure. The degree gives a credential. Certs give focused learning. Projects give practical experience. The homelab gives somewhere to experiment. Internships starting freshman year give real exposure early enough to compound. Documenting all of it gives proof.

Attention is the actual scarce resource. AI raised the floor on information access and did nothing for your ability to focus for three uninterrupted hours, which is exactly why that ability is worth more now.

The Challenge

You don’t need your career figured out at 18. I definitely didn’t. Explore, build things, break things, find what you’re actually interested in.

But don’t treat the degree as the destination, and don’t assume you have time to wait.

So do one thing this week: apply to one internship you feel unqualified for, or spin up one VM and start the lab. Then reply and tell me which, or drop it in the Discord.

Graduation shouldn’t be where your cybersecurity journey starts. It should be where you cash in four years of proof.

Sources and further resources for this issue:

Interested in sponsoring Cyberwox?

Sponsoring Cyberwox helps me continue creating practical cybersecurity education, labs, and industry analysis while connecting your brand with a trusted multi-platform audience of 120,000+ cybersecurity practitioners, engineers, students, founders, and technology leaders across the global cyber community on our YouTube, LinkedIn, X, & Substack 🌎

Learn More Here 🚀

Until Next Time

That’s it for this one.

As always, keep learning, keep building, and keep thinking deeply about the systems we’re trusted to defend.

See you in the next one.

~ Day 💙

Watching tutorials helps. Taking notes helps. Even stacking up certifications helps, a little. But none of that forces you to touch packets, break something on purpose, read your own logs, secure an app, deploy infrastructure, and then explain what you actually built.

So this issue is my answer to that gap: five cybersecurity projects that map directly to real skills, network analysis, cloud and container security, secrets management, Kubernetes, SOC operations, and detection engineering. I’ve either built these myself on the channel or worked through similar examples already, so I’m linking the receipts as I go.

Why I Think Watching Isn’t Enough Anymore

A lot of people say they want security operations, threat hunting, incident response, or blue team work, and then skip the fundamentals entirely.

The goal is not to become a packet wizard overnight. The goal is to build the muscle to look at traffic and say, “Okay, I understand what is happening here.”

That line applies to basically every project below. None of these are “beginner project” ideas that sound good on a resume and teach you nothing. Pick one, build it, and document it like you’d document work you actually got paid for.

Project 1: Build a Network Traffic Analysis Lab

So much of security still comes back to understanding what’s actually happening on the wire. Set up a couple of virtual machines, generate normal traffic (browse the web, SSH into a box, transfer a few files), and capture it with Wireshark.

Then start interrogating it:

• What does normal DNS traffic look like?

• What does an SSH connection look like?

• What changes once traffic is encrypted?

• Can you identify the source, destination, protocol, port, and purpose?

Once you’ve got a feel for “normal,” introduce something suspicious: run a basic port scan, simulate a file download from a shady host, or replay a PCAP from a malware analysis challenge. That skill translates directly into SOC work, incident response, and detection engineering.

I’ve already worked through this kind of analysis on the channel:

A Quick Word on Python and SQL

Many of these projects are hands-on, but two foundational skills make them easier: Python and SQL.

Python shows up everywhere in this field: parsing logs, hitting APIs, automating repetitive tasks. SQL matters just as much once you’re touching logs, SIEMs, and dashboards, because most security work is really just asking better questions of data.

Every modern SIEM you’ll touch- Splunk, Sentinel, Chronicle, Elastic- is essentially SQL under the hood. Pivoting through auth logs for lateral movement, correlating DNS queries against a threat feed, building a dashboard of failed logins by user: that’s SQL.

I partnered with DataCamp for this one, for exactly that reason. I’d point you to their Python Programming Fundamentals and SQL Fundamentals tracks, both around 12 hours and hands-on the whole way through, with a certification at the end for your resume or LinkedIn.

You only retain about 20% of what you passively consume. When you’re actively writing code, that jumps to 75 or 90%.

That’s the actual reason I’ve been using it myself to keep those skills sharp: DataCamp Python Fundamentals and DataCamp SQL Fundamentals.

Project 2: Securely Containerize a Basic App

This one is underrated. A lot of people want to jump straight to cloud security or DevSecOps without ever containerizing an application themselves, and I don’t mean copying a Dockerfile off the internet and running it docker build.

Take a basic Flask app, a Node app, or something intentionally vulnerable, containerize it, and then secure it. Ask yourself:

• Am I running this container as root?

• Do I need every package inside this image?

• Are there secrets hardcoded in the app?

• Did I expose unnecessary ports?

• Can I scan this image for vulnerabilities?

This bridges the gap between “I know cybersecurity theory” and “I can actually secure something engineers use,” because in the real world, security teams spend as much time on how software is built and shipped as they do triaging alerts.

Reference points from past videos on the channel:

Then take it further by documenting your own hardened version: write a README, show the before-and-after Dockerfiles, and include the scan results.

Project 3: Self-Host a Password Manager

Everyone understands passwords and why password managers matter. What most people skip is the security model underneath it.

You can run this locally in your homelab or host it in the cloud with something like Vaultwarden or Passbolt. The value isn’t in getting it running; it’s in thinking through the threat model: Is it exposed to the internet? Is it behind a VPN? Are backups handled safely? Are you monitoring authentication attempts? Are you actually applying updates?

That’s the difference between “I installed a password manager” and “I deployed a security-critical service, locked down access, configured backups, and monitored it.” One of those is a resume line. The other is a project.

The same reference video applies here:

And it stacks well with the other projects on this list: put it behind Tailscale, monitor it with Wazuh, write detection rules for failed logins.

Project 4: Learn Kubernetes the Hard Way (or Break It With Kubernetes Goat)

Kubernetes is intimidating the first time you look at it: containers, networking, certificates, YAML, RBAC, service accounts, ingress, all stacked together. That’s exactly why it’s worth learning properly.

Two paths here. Kubernetes the Hard Way has you manually build a cluster and actually understand the certificates, control plane components, and networking that a managed service normally hides from you:

Kubernetes Goat is the security-focused path: it covers vulnerable scenarios such as misconfigurations, privilege escalation, secret exposure, and container escapes.

If your goal is to understand infrastructure, do the Hard Way. If your goal is Kubernetes security specifically, do Goat. If you’re serious, do both: understand how it works first, then attack and defend an insecure version of it.

Project 5: Build a Cybersecurity Homelab or Mini SOC

This is probably the project most aligned with this channel, because if you’ve been around a while, you already know I love homelabs. And a homelab does not need to be expensive. You don’t need a rack, you don’t need enterprise gear, you don’t need ten servers humming in a closet. An old laptop, a mini PC, a Raspberry Pi, or even VirtualBox on your current machine is enough.

A simple version looks like: a hypervisor like Proxmox, a Windows endpoint, a Linux endpoint, a Wazuh manager and a few agents, a vulnerable machine, and some log sources. Then you start generating real questions: Can I see failed logins? Can I detect suspicious PowerShell? Can I collect logs from Linux and Windows and write a custom detection rule?

Installing Wazuh, Security Onion, or Splunk is not the project. The project is what you do after it’s installed: generating telemetry, tuning false positives, building dashboards, and documenting the incidents you investigate.

I’ve documented my own homelab journey across my Homelab and Detection playlist and Home SOC projects, including the Proxmox build itself:

How I’d Actually Approach These Five

If you’re new to the field, start with the Network Traffic Analysis Lab and either the Homelab or the SOC project. Those give you the strongest fundamentals.

If cloud security, DevSecOps, or AppSec is the goal, start with containerizing an app and self-hosting a password manager.

If you want to push into more advanced infrastructure, do Kubernetes the Hard Way or Kubernetes Goat.

But honestly, the real magic is connecting them. Build a homelab. Run a password manager inside it. Containerize a basic app. Monitor everything with Wazuh. Capture the traffic. Deploy Kubernetes Goat. Generate attacks. Write detections. Document the whole thing.

That’s the difference between someone who says “I’m interested in cybersecurity” and someone who can say “here is what I built, here is what I broke, here is what I secured, and here is what I learned.”

What I’m Taking Away From This

Consumption isn’t the bottleneck anymore; application is. Between YouTube, certifications, and endless write-ups, information has never been easier to find. The people who stand out are the ones who actually built something with it.

Documentation is the project. Building the lab and never writing it down is basically the same as not building it. A README, a set of screenshots, and an honest account of what broke turns a weekend project into a portfolio piece.

Connected projects beat isolated ones. A password manager behind Tailscale, monitored by Wazuh, inside a homelab you built yourself, tells a far stronger story than five disconnected weekend experiments.

Your Challenge

Pick one of these five projects and actually build it. Not save it, not bookmark it, not add it to a Notion board. Build it, then document it: take the screenshots, write down the commands, explain what went wrong and what you fixed.

That documentation is what turns into a GitHub project, a blog post, a LinkedIn post, or your next interview talking point.

I genuinely want to know: which one of these five are you building this summer? Network Traffic Analysis Lab, Securely Containerizing an App, Self-Hosting a Password Manager, Kubernetes the Hard Way or Goat, or your own Homelab/SOC? Reply and let me know; I want to see what y’all are building.

Interested in sponsoring Cyberwox?

Sponsoring Cyberwox helps me continue creating practical cybersecurity education, labs, and industry analysis while connecting your brand with a trusted multi-platform audience of 120,000+ cybersecurity practitioners, engineers, students, founders, and technology leaders across the global cyber community on our YouTube, LinkedIn, X, & Substack 🌎

Learn More Here 🚀

Until Next Time

That’s it for this one.

As always, keep learning, keep building, and keep thinking deeply about the systems we’re trusted to defend.

See you in the next one.

~ Day 💙

My primary homelab server lab0 was still running Proxmox VE 8.4 on Debian 12 Bookworm. Since Proxmox VE 9 had been out for a while and moves the underlying distribution to Debian 13 Trixie, I decided it was time to make the jump.

This is the same host running much of the infrastructure from my homelab series, including my Wazuh VM.

So before changing anything, I started where every major upgrade should start:

pve8to9 --full

The initial report was better than expected: 43 checks total, 29 passing, three warnings, and one failure.

The failure was the one that mattered most:

FAIL: systemd-boot meta-package installed.

There were a few other cleanup items too:

• AMD CPU microcode was missing.

• Legacy settings remained in /etc/sysctl.conf.

• LVM volumes were using the old autoactivation behavior.

• Wazuh’s third-party repository appeared as an unusual APT suite.

• One VM was still running.

None of that was catastrophic. But this is precisely why pre-upgrade checks exist: they turn hidden technical debt into an actionable checklist.

Full unedited upgrade process (with the help of ChatGPT).

Confirming the Boot Path

The first thing I wanted to understand was the bootloader warning.

Having the systemd-boot package installed does not necessarily mean the host actually boots using systemd-boot, so I checked the relevant state:

proxmox-boot-tool status
efibootmgr -v
dpkg -l | grep -E 'systemd-boot|grub|proxmox-boot'

The key detail was this EFI entry:

Boot0004* proxmox ... \EFI\proxmox\shimx64.efi

The host also had the full GRUB stack installed. In other words, it was booting through Proxmox’s GRUB/shim path—not systemd-boot. The package was simply an unnecessary meta-package left behind on the system.

I removed it, reran the checker, and the failure disappeared.

That took the host from one failure to zero.

Cleaning Up Before the Upgrade

Next, I worked through the remaining warnings.

Updating LVM autoactivation

Proxmox 9 changes how newly created LVM and LVM-thin guest volumes use autoactivation. One of my existing VM disks still had the older behavior enabled.

Proxmox provides a migration script for this:

/usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation

It found the affected volume and corrected it.

One important lesson: I had to run this script a second time later in the upgrade

Read more

So before I left, I made sure Tailscale was already installed and running across the homelab: the Proxmox host, my laptops, all of it.

That one decision ended up being the whole point of this issue. Because once I was actually in D.C., sitting on hotel WiFi with zero trust in that network, I got to see firsthand just how powerful that setup really is.

So this issue is about showing that off: how I access my entire cybersecurity homelab from anywhere, without exposing Proxmox, SSH, or remote desktop services directly to the internet, and why setting it up before you need it is the move.

The two tools doing all the heavy lifting: Tailscale and RustDesk.

Watch the full walkthrough here:

Why I Set This Up Before I Ever Needed It

Here’s the thing about homelabs: the second you want to reach them from outside your own network, you’re one bad decision away from turning a learning environment into a real liability.

Port forward SSH to the router and you’ve got a service sitting on the open internet getting hammered by scanners or unrelentless AI agents within hours. Expose the Proxmox web UI the same way, and you’ve basically hung a sign that says “management plane, please attack me.”

I never even considered either of those routes. I wanted something that felt like I was still on my home network, no matter where I actually was, and I wanted it working well before I needed it under pressure.

That’s the whole premise of Tailscale: a mesh VPN built on WireGuard that quietly stitches all your devices into one private network (a “tailnet”), with no ports opened on your router at all.

How Tailscale Connects My Homelab Devices

The setup is almost anticlimactic in how simple it is. Install the Tailscale client on a device, authenticate, and it joins the tailnet. That’s it. No firewall rules, no static IP requirements, nothing crazy.

I’ve got it running across the homelab: the Proxmox host, individual VMs, my laptops, even devices that aren’t normally reachable from outside the house.

Once everything’s on the same tailnet, they can all talk to each other using stable, private IP addresses (or MagicDNS names, if you want something more human-readable). It doesn’t matter if I’m on hotel WiFi in D.C. or on my phone’s hotspot. As far as the network is concerned, I’m home.

Configuring and Using Exit Nodes

This is where it goes from “nice remote access” to genuinely useful: exit nodes.

An exit node lets you route your device’s entire internet traffic through another machine on your tailnet, in my case, a node sitting at home. Flip it on, and suddenly all my traffic looks like it’s coming from my home network, encrypted the whole way there.

Practically, that means I can be anywhere, connect through my home exit node, and get the same network posture I’d have sitting on my couch. For a security engineer who’s paranoid about hotel and conference WiFi (rightfully so), that’s a real upgrade over hoping a commercial VPN is trustworthy.

Remotely Accessing Machines With RustDesk and Tailscale

SSH gets you a terminal. Sometimes you need a screen or GUI.

That’s where RustDesk comes in, an open source remote desktop tool that I’m running entirely over the Tailscale network rather than exposing it to the open internet. Since RustDesk traffic rides on top of Tailscale’s already encrypted mesh, I get full remote desktop access to my homelab machines without opening a single port.

This combo (Tailscale for the private network, RustDesk for the actual screen access) means I can pull up a full desktop session on any lab machine from basically anywhere, and the attack surface stays exactly where I want it: nowhere on the public internet.

Using Tailscale SSH Across My Tailnet

Once devices are on the tailnet, Tailscale can also handle SSH directly, no separate key management, no exposed port 22, no fumbling with .ssh/config across a dozen machines.

Access control lives in Tailscale’s ACLs instead of a patchwork of firewall rules. Want to restrict which devices can SSH into which lab machines? That’s simple a policy.

For a homelab where I’m constantly spinning things up and tearing them down, this alone saves a meaningful amount of friction.

Secure File Sharing With Taildrop

Small feature, genuinely useful: Taildrop.

It lets me send files directly between devices on the tailnet, no cloud upload, no USB drive, no janky SCP command with a path I always mistype. Need to grab a config file off my macbook host onto my Proxmox while I’m out? Taildrop handles it, encrypted, peer-to-peer, done.

It’s not the headline feature, but it’s the kind of quality-of-life addition that makes the whole setup feel less like a workaround and more like an actual system.

Security Considerations for Remote Homelab Access

I’d be doing you a disservice if I didn’t call out the tradeoffs, because there always are some.

Tailscale and RustDesk dramatically shrink my attack surface compared to port forwarding, but they don’t eliminate risk. A few things I’m keeping in mind:

• Identity is the new perimeter. Tailscale ties device access to your identity provider. If that account gets compromised, the blast radius is your entire tailnet. Multi-factor authentication on that identity provider isn’t optional.

• ACLs need actual attention, not defaults. It’s tempting to let every device talk to every other device once it’s all “private” anyway. Don’t. Scope access the same way you would on any internal network. I’ll make a future issue on that.

• RustDesk still needs auditing. Remote desktop access is powerful, which means it’s also exactly the kind of access an attacker wants if something upstream goes wrong. I’m treating it the same way I’d treat any privileged access path in production: logged, reviewed, with MFA and not left on indefinitely.

None of this is a reason to avoid the setup. It’s a reason to run it the way I’d want anyone on my team running similar access in a real environment.

What I’m Taking Away From This

Setting it up before you need it is clutch. The whole reason this trip went smoothly is that Tailscale was already running when I needed it. If I’d waited until I was in a hotel room trying to configure a VPN for the first time, this story would read very differently.

Convenience and exposure aren’t the same tradeoff you think they are. I assumed secure remote access meant sacrificing convenience. Tailscale proved that wrong. The private mesh is often more convenient than the “exposed” version ever was.

Identity-based access beats network-based access almost every time now. Instead of asking “what can reach this port,” I’m asking “who is this device, and should it be allowed to talk to that other device?” That mental shift matters more than any specific tool.

The best security fix is usually the one that removes the exposure entirely, not the one that adds another layer on top of it. Zero open ports beats a hardened open port every time.

What’s Next

Now that I’ve seen how well this held up under real-world conditions, I want to push further into how I segment the tailnet itself: tighter ACLs between the Wazuh manager, the endpoints reporting to it, and everything else in the house.

If something in this house misbehaves while I’m three states away, I want to still catch it. If it breaks, I want to know why, from wherever I happen to be.

The homelab keeps getting more capable. Let’s see where it goes next.

Interested in sponsoring Cyberwox?

Sponsoring Cyberwox helps me continue creating practical cybersecurity education, labs, and industry analysis while connecting your brand with a trusted multi-platform audience of 120,000+ cybersecurity practitioners, engineers, students, founders, and technology leaders across the global cyber community on our YouTube, LinkedIn, X, & Substack 🌎

Learn More Here 🚀

Until Next Time

That’s it for this one.

As always, keep learning, keep building, and keep thinking deeply about the systems we’re trusted to defend.

See you in the next one.

~ Day 💙

That’s insane to say out loud. It’s July 2026 now.

Life’s been a whirlwind though, a good one. I got married. We went on our honeymoon. And somewhere in the middle of planning a wedding for six straight months, the homelab just… sat there. Dormant. Collecting dust.

But here’s the thing: now more than ever, this project matters. Because my wife and I living together has literally expanded our threat surface. New devices, new habits, new attack surface under one roof.

So this is a two-in-one issue, part homelab, part home security. Time to get this thing back on track.

The mission: deploy the Wazuh agent across four endpoints (three macOS machines and one Windows box) and make sure I have visibility into every single asset in this house.

Endpoint 1: The Command Center

First up is an old MacBook (M1, Apple Silicon) that used to be my daily driver, before it got demoted to “random stuff” duty once I upgraded. Still functional, still useful, so I gave it a new job: command center for the homelab.

Everything still runs off the makeshift PC server, where Proxmox lives. But this MacBook is where I access the Wazuh dashboard and manage the whole operation.

Following the Wazuh macOS install docs, the process is refreshingly simple:

• Log into the dashboard, click Deploy a new agent

• Confirm the architecture (Apple Silicon vs. Intel)

• Point it at the manager IP; mine’s sitting on 192.168.1.133

• Name the agent (I went with cwx-mac-cmd-ctr)

• Copy, paste, run

A few minutes later: agent active. To confirm it was actually working, I ran sudo -i to trigger a privileged session, and sure enough, Wazuh flagged it immediately: “First time user executed sudo.”

That’s the whole point of a homelab, honestly. You don’t just install something and trust it works. You poke it until it proves itself.

Endpoint 2: The Daily Driver

Next up was my actual daily driver, an M4 MacBook, also silicon, also where all my content and work actually happens. Same install flow, new agent name: cwx-mac-daily-driver

Ran the same sudo -i test. This time, four events came through: agent connected, agent stopped, agent started, first-time sudo. Clean.

Two active agents down. Two to go.

Endpoint 3: My Wife’s MacBook (Yes, “Big Bertha”)

This one came with a small hiccup, a connection refused error that turned out to be a missing https:// in the manager address. Classic. Once fixed, the install went smoothly on her M1 MacBook, which (for reasons I will not fully explain in a newsletter) was almost affectionately named Big Bertha.

Same sudo test, same confirmation. Three agents active.

Endpoint 4: The Proxmox Node

This is the one that actually matters most, the bare-metal node running every virtual machine in the lab. Confirmed it was a Debian-based AMD64 system with uname -m, grabbed the Linux install command, and named it cwx-proxmox-lab0, after the lab itself.

Then it broke.

“The job for the wazuh-agent service failed because the control process exited with error code.”
“Invalid server address found for manager IP.”

Classic homelab moment. Turns out I had previously installed the Wazuh manager on this exact node (back when this box briefly played SIEM server), and the config was still pointing at itself instead of the actual manager IP. A quick edit to swap the manager IP field to 192.168.1.133, a service reload, and it connected.

This is the part of homelabbing that never changes, no matter how many years in: trial and error is still the name of the game. Every fix teaches you something about how the system actually behaves under the hood, not just how the docs say it should.

Endpoint 5 (Sort Of): The Windows Box

Last endpoint: a Windows machine I picked up a couple years ago while (half-heartedly) studying for the SANS GCIH cert I never actually took. It’s been sitting around for VMware experiments and “special projects” ever since. Time to put it to work.

Here’s where I have to be honest with you: I goofed. OBS wasn’t configured to capture the screen properly, so the actual Windows install didn’t record. But the process is genuinely this simple:

• Copy the install command from the Wazuh dashboard

• Run it as admin in PowerShell

• Start the service

And then, don’t skip this, install Sysmon. Raw agent telemetry is good, but Sysmon is what turns “I have an agent” into “I actually have visibility.” I recommend Olaf Hartong’s Sysmon-modular config, probably the most useful config out there, or SwiftOnSecurity’s Sysmon config as a solid alternative.

What I’m Taking Away From This

A few things stuck with me rewatching this lab session:

Visibility isn’t a one-time project; it’s a maintenance habit. Nine months of dormancy meant nine months of blind spots. The moment life changes (new house, new person, new devices), your monitoring needs to catch up.

The “boring” fixes are usually config, not code. Every issue in this session (a missing https://, a stale manager IP left over from an old install) was a five-second fix once I actually read the error message instead of assuming the worst.

Test every agent the same way you’d expect a real event to fire. sudo -i isn’t glamorous, but it’s a fast, repeatable way to confirm an agent is actually alive and alerting, not just “installed.”

What’s Next?

The homelab’s back. Let’s see where it goes.

Watch the full episode:

Interested in sponsoring Cyberwox?

Sponsoring Cyberwox helps me continue creating practical cybersecurity education, labs, and industry analysis while connecting your brand with a trusted multi-platform audience of 120,000+ cybersecurity practitioners, engineers, students, founders, and technology leaders across the global cyber community on our YouTube, LinkedIn, X, Substack, and Discord 🌎

Learn More Here 🚀

Until Next Time

That’s it for this one.

As always, keep learning, keep building, and keep thinking deeply about the systems we’re trusted to defend.

See you in the next one.

~ Day 💙

I have now quickly surpassed 61,000, and until recently, I had not answered a single one. So I finally sat down, opened my laptop, pulled up the questions, and started working through them.

What came out of that process did not feel like a Q&A. It felt more like a mirror.

The questions forced me to look at the person I was when I got into cybersecurity at 18, the person I have become over the last six years, and the person I am still trying to become now. They made me think about ambition, comparison, faith, artificial intelligence, content creation, and the kind of life I am building around all of it.

But one question sat underneath almost every answer:

What do you do when the same qualities that gave you an edge also begin to cost you something?

The Balance I Still Haven’t Found

The first question was simple:

Do you enjoy your work-life balance?

No? Honestly, I don’t know.

To be more accurate, I am still figuring out whether I have one.

I started my career at 18. Cybersecurity has occupied almost my entire adult life. In the beginning, I was obsessed. I pulled all-nighters. I studied constantly. I learned everything I could get my hands on.

At the time, I did not really think about work-life balance because there was not much of a life outside of work to balance it against.

That obsession accelerated my career.

It also meant I went four or five years without taking a real vacation.

For a long time, I saw that intensity as an advantage. In many ways, it was. It helped me build skills quickly. It opened doors. It gave me the confidence to enter rooms I probably would not have entered otherwise.

But the things that give you an edge early in your career can become harder to carry as your life expands.

I just got married. I am entering a new season. My time is no longer mine alone.

My wife tells me I am a workaholic, and she is right.

Read more

Every few years, cybersecurity gets a new “end of the world” moment. Sometimes it is cloud. Sometimes it is ransomware. Sometimes it is generative AI. Now, with Claude Mythos and Project Glasswing, the conversation has shifted again.

On April 7, 2026, Anthropic announced Project Glasswing, an initiative built around a frontier model called Claude Mythos Preview. The basic idea was simple: Anthropic had developed a model with cyber capabilities strong enough that they did not want to make it generally available to the public right away. Instead, they gave select organizations early access so they could identify and fix serious vulnerabilities in critical systems before similar capabilities became more widely available.

According to Anthropic, Mythos demonstrated the ability to find high-severity vulnerabilities, including long-standing issues in systems such as OpenBSD and FFmpeg, and to chain multiple vulnerabilities in complex software. The reason this matters is not just that the model can find bugs. Security researchers have been finding bugs for decades. What matters is that AI appears to be compressing the time between vulnerability discovery, exploit development, and operational use.

That is the actual problem.

Not that cybersecurity is over. Not that defenders are useless. Not that AI is some magical offensive weapon that immediately invalidates everything we know. The real issue is that AI continues to make certain parts of cyber operations faster, cheaper, and more scalable. And in cybersecurity, speed has always mattered.

True To This, Not New To This

We have seen this pattern before.

The cloud era taught us this lesson clearly. Cloud-based infrastructure gave us faster deployment, easier scaling, and more flexible operation. But that same speed also created new failure modes. Misconfigured storage buckets, overly permissive IAM roles, public-facing admin panels, exposed keys, open security groups, and flat cloud environments all became part of the modern attack surface.

The Capital One breach became one of the clearest examples of this reality. Cloud was not the problem by itself. The problem was that the speed of cloud adoption outpaced the maturity of cloud security practices. A single misconfiguration, combined with an exploitable path through the environment, led to consequences on a massive scale.

That same pattern is now playing out with AI.

Early chatbots were quickly met with prompt injection. Systems designed to follow user instructions were manipulated by users who understood that the instructions themselves had become part of the attack surface. As AI systems became more connected to tools, browsers, files, APIs, and enterprise data, the problem became bigger than getting a chatbot to say something weird. The concern became what happens when an AI system can act.

That is why exposed AI systems matter. If we have learned anything from cloud security, it is that organizations will expose things they do not fully understand. They will deploy fast. They will leave defaults in place. They will connect powerful systems to sensitive resources before security architecture catches up. The names change, but the foundational issue is familiar.

This is not new.

It is the same security debt showing up in a new format.

The Real Problem Is Exploitability

Cloudflare’s Project Glasswing update displays this flawlessly.

Vulnerabilities do not exist in a vacuum. A bug becomes dangerous because surrounding conditions make it exploitable. That is why attack paths matter. An attacker does not just need a vulnerability. They need reachability, permissions, context, credentials, exposure, and a way to turn technical weakness into operational impact.

This is where models like Claude Mythos become interesting. The concern is not only that AI can identify a vulnerable code path. The concern is that AI can reason across multiple small primitives and assemble them into something meaningful. That starts to look less like automated scanning and more like the workflow of a capable vulnerability researcher.

That is a shift defenders should take seriously.

If AI can reduce the time required to discover, validate, and chain vulnerabilities, then defenders have less time to respond. Patch cycles become more compressed. Exposure windows become more costly. Asset inventory becomes more important. Vulnerability management becomes less about knowing that something is vulnerable and more about understanding which weaknesses can actually be reached, chained, and exploited in your environment.

This is why the conversation cannot stop at AI capabilities. The real conversation is about defensive readiness.

Cybersecurity First Principles Still Matter

When a technology feels new, the industry has a habit of pretending the fundamentals have changed. Most of the time, they have not. AI introduces new capabilities, new attack surfaces, and new operating models, but it does not remove the need for strong security foundations.

Cybersecurity first principles still matter because they give us a way to reason about new systems without being distracted by novelty.

1. Domain separation becomes critical when AI agents can interact with tools, data, users, and infrastructure. If an agent is compromised or manipulated, strong boundaries should prevent that compromise from spreading across the environment. An AI agent should not be able to move freely between sensitive domains simply because it was given access to a browser, a shell, an API, or an internal knowledge base.

2. Process isolation matters for the same reason. AI-enabled workflows should not be treated as trusted monoliths. Models, tools, plugins, execution environments, and downstream systems should be isolated from one another as much as possible. If one component behaves unexpectedly, the rest of the system should not automatically inherit that failure.

3. Resource encapsulation is also essential. AI systems should interact with resources through controlled interfaces, not through broad and undefined access. If an agent needs to query a database, call an API, or retrieve a document, that interaction should be mediated, logged, scoped, and governed. The agent should not receive unrestricted access just because the user has it.

4. Least privilege might be one of the most important AI security principles. An agent should not inherit full user authority by default. It should receive the minimum capability required for the task. That means scoped tokens, limited tool access, narrow execution rights, and explicit boundaries around what actions it can take without human approval.

5. Layering still matters because no single AI security control will be enough. Prompt injection defenses, model monitoring, tool permissioning, retrieval filtering, behavioral detection, human approval, and traditional security controls all need to work together. AI security will not be solved by one guardrail. It will require a defense-in-depth.

6. Abstraction helps defenders manage complexity. AI systems are quickly becoming chains of models, tools, prompts, memory stores, retrieval systems, APIs, and user interfaces. Without clean abstractions, defenders will struggle to understand where trust boundaries exist and where security decisions are actually being made.

7. Data hiding becomes more important as AI systems consume more context. Sensitive data should not be exposed to a model or agent simply because it exists somewhere in the environment. Data should be filtered, scoped, redacted, tokenized, or withheld when it is not necessary for the task. The more context we provide to autonomous systems, the more intentional we need to be about what they are allowed to see.

8. Modularity enables organizations to contain failures and improve systems over time. If every AI workflow is tightly coupled to every other part of the business, securing it becomes nearly impossible. Smaller, well-defined components are easier to test, monitor, replace, and restrict.

9. Simplicity and minimization may be the most underrated principles in AI security. The more tools an agent has, the more ways it can fail. The more permissions it holds, the greater the blast radius. The more context it receives, the more opportunities exist for leakage, manipulation, or misuse. Secure AI systems will not simply be the most capable systems. They will be the systems with the least unnecessary complexity.

This is the point I keep coming back to: AI does not replace cybersecurity fundamentals. It punishes organizations that fail to implement them.

Beyond Reactive Defense

First principles give us the foundation, but AI also forces us to think more seriously about the economics of defense.

For most of cybersecurity history, defenders have operated in a difficult asymmetry. Attackers can reuse infrastructure, tooling, research, and techniques across many targets. Defenders have to protect their specific environment, business logic, legacy systems, and operational constraints.

AI has the potential to make that asymmetry worse.

If autonomous agents can conduct reconnaissance, summarize targets, generate payloads, test exploitability, and adapt based on results, then adversaries may be able to scale certain parts of cyber operations with less human effort. Even if AI does not produce perfect attacks, it can still increase volume, speed, and persistence. That alone matters.

This is why I think cybersecurity has to evolve beyond purely reactive defense. By active defense, I do not mean reckless retaliation or unauthorized access to adversary infrastructure. I am not talking about hack back. I am talking about defensive actions taken inside authorized environments to detect, deceive, delay, degrade, and increase the cost of malicious activity.

That distinction matters.

The future of active defense in the AI era should not be about defenders becoming attackers. It should be about defenders designing environments that are harder for autonomous adversaries to reason through, move through, and exploit at scale.

Economic Friction

One way to think about this is in terms of economic friction.

Traditional economies of scale teach that as production increases, the cost per unit can decrease because fixed costs are spread across a larger volume. This is part of why AI is attractive to both businesses and adversaries. If an attacker believes AI can reduce the human effort required for reconnaissance, targeting, exploit development, or phishing, then AI becomes a way to pursue malicious scale.

Defenders should respond by targeting that assumption.

If AI-enabled attacks depend on tokens, tool calls, context windows, model reasoning, browser automation, API usage, and agentic workflows, then defenders can design controls that make malicious automation more expensive, less reliable, and less efficient.

This is not just about blocking attacks. It is about degrading the economics of the attack.

A defender may not always be able to prevent an autonomous agent from scanning an exposed surface, but they may be able to identify it, slow it down, feed it low-value paths, force unnecessary reasoning steps, trigger additional tool calls, or route it into monitored deception resources. In other words, the defender can impose cost.

That cost can take different forms. It can be the token cost. It can be time. It can be uncertain. It can be false confidence. It can be a wasted tool execution. It can be a forced human review on the attacker’s side. It can be telemetry that exposes the agent’s behavior before it reaches anything sensitive.

This is where deception becomes very interesting.

Deception Against Autonomous Agents

AI agents are not humans, but they still make decisions based on context. They read pages, interpret instructions, follow links, inspect artifacts, summarize data, invoke tools, and decide what to do next. That means the environment itself can influence their behavior.

We already understand this concept with humans. Honeypots, canary tokens, decoy credentials, and deception environments exist because attackers make decisions based on what they see. The AI version of this idea is that autonomous agents can also be lured, redirected, slowed, or fingerprinted through the information they consume.

This is where techniques like AI Agent Clickbaiting (AML.T0100) become relevant. If an agent can be manipulated through content, interface cues, instructions, or task framing, then defenders can create canary-style resources designed specifically for AI-operated reconnaissance. These could be fake exposed panels, synthetic documentation, monitored API endpoints, decoy credentials, prompt-injection canaries, or high-token dead ends that cause malicious agents to waste resources while generating useful telemetry for defenders.

The goal is not to create chaos. The goal is controlled defensive friction.

A malicious autonomous agent conducting reconnaissance should not experience the environment as clean, cheap, and easy to reason through. It should encounter boundaries, uncertainty, deceptive paths, scoped access, monitored resources, and expensive decision points.

This is especially relevant when we look at AI-orchestrated campaigns. In Anthropic’s report on the AI-orchestrated cyber espionage campaign they disrupted, the actor used Claude’s agentic capabilities across phases like reconnaissance, vulnerability discovery, credential harvesting, and data collection. That is the kind of activity defenders need to study closely. If AI agents are going to be used to automate parts of the intrusion lifecycle, then defenders need to understand how those agents perceive environments, how they make decisions, and where they can be safely disrupted.

Cybersecurity researchers at also recently released a publication on the concept of Context Bombs, a defensive technique designed specifically for autonomous AI attackers.

Tracebit Dispatches

Context bombs: Canaries that stop AI attackers

Frontier AI agents can seize full admin of a cloud account in minutes - a critical action within 14 minutes on average, leaving defenders barely an 8-minute window to respond. When attacks move that fast, detection alone isn’t enough…

Read more

3 months ago · 3 likes · Tracebit

The idea is simple but clever: plant carefully crafted text inside canary secrets, environment variables, or other artifacts that an AI agent is likely to read. Instead of simply detecting the attacker, the text is designed to trigger the model’s own safety guardrails, causing it to refuse to continue the attack.

That is the next layer of AI defense.

Not just protecting AI systems from attackers, but protecting our environments from attacker-controlled AI systems.

Final Thoughts

Claude Mythos does not prove that cybersecurity is ending. It proves that the timeline is shrinking.

The industry should take that seriously, but panic is not a strategy. Neither is pretending that every AI development requires a completely new security philosophy. Most of what we need still comes back to fundamentals: isolate systems, reduce unnecessary access, protect sensitive data, minimize attack surface, layer controls, and design systems whose failure modes are understood.

At the same time, AI does create a new defensive challenge. If adversaries use AI to scale cyber operations, then defenders have to think beyond detection and response. We have to think about cost. We have to think about friction. We have to think about how to make malicious automation less efficient.

That is the real shift.

AI does not replace cybersecurity fundamentals. It makes weak fundamentals more expensive. And for defenders, the opportunity is not just to use AI faster than attackers. It is to build environments where attacker-controlled AI systems are constrained, misled, slowed down, and forced to pay a higher price for every step they take.

Interested in sponsoring Cyberwox?

Sponsoring Cyberwox helps me continue creating practical cybersecurity education, labs, and industry analysis while connecting your brand with a trusted multi-platform audience of 120,000+ cybersecurity practitioners, engineers, students, founders, and technology leaders across the global cyber community on our YouTube, LinkedIn, X, Substack, and Discord 🌎

Learn More Here 🚀

Until Next Time

That’s it for this one.

As always, keep learning, keep building, and keep thinking deeply about the systems we’re trusted to defend.

See you in the next one.

~ Day 💙

“Humans are the weakest link.”

We’ve even made cybersecurity marketing and product playbooks just to fit this rhetoric.

It’s said with a mix of conviction, some frustration, and resignation, as if the problem begins and ends with the user who clicked the phishing email or reused their password.

But lately, I’ve been rethinking that phrase, because maybe the problem isn’t the people.

Maybe it’s the way we design for them.

Subscribe now

Join a vibrant cybersecurity community of over 7000 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like reading, fitness, finance, anime, and other exciting subjects.

Join Us!

A Flawed Premise

I’ve been reading (and have since paused) Don Norman’s The Design of Everyday Things. This is one of the most influential books on human-centered design.

Norman shares a story about investigating the Three Mile Island nuclear accident. The operators were blamed for “human error,” but as his committee later found, the real failure was design.

The control panels were so poorly laid out that it was inevitable that the wrong actions would be taken.

That story struck me hard because the same logic applies to cybersecurity. Hence, the reason why I’m writing this.

When we blame users for being “the weakest link,” what we’re really saying is:

We designed a system that expected humans to behave perfectly…and they didn’t.

What Human-Centered Design Teaches Us

Norman’s philosophy is simple yet radical:

Human-centered design starts from understanding humans.

It’s the belief that systems should be built around people, their capabilities, limitations, and behavior, not the other way around.

Now imagine applying that same principle to cybersecurity.

What if security were an enabler of trust, confidence, and resilience?

The Essence of Security

I’ve been obsessed with word etymology recently and decided to find out the etymology of the word “security”.

Per etymonline (as recommended by Gemini), the word "security" originates from the Latin sēcūritās, meaning freedom from care, apprehension, or danger, derived from sēcūrus ("safe" or "without care").

It combines se- (without) and cura (care/concern), emerging into Middle English as securite in the early 15th century to describe a state of safety.

So, what this means is that security, at its core, is supposed to mean freedom from care. Freedom from anxiety. A state where you’re not constantly thinking about what could go wrong.

But that’s not what most people experience.

What they experience is friction. They experience getting locked out of their own accounts. They experience clicking through prompts they don’t fully understand. They experience being told to “be more careful” in systems that never really help them be.

Somewhere along the way, security stopped feeling like safety and started feeling like responsibility. And we handed that responsibility to the user.

That’s the part I keep coming back to, but that’s a letter for another day.

What would it look like if we actually took that definition of security seriously?

Human-Centered Security

If security is supposed to feel like freedom from care, then what we build shouldn’t feel like something users have to constantly fight through. It should feel like something that quietly supports them.

That’s where I think human-centered security comes in.

Human-centered security, at least to me, isn’t about adding more shiny controls or features. It’s about rethinking security as an experience.

Reality shows that a well-designed system doesn’t rely on people memorizing policies or sitting through another awareness training session. It makes the right action obvious through its design. The experience aligns with what security is actually supposed to feel like: a sense of safety, not constant friction.

That distinction matters because if we over-index on the feeling of security without grounding it in reality, we end up with something worse than insecurity, a false sense of security.

And we know how dangerous that can be.

The better approach is simpler, but harder to execute. It’s the same principle you see everywhere else in good design, where you don’t need a manual to use a well-designed door. You don’t need a checklist to move through a clean interface. The design communicates intent. It guides behavior and meets you where you are.

Security should be doing the same thing.

Which means the questions start to change.

Not “how do we make users comply,” but how do users naturally understand what’s secure? How do we communicate risk in a way that actually lands, without overwhelming them? How do we make the secure choice the path of least resistance instead of the most difficult one? And how do we make security feel like an enabler instead of something that’s constantly in the way?

These questions are important because the reality is, people are going to make mistakes. That’s not a flaw in the system. That is the system.

Good design anticipates that. It doesn’t pretend it won’t happen. It builds around it.

In a security context, that means assuming an error will occur and designing for it anyway. It means putting guardrails in place that prevent small mistakes from turning into major incidents. It means creating feedback loops that actually teach and guide rather than punish people after the fact.

Once you start thinking about it this way, the “weakest link” framing starts to fall apart.

We start to undo this quiet assumption that’s shaped security for years. This bad assumption that the relationship between humans and security has to be adversarial, or that the user is the problem to be controlled.

It doesn’t have to be that way.

When you design with people in mind, the relationship shifts and becomes collaborative. The system supports the human, and in turn, the human strengthens the system.

The Real Weak Link

Every incident I’ve ever investigated has reinforced a humbling truth:

The system always works exactly as designed; it was just used for a different purpose or via a different mechanism than intended.

This is the part we tend to move past too quickly because, when you really sit with it, much of what we label “human failure” doesn’t actually start with the human. It starts with the environment we placed them in.

If a developer can’t realistically follow an IAM policy because it’s too complex to reason about in the flow of their work, that’s not a training gap. If a phishing simulation leaves employees feeling embarrassed instead of better equipped the next time around, that’s not awareness. If a password rotation policy leads to credentials being written down and hidden under keyboards, that’s not defiance.

Those are signals.

Signals that the system, as designed, is asking people to operate in ways that don’t align with how they actually think, work, and make decisions.

And this is where I think security always loses the plot.

We’ve spent years optimizing for technical correctness, tighter controls, more coverage, and logical completeness. But in doing so, we’ve overlooked something, the fundamental fact that humans don’t operate on logic alone.

They operate on trust, intuition, emotion, and habit.

And when those realities collide with systems that weren’t designed with them in mind, something has to give.

Most of the time, it’s the human who gets blamed.

But if we’re being honest, the system did exactly what it was built to do.

And until security starts accounting for that, we’ll keep building mechanisms that look strong on paper but end up working against the very people they’re supposed to protect.

AI, for humanity?

I believe this is where AI starts to become interesting and useful in a very different way. Not just as a tool for detection or automation, but as a bridge between systems and people.

For the first time, we have systems that can adapt more closely to how humans think, rather than forcing humans to adapt to rigid machine logic.

And if that’s the direction things are moving, then the role of the security professional has to evolve with it.

It’s no longer enough to just understand systems. You have to understand people, their thought processes, how they make decisions, and how trust is formed and broken. The Social Engineering Community already has a head start on this.

As AI continues to accelerate the technical side of security, more of the differentiation will come from understanding the human side. Psychology, behavior, communication, and all areas that security has historically treated as secondary will become core to how effective systems are designed.

Rethinking Security Through Human-Centered Design

Human-centered design doesn’t excuse mistakes or assign blame to humans; it approaches design with them in mind.

It utilizes iteration, observation, and empathy to design systems that adapt to human behavior, rather than requiring humans to adapt to systems.

So maybe the next evolution of cybersecurity isn’t just about AI-driven detections or zero-trust architectures.

Perhaps it’s also about human-centered security, which builds systems designed to work with people, not against them.

The real weakest link isn’t the human. It’s our failure to design for humans.

Share

It’s a strategic blueprint from someone who helped Netflix scale security without sl…

Read more

What kind of engineer am I?

Not just what tools you use. Not just what your current title says.

But how do you show up?

How do you solve problems?

How do you instinctively approach complexity?

I’ve seen this question (and its answer) surface over and over again in Slack threads during IRs, in 1:1s with mentees, in hallway conversations, in the quiet frustration of mid-career engineers trying to “level up” but not quite sure how.

And after half a decade in the field—from building threat detection pipelines at prominent startups to leading IR and threat detection at one of the largest tech companies on Earth—I’ve come to believe that most of us in security tend to move within a few core archetypes.

Not boxes. Not labels.

Gravity wells.

You may have blended skills, but there’s usually a center of mass—a force that pulls you toward a particular way of thinking, contributing, and growing. And once you can name that?

That’s when your career starts to gain direction.

Subscribe now

Join a vibrant cybersecurity community of over 7000 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like fitness, finance, anime, and other exciting subjects.

Join Us!

Watch the full video breakdown below:

Archetypes: A Language for How We Work

Across every security team I’ve been on, I’ve seen five archetypes show up again and again.

These are less about job titles and more about your operating posture.

How you move through problems, what you prioritize, and what kind of work gives you energy.

The Guardian

You’re the shield. The one who jumps on high-severity alerts before anyone else blinks.

You see logs like other people see spreadsheets in patterns, stories, and subtle shifts. Your radar is constantly scanning for badness.

You live in detection pipelines, SOAR playbooks, and IR processes.

You bring signal out of noise. And when things are chaotic, you’re the one who restores order.

Superpower: Translating alerts into action. Noise into signal. Chaos into clarity.

Growth Edge: Learning to zoom out. Don’t just be good at building detection rules or IR workflows. Learn to ask why this detection matters to the business in the first place.

The Architect

Read more

Most of the time, you don’t just buy an asset and walk away; you continue to pay to maintain it. Take an investment property, for example. You pay for staff, maintenance, utilities, and software to sustain operations.

Cybersecurity is no different.

Every new detection rule, workflow automation, or control we deploy carries its own operational expenditure. It requires continuous validation, clear documentation, and regular upkeep via updates or deprecations.

But more importantly, it consumes the scarcest resource in cybersecurity: skilled humans. There simply aren’t enough experienced security professionals to go around, and every new control competes for their limited time, focus, and expertise.

On the same note, building new things is great; as a matter of fact, I encourage all cybersecurity engineers to be builders. However, building is a capital expenditure (CapEx). It’s exciting, one-time, and easy to celebrate.

Maintaining what we build? That’s OpEx. It’s invisible, mundane, constant, but essential.

The more you build, the more likely you are to owe, especially if you cut corners. And like financial debt, it doesn’t disappear. It compounds. You’re borrowing time from your future self, and eventually, the bill comes due.

But enough doom and gloom. This issue isn’t meant for that. It simply expresses this sentient problem as it relates to cyber defense.

Subscribe now

Detection Engineering: Hidden Subscription Fees

Writing a detection rule feels like a win. Even better when it catches an actual threat. You get the dopamine hit of adding coverage, expanding visibility, and contributing to your SOC’s “rule count.”

But every detection you create is a new “subscription”. More specifically, a line item on your cybersecurity operational budget.

The starting cost is the time spent building the detection and testing for precision. Then comes the forever tax of cycles spent triaging inevitable false positives. Then there are hidden fees in the form of headspace needed to document, tune, and maintain as adversaries shift or your environment evolves.

Over time, these costs may accumulate into what I call detection debt. This is the backlog of unmaintained rules and unreviewed alerts that quietly bleed efficiency from your Cybersecurity Operations function.

And like real debt, it then accrues interest if you don’t pay it down quickly or reel in your “spending” habits: more noise, more fatigue, more missed signals.

A future issue of the newsletter will address the topic of detection deprecation which may help keep your budget on track.

Incident Response: Expensive Attention

Incident Response operates under high pressure, where time is capital in a very valuable currency.

And just as a company’s burn rate determines its financial health, your alert volume and false positive rate determine your cognitive health, especially for the engineers or analysts triaging or responding.

When everything triggers, nothing stands out. It’s just like the boy who cried wolf. When security alerts lose credibility through repetition, coupled with little detection accountability, the real threats get ignored.

Each noisy alert from your detection engineering “subscription fees”, misconfigured automation workflows, or irrelevant security escalation/investigation costs minutes, which compound into hours across the team.

Ultimately, the time (capital) spent, or otherwise wasted, in a security incident could be the difference between containment and compromise. This is where those hidden fees start charging interest and bleeding you even more of your most finite IR resource - time.

GRC: The Cost of Compliance Theater

Governance, Risk, and Compliance (GRC) resides in the fine print of cyber defense, which is precisely where operational costs accumulate quietly. Every new framework, audit requirement, or control mapping is like adding another recurring bill.

At first, it looks harmless. One more spreadsheet, one more evidence collection task.

However, over time, these small costs accumulate into process debt, resulting in endless reviews, repetitive documentation, and reactive reporting loops.

Essentially, the result of GRC becoming a checklist rather than a compass. OpEx skyrockets without improving actual security outcomes. Policies become artifacts. Audits become rituals.

You end up paying to maintain a compliance theater instead of actual cyber resilience. Everyone loves a good show, but it should not come at the expense of actual security.

Maturity

Just as financial maturity isn’t necessarily measured by how much you make but by how much you actually keep, Security maturity should not simply be measured solely by how much you deploy.

It should also measure how much you sustain without drowning in your own complexity.

And your cost model should account for both maintenance and development.

I don’t want to reduce operational cost to a mere financial metaphor; I’ll dare to say that it’s a mindset.

It forces you to ask:

• Can this <insert control here> survive without me?

• Can this <insert control here> be maintained six months from now?

• Can this <insert control here> adapt to changes in the environment?

If the answer is no, it’s not ready for production — it’s just another liability waiting to mature.

Every control is a contract. Every rule is a recurring bill.

The longer you operate without acknowledging this, the more expensive your security becomes.

💭 Closing Thought

What’s your team’s real operational cost? Audit your detections, playbooks, and controls to see what you’re still paying for in time, toil, and attention.

Share

Nine years.

Nine years of learning, grinding, building, and changing in ways I didn’t fully understand until I went back.

And somewhere between the chaos of Abuja’s traffic and the peace of being home again… I realized something.

Man…what an advantage. But also, what a paradox.

Subscribe now

The Advantage

There’s something special about being an immigrant, or really, anyone who’s ever had to start from zero.

You see two worlds. You understand scarcity and abundance.

You carry a perspective most people don’t even know exists. Your perspective gives you clarity.

Your clarity gives you resilience. Your resilience gives you staying power.

In a weird way, you learn to thrive with limited resources, and then when you finally get access to more, you move like someone who still remembers what it’s like to have none.

That’s your edge. That’s your advantage.

The Trap

But here’s the part you don’t notice:

That advantage fades fast.

When you finally get comfortable, the fire that once pushed you forward quietly goes out.

When the stakes aren’t as high anymore, urgency disappears. And slowly, you start coasting.

It’s the same thing that happens in cybersecurity careers.

You get the job, you learn the tech stack, you detect the threats, you respond to the incidents, you automate the redundant security work.

You make the multiple six figures salary.

And somewhere in between performance reviews, raises, and promotions, you lose that early hunger. The hunger that made you stay up late tinkering in your home lab, studying packet captures for fun, or learning that new programming language.

You stop chasing mastery and start chasing stability.

Now, don’t get me wrong, stability is good.

It’s okay to find peace in your work, to want consistency, to finally breathe after years of grinding.

But stability shouldn’t become complacency.

You can be content without being stagnant. You can rest without losing your edge.

Lesson Learned

The immigrant advantage, just like your early-career edge, isn’t something you get once and keep forever.

It’s something you have to protect, and you protect it by staying curious.

By building things even when no one’s asking.

By mentoring others and realizing how much you still have to learn.

By pushing yourself into discomfort because comfort is where edges go to die.

If you ever want to know where your career is headed, don’t look at your title or your pay. Look at your edge.

Is it sharper than it was a year ago?

Or has comfort slowly dulled it?

Join a vibrant cybersecurity community of over 6,900 people who are constantly engaging in conversations and supporting one another, covering topics from cybersecurity and college to certifications, resume assistance, and various non-professional interests like reading, fitness, finance, anime, and other exciting subjects.

Join Us!

Five Years In

This year marks my fifth year in cybersecurity.

From breaking into the field with nothing but curiosity and persistence, to hunting for threats at Amazon’s scale and helping others start their own journey, the lesson that keeps repeating is simple:

Never lose the edge that got you here.

Five years in, I’ve learned that skill can be taught, titles can change, and opportunities can evolve…but that hunger, that fire that made you chase growth in the first place, that’s what keeps you alive in this field.

The real advantage for me isn’t just being an immigrant.

It’s not being early in my career.

It’s staying hungry long after I no longer need to be.

That’s how you build longevity in cybersecurity — and in life.

Share

HashiConf 2025 marked a turning point for how we think about automation, visibility, and security in the AI age. The announcements appear to be puzzle pieces forming a bigger vision of what HashiCorp plans for the future of infrastructure, which involves systems that understand context before they act.

From Project Infragraph to the rise of MCP-powered AI operations, every keynote, demo, and hallway conversation hinted at the same shift: the future of DevOps and cloud security is about orchestration backed by context.

This issue of Cyberwox Unplugged explores that future.

I already outlined the major releases and announcements in my vlog, so this newsletter will focus on practical insights from the field and discussions with key figures shaping the next phase, including HashiCorp’s leadership and practitioners working at a large scale.

Subscribe now

Watch the full HashiConf 2025 vlog on the CYBERWOX YouTube channel for clips from these interviews and behind-the-scenes moments from San Francisco.

Standout Announcements

• Project Infragraph offers a real-time, unified graph for managing multi-cloud and hybrid states. This feature is in private beta, expected in December 2025. Think of it as live topology and relationships that agentic systems can analyze. 

• MCP servers (Model Context Protocol) for Terraform, Vault, and HCP Vault Radar are now in public beta. They enable AI tools to securely initiate runs, read state, and execute common operations from an IDE or client. This serves as the link between current platforms and future agents. 

• Terraform gains more pragmatic power with Stacks GA, Actions for “Day 2” ops, and Terraform Search (long-requested) to discover unmanaged resources and bring them under IaC. Fewer click-ops, less drift.

• Packer now offers SBOM storage (GA) and package visibility (beta) to mark images with provenance and software bills of materials, providing supply-chain transparency from the initial boot. 

• Vault & Radar updates enable secrets protection directly within your code editor, offering features like pre-commit detection, IDE workflows, and Jira SaaS scanning to ensure secrets are fixed before reaching the repository. 

And so much more you can dive into below:

Expert Insights

Armon Dadgar on Simplifying Cloud Complexity

When I asked Armon Dadgar, Co-founder and CTO of HashiCorp, how he envisions helping organizations stay secure and operationally resilient as AI and multi-cloud adoption expand, his answer centered on three core themes:

• standardization

• managed delivery, and

• AI-augmented visibility

“When we talk about our hybrid cloud operating model, it’s about how do you get to a standardized platform approach… Most enterprises are highly fragmented—they have a hundred app teams doing it a hundred different ways, and that’s an unmanageable level of complexity. You’re never going to get good at that, or be able to secure that.”

For Armon, security at scale begins with a unified platform strategy for provisioning, secrets management, and key management. Fragmentation, he noted, is the real enemy of operational maturity. The more unique patterns that emerge across teams, the harder it becomes to secure and automate them.

He went on to highlight a second primary focus: the HashiCorp Cloud Platform and the company’s broader managed services push.

“A lot of organizations lack the skills to actually deliver this stuff. So our big focus is: how do we run it as a managed service? We’ll handle integrations, backups, upgrades—all the stuff most teams struggle with.”

This reflects a long-term shift for HashiCorp from just being a tool provider to becoming a platform operator that helps enterprises consume secure infrastructure as a service, rather than a burden.

But Armon’s third point revealed where HashiCorp’s roadmap is truly heading: visibility and context through Project Infragraph.

“When I look at most outages or security issues, it’s not one system in isolation—it’s a chain of dependencies. The only way you solve that complexity is by visualizing it and seeing it.”

Infragraph, he explained, will help organizations map and understand relationships across their infrastructure, making cause-and-effect more visible across teams, clouds, and environments.

And once visibility is established, AI can play a significant operational role.

“Once you can visualize and see those relationships, that’s when AI augmentation starts making sense. You add MCP interfaces to something like Infragraph, and it starts unlocking day-two automation—the stuff we can’t really do today because the systems have no context.”

That last line says it all.

It doesn’t seem like HashiCorp is just chasing AI for the sake of hype. They seem to be building a contextual foundation that AI needs to operate responsibly in production systems, where visibility (from the context) is a fundamental requirement for AI autonomy.

Armon summed up the company’s mission clearly:

“Drive standardization, get to simplicity through a platform strategy, create consistent visibility, and ultimately help drive AI day-two operations.”

Will Bengtson on Platform Security and the Future of Infragraph

In our conversation, Will Bengtson, VP of Platform and Security Engineering at HashiCorp, gave a practical look into how HashiCorp runs its own products internally, as well as what excites him most about the company’s latest announcements.

“I own our cloud platform, HCP, and security… probably the most used tool for my teams is Terraform. Infrastructure as code lets us launch new features and deploy Infragraph with security baked in from the start.”

He also highlighted the critical role of Vault in their CI/CD processes and how it ties directly into HCP (HashiCorp Cloud Platform) — bringing secret management and compliance checks closer to the build pipeline. But when asked about his personal favorite tool, he didn’t hesitate:

“The one I love the most is Packer. Immutable infrastructure. Instead of patching, we just rebuild and redeploy. You can move infrastructure really fast.”

The mindset of rebuilding an image reflects a security engineer’s instinct to prefer known-good baselines over accumulated risk. It’s also the type of thinking that makes HashiCorp’s internal engineering culture mirror the ideals it advocates to its customers.

When we got into new announcements from HashiConf, Will pointed straight to Project Infragraph:

“The one I’m hearing the most buzz about is Infragraph. From a security perspective, asset management… from an ops perspective, being able to dig into a vulnerability, figure out where it lives in HCP or Packer, and trace it back into Terraform—that’s powerful.”

Seeing Infragraph’s first live demo alongside the rest of the audience, he noted that the natural language pre-built queries stood out the most:

“The pre-canned questions are super important—especially if you’ve never used it. You can filter and explore without needing to do everything manually. I thought the natural language hit hard.”

That’s the vision of Infragraph in action: making infrastructure and dependency visibility accessible not just to engineers but to anyone managing security and reliability at scale.

Before wrapping up, Will mentioned his next big “side project” — welcoming a new baby into the world. But even with that personal milestone ahead, his mind is already turning to what’s next for AI inside HashiCorp’s ecosystem:

“I’m really just trying to figure out where we’re going with AI next in our products. That’s going to be my new side project.”

All the best, Will!

Brian Chong on Scale, SBOMs, and the Next Layer of Infrastructure

Brian Chong, Director of Infrastructure and Security at Rubrik, brought a large-scale enterprise perspective to the table. His teams rely heavily on HashiCorp tooling—Terraform, Packer, and Vault—with an eye toward expanding into Nomad and Consul to extend automation beyond infrastructure and into service-level orchestration.

“Our three main tools are Terraform, Packer, and Vault. But we’re looking at Nomad and Consul as well.”

When asked which of the new announcements caught his attention, Brian didn’t hesitate:

“From my world, Terraform Actions. That’s going to help unify some of our toolsets and hopefully let me eliminate a few we already have. Optimization at our scale is always important.”

For him, the other standout was the new SBOM integration in Packer.

“As a security and compliance leader, SBOMs are a big deal. With the recent executive orders and all the discussion around supply-chain security, it’s good to see HashiCorp taking it seriously.”

He emphasized that the ability to automatically embed and track software bill of materials data directly within image metadata will streamline compliance workflows and help meet evolving regulatory requirements.

Looking ahead, Brian and his team are exploring Consul for service discovery and service mesh.

“We want to scale from infrastructure into the application tier. And integrating SBOM data into compliance systems will be a key next step.”

Rob Barnes on Nomad, Terraform Actions, and Building for the Ecosystem

In our conversation at HashiConf, Rob Barnes, Senior Developer Advocate at HashiCorp, shared a grounded perspective on Nomad’s flexibility, the future of Terraform, and what drives his work in connecting users to better workflows.

“Nomad is very underrated. It’s extremely flexible—which for me is one of its core strengths. It’s also extremely scalable… especially for high-performance workloads.”

Rob emphasized that while Nomad has long been seen as an alternative to Kubernetes, its scalability and simplicity make it an ideal choice for modern use cases, particularly in AI data centers, where speed and orchestration efficiency are critical.

When asked about the feature he’s most excited about from the conference, Rob didn’t hesitate:

“The clear winner is obviously Terraform Actions. Everyone’s super excited about that.”

He reflected on how Terraform Actions addresses a long-standing community desire for post-deployment operations—something many had tried to solve with Ansible-style provisioning. Rob admitted that HashiCorp’s earlier stance (“you have images, you don’t need provisioners”) made sense for its time, but “the world’s moved on.”

Now, Terraform Actions marks a major advancement in transforming Terraform from just a provisioning tool into a comprehensive lifecycle automation platform.

Beyond the announcements, Rob’s mindset as a developer advocate stood out. He talked about maintaining the Terraform provider “Terracurl”, which has surpassed two million downloads, and how the new features will soon impact his work directly.

“I can already see I’m going to start getting issues saying—‘Can you implement Terraform Actions?’ Once the conference season dies down, that’s probably what I’ll be working on.”

Outside of his conference workload, Rob’s also working on a five-part blog series on secrets consumption patterns (part 1 & part 2), exploring how organizations can better manage secrets at runtime across AWS Fargate and EC2 environments.

“I’m always looking at the problems people are facing and how, from an ecosystem perspective, we can build integration paths between where we are and where our users are.”

Tameika Reed on Accessibility, AI, and the Future of Infrastructure

Tameika Reed, founder of Women in Linux and infrastructure leader working across edge, cloud, and multi-cloud platforms, brought an energy to our conversation that cut straight to the heart of what HashiConf 2025 was all about.

“By day I lead a team of infrastructure and platform engineers building out edge nodes, cloud computing in multi-cloud environments, and securing those environments — on-prem, edge, and in the cloud.”

Her team’s toolkit reads like a HashiCorp product lineup: Boundary, Consul, Terraform, Vault, and even integrations with OpenShift, which she was particularly excited to see officially supported.

“I’m glad they integrated OpenShift with Vault — that was a big announcement.”

But what stood out most in our talk was how personal this evolution felt to her. Back in 2019, Tameika sat with Armon Dadgar in Amsterdam and shared a prediction:

“I said it’d be great to use AI on the backend of Terraform Cloud — to make suggestions based on what people have already deployed. To help them improve their infrastructure.”

Fast forward to 2025, and that idea has manifested as Terraform Search and MCP servers — both of which she views as major steps toward a more intelligent, guided DevOps experience.

“Here we are from 2019 to what we see now — Terraform Search, with import, and MCP servers that can make suggestions. If I’m a startup, I can use ChatGPT, Terraform Cloud, and MCP to spin up infrastructure really quickly — even without the budget for a full team yet.”

Tameika sees this not just as a technical improvement, but as an equalizer. For early-stage startups or small teams, these features bridge the gap between idea and implementation, allowing teams to deploy quickly, learn faster, and introduce governance later.

“Maybe I don’t have the money to maintain it just yet, but I can get up and running quickly. Then later, I can bring in someone to help maintain or govern it.”

When asked which announcements stood out to her most, she pointed to the same tools shaping the new AI-first operations model:

“I’m most excited about the MCP side and Terraform Search… Terraform Search helps people who already have infrastructure deployed — they don’t have to spend time importing it manually. It’s already there. Just import it, and you’re done.”

For Tameika, MCP is a sign of how AI is transforming how engineers learn and work

Tameika also raised an interesting question about the future of education and certification in this new AI-driven world.

“How does AI change exams? Are we going to be able to use AI on the exam when we’ve been using it all this time? Are we at the age now where exams don’t matter?”

It’s a fair question, honestly, and one that resonates across every industry where copilots and coding assistants are already part of daily workflows. If AI becomes the default partner in real-world engineering, traditional assessments might need to change to focus on judgment and design thinking, not just rote memorization.

Looking ahead, Tameika’s curiosity is far from slowing down. She’s currently studying Generative AI and security, exploring how tools like Vault, OpenShift, and MCP can converge into a secure, automated infrastructure workflow.

She’s also heading to KubeCon, where she expects to see how players like IBM, Red Hat, and HashiCorp might position themselves within the broader AI and quantum ecosystem.

“Just my personal opinion, but I think they’re looking to make a play with or alongside Palantir.”

And her long-term prediction feels both bold and inevitable:

“We’re going to reach a point where everyone’s just creating workflows. You’ll drag and drop what you want, it’ll generate the Terraform code for you, and you’ll hit run.”

That vision aligns perfectly with what’s already unfolding as infrastructure creation becomes more visual, collaborative, and accessible.

“No one cares that you know infrastructure as code. We just need to know: can you check it, does it work, and how much is it going to cost?”

Nasiullha Chaudhari on MCP Servers, AI, and Community Learning

Nasiullha Chaudhari, better known as Cloud Champ to his 160,000+ YouTube subscribers, joined HashiConf 2025 as both a HashiCorp Ambassador and a passionate community educator.

His content centers around cloud, DevOps, and automation, and that perspective showed clearly in our conversation.

“I use HashiCorp tools like Terraform, Waypoint, Boundary, and Consul. I’m here to learn more so I can use them better and share that knowledge with my community.”

When we talked about this year’s wave of announcements, Nasiullha didn’t hesitate to share his excitement centered around the new MCP Servers.

“Most importantly it’s going to be MCP Servers, because initially HashiCorp didn’t have an MCP server under their name. Now they do—for Terraform and other tools. I use Terraform the most, so I’m excited because with MCP, you can just tell the LLM in your language what you want, and it can do it for you.”

He described it as a major change in how people will create and control infrastructure, no longer relying on declarative files but instead using natural language instructions that generate Terraform configurations automatically.

“You can say, ‘I want to create infrastructure on AWS for my application,’ and it’ll do it without you writing the code. And since it’s good for production—you can even use modules and complex setups. I’m eager to test that out.”

But Nasiullha’s curiosity didn’t stop with MCP. He also spoke about Mitchell Hashimoto’s return and the reveal of The Story of Code project:

“I’m also excited to see what’s going on there and why Mitchell’s back. We saw the trailer, and it looked really interesting. With IBM now in the mix, I think we’re going to see even more exciting changes.”

That curiosity reflects what I’m also experiencing. I’m eager to see how HashiCorp’s new era under IBM unfolds with innovation while maintaining its open, developer-first spirit.

For Nasiullha, events like HashiConf are as much about connection as learning:

“These conferences give you exposure. They tell you what’s new, help you connect with other ambassadors and experts. I’m here to connect, learn, and grow.”

After the conference, his focus shifts right back to his audience:

“I’ll go back and start recording my videos again—it’s been long. I miss creating content. I also attend other conferences like KubeCon and DevOps events, but I’ll definitely be back for HashiConf 2026 in Atlanta.”

Takeaways

HashiConf 2025 was a mirror reflecting where the entire industry is heading.

Every conversation I had, from Armon Dadgar’s vision of agentic operations, to Will Bengtson’s emphasis on security baked into the platform, Rob Barnes’ focus on ecosystem enablement, Tameika Reed’s push for developer accessibility through AI, Brian Chong’s enterprise lens on SBOMs and compliance, and Nasiullha Chaudhari’s community perspective, pointed toward the same reality:

The next era of cloud and security won’t be built by humans or machines. It’ll be built with them.

Infrastructure now needs to become more contextual because the tooling is shifting from things we configure to technological partners (AI) that we guide, systems that reason about their environment (AI), operate safely within policy (AI), and adapt as quickly as the organizations behind them (even more AI).

Automation appears to be evolving beyond infrastructure efficiency but more towards infrastructure resilience, backed by the aforementioned context.

And visibility, like the kind HashiCorp is now enabling through Infragraph, is evolving beyond dashboards and charts to bridge the trust gap between people, processes, and the AI that will soon help operate them.

As builders, our role must evolve from writing code that simply executes to designing & architecting resilient systems at scale.

A huge thank you to HashiCorp for sponsoring my trip to San Francisco for HashiConf 2025 and giving me the chance to meet so many brilliant builders and security minds in person.

This newsletter, however, isn’t sponsored by them. It’s an independent reflection written from my own experience, perspective, and conversations throughout the event.

Share

I’ve been in this space for five years now, working as a security engineer, mentoring hundreds of students, and teaching th…

Read more

What started as a room of students, career-switchers, and curious professionals asking simple questions — “What exactly is cybersecurity?” — turned into a deep dive on why this field matters, how attackers operate, and how you can build a career in …

Read more

That provided us with a map of what we’re defending against.

Now let’s talk about the people who do the defending, and those who play offense to make defenses stronger. From there, we’ll dive into t…

Read more

Now it’s time to get a little more structured.

When I teach cybersecurity, I always emphasize that we need foundations—concepts that simplify a massive, complex fie…

Read more

Not quick hot takes. Not polished LinkedIn posts.

This is where I reflect, document, and share the more profound lessons that shape my career and this community.

Earlier this year, I had the opportunity to give a two-hour live workshop on t…

Read more

I was 18, a college freshman, and an immigrant trying to figure out not just how to pass classes, but how to carve out a future in an industry I barely understood. Back then, terms like Blue Team and Red Team sounded like code names from a movie, not real jobs people built career…

Read more